Menu
▾
▴
openvrml-develop
|
From: Braden M. <br...@en...> - 2002-03-20 07:12:14
|
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...> |
|
From: Nigel S. <ni...@ni...> - 2002-03-20 11:38:04
|
Braden,
I'm very happy to hear that OpenVRML is heading towards a stable
status. Speaking for myself, there are two major issues with
OpenVRML - handling of events to PROTO's (H-Anim) and examiner
viewing for lookat. I think I'm probably qualified enough to
dig into the examiner issue, but the camera transformation scheme
wasn't clear to me whan I had a (quick) look recently. Any clues
that can be offered here on the forum?
I'm more than happy to try a snapshot, whenever that becomes
advisable....
A mozilla plug-in is certainly attractive, but my feeling is that
compulsory dependency on extraneous libs is something to be warey of.
If I simply want to use OpenVRML as part of a 3D engine - do I need
to deal with xxx.so and yyy.so? Cygwin? Win32? So, if there is a
scheme that can optionally use, say, the mozilla tricks for doing
a mozilla plugin, that would be the ideal.
Boost, of course, is a good thing.(tm)
Nigel Stewart
> 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...
--
Nigel Stewart (ni...@ni...)
http://www.nigels.com/
|
|
From: Braden M. <br...@en...> - 2002-03-20 15:10:27
|
On Wed, 2002-03-20 at 06:34, Nigel Stewart wrote: > I'm very happy to hear that OpenVRML is heading towards a stable > status. Speaking for myself, there are two major issues with > OpenVRML - handling of events to PROTO's (H-Anim) and examiner > viewing for lookat. I think I'm probably qualified enough to > dig into the examiner issue, What issue is that? Bose repaired examine mode some months ago. > but the camera transformation scheme > wasn't clear to me whan I had a (quick) look recently. Any clues > that can be offered here on the forum? Look at getParentTransform and friends on Node. The event issue with PROTOs will hopefully be resolved as part of my rewrite of the PROTO implementation. But we have no shortage of areas that need more love than I am able to give. It would be especially helpful if someone were to tackle caching images inside the renderer, or use FreeType to make our Text node support stop sucking. > I'm more than happy to try a snapshot, whenever that becomes > advisable.... As I posted previously, the rearchitecture branch has stabilized and is usable for the most part. It doesn't do PROTOs yet, but I'm working on it. The main branch should be at least as usable as 0.11.2; hopefully more so. So have at it. :-) > A mozilla plug-in is certainly attractive, but my feeling is that > compulsory dependency on extraneous libs is something to be warey of. It would only be compulsory if you want to build lookat. If you didn't care about building lookat, you wouldn't need Mozilla. Just like you don't need SpiderMonkey if you don't care about JavaScript support. > If I simply want to use OpenVRML as part of a 3D engine - do I need > to deal with xxx.so and yyy.so? Cygwin? Win32? So, if there is a > scheme that can optionally use, say, the mozilla tricks for doing > a mozilla plugin, that would be the ideal. Someone who wants to use the OpenVRML runtime in their application shouldn't care about lookat except as a source of example code. -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Nigel S. <ni...@ni...> - 2002-03-25 11:53:59
|
> > examiner
> > viewing for lookat. I think I'm probably qualified enough to
> > dig into the examiner issue,
>
> What issue is that? Bose repaired examine mode some months ago.
I'm using 0.11.2. I suppose I'll need to wade into CVS
and see if I can get examiner mode. Thanks for the info.
Nigel
--
Nigel Stewart (ni...@ni...)
http://www.nigels.com/
|
|
From: John R. <ric...@sp...> - 2002-03-20 18:09:41
|
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 |
|
From: Braden M. <br...@en...> - 2002-03-20 18:59:13
|
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... |
Thanks for helping keep SourceForge clean.
X