Re: [openvrml-develop] Making Lookat useful

[John R. <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 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.

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? 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.

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.

John F. Richardson

>It'll be some weeks before I start any development on this; but the
>ideas are bouncing around in my head, so I thought I'd go ahead and post
>them to get a reaction...
>
>The major item I'll be pursuing for the 0.13 release is a good
>asynchronous I/O story. My plan for this is to use C++ standard
>iostreams in conjunction with threads (probably Boost threads). As part
>of this change, network code will be removed from the library. There
>will be a virtual stream factory method, probably on a Browser class,
>that users of the library will need to implement.
>
>The downside of this is that OpenVRML will become more difficult to use;
>the upside is that OpenVRML will be able to leverage whatever network
>code is in place in the host environment. So if one were writing a
>browser plug-in, one could use the network functionality exposed by the
>browser's API, and presumably leverage things like the browser's cache.
>
>Because the approach to implementing the streams is not readily apparent
>to persons unfamiliar with the iostreams framework, and more importantly
>because we will need a means of testing the "upstream" code in OpenVRML,
>a sample implementation will be provided. So Lookat will be improved
>along this vector, both to provide that implementation and to keep
>Lookat functioning alongside the library.
>
>And at that point we have a choice: What network code do we use as the
>basis for the sample implementation? The code must remain
>cross-platform, and any dependencies should be widely deployed (or at
>least readily available).
>
>One obvious candidate is the W3C's libwww. This, I imagine, would be
>very good for illustrative purposes, but little else. I get the
>impression that there isn't a whole lot of nontrivial code that depends
>on libwww. And presumably there are good reasons for that. Still, if
>providing an illustration is what is called for--and that is Lookat's
>primary purpose--I am sure it would fit the bill.
>
>But there is another alternative: turn Lookat into a Mozilla plug-in. In
>this case we would, of course, use Mozilla's networking facilities. The
>disadvantage? Lookat would nolonger be a standalone viewer. I get the
>impression that a lot of folks like having a standalone viewer, but
>frankly it's lost on me. The advantage is that, IMO, a Mozilla plug-in
>would be much, much more useful than what Lookat is now.
>
>So I'd like to take the group's temperature on this. A Mozilla plug-in
>is definitely a more ambitious project; but I'd like to maximize the
>value of the development time I spend on OpenVRML, and I think it's the
>way to go in that respect.
>
>--
>Braden McDaniel                           e-mail: <br...@en...>
><http://endoframe.com>                    Jabber: <br...@ja...>
>
>
>_______________________________________________
>openvrml-develop mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openvrml-develop