Re: [openvrml-develop] Making Lookat useful

[Braden M. <br...@en...>]

Quoting John Richardson <ric...@sp...>:

> Hello,
> 
> In SimVRML, the idea would be to offload "ALL" simulation ( = behaviors )
> from  the rendering system. In my favorite case, that means perform the
> simulation in Labview and then use interprocess communication to access
> OpenVRML methods to modify the virtual environment.

The core of OpenVRML isn't a renderer; it's a runtime that supports the behavior
described in the VRML97 spec (or, at least it attempts to do so).

Of course, it can be used as a renderer for something as you describe. But keep
in mind that from my perspective, OpenVRML isn't supposed to be a single black
box. It's supposed to be lots of little black boxes that work together. :-)

> The SimVRML RPT is a "VRML GUI builder". The same strategy (Macintosh)
> would be used to improve the "human factors" capabilities of SimVRMLviewer,
> which comes from MacLookat, which comes from Lookat. It is just a case of
> making a more interesting or capable SimVRML RPT. The biggest problem would
> be in performing usability testing to get the most useful set of user
> interface elements for a generic VRML viewer.   Now, one of the benifits of
> using SuperCard is that it does have some built in capabilities for
> networking. Windows users would use Director, UNIX users would use MetaCard
> for rapid VRML prototyping under the above scheme.

A big difference between the environment provided by OpenVRML and that provided
by your typical GUI builder is that the clock is running in OpenVRML while
you're building the GUI--not just while you're using it.

Aside: I'm quite fond of the notion of building world UIs with VRML. But I tend
to come at it from the direction of wanting to be able to write custom nodes to
participate in such UIs.

> So, from that standpoint, removing the code from the library is fine.
> However, since Lookat and it's descendents are standalone, we would become
> dependent on being a plug-in to a browser. Is that correct?

No. None of the *lookats is dependent on lookat. It would be completely possible
to build a standalone viewer, if someone wanted to do so. (In fact, that's along
the lines of what Semblance would be, if I ever find time for that project.)

It is accurate that all of the *lookats would be broken by this change and would
need a nontrivial amount of love to repair.

> Naturally, the
> user would not have to implement the network methods. They can have other
> systems handle the networking. Just as long as there is a method in
> OpenVRML to load a file into a standalone configuration.

The library user *would* have to implement Browser::getResource (or whatever it
ends up being called). Hypothetically speaking, this method would return an
IResStream (which is basically a std::istream with additional methods for
getting things like the URI and the media type).

If the library user isn't interested in network access, this method can be
implemented using the local filesystem API for the target environment.

> Metrowerks Codewarrior should be happy with iostreams so I see no technical
> problem.
> 
> The above comments are just that. They implement a certain strategy that
> leverages the OpenVRML work. The goal of OpenVRML is still the same. Full
> compliance with the spec. I'm not a scengraph guru.
> 
> In the meantime, I'll pass on this "network integration with OpenVRML"
> question on to the SuperCard network guru's and the Labview network guru's
> for comments. I'll also pas on this to my contacts in Template Graphics
> systems for comment. They make the commercial Open Inventor libraries.
> Their subsidiary also makes Amapi and Carrara which I believ have network
> rendering capabilities.

It would be interesting to get some feedback there, but I'm inclined to doubt
that those projects have the same priorities and problems that we have.

As far as I'm concerned, it is a given that networking code doesn't belong in
the core library.

 * There is *no way* that we will ever be able to produce networking code that
is as good or as complete as what is available in a project like Mozilla. Or
even libwww for that matter.

 * If by some blunder we allowed ourselves to be convinced that a robust,
cross-platform networking subsystem were an approachable task in the context of
this project, then other parts of OpenVRML would suffer greatly. The resources
just aren't there.

Given the above, the task at hand is to *enable* the use of robust, complete
networking facilities in conjunction with OpenVRML, while keeping those
facilities *out* of the library. The code has to go *somewhere* though; so if it
isn't in the library, it goes into lookat or whatever the client application is.

-- 
Braden McDaniel                                   e-mail: br...@en...
http://endoframe.com                              Jabber: br...@ja...