Normally I'd post this to the Java 3D comments address but I always get the impression that its going into a black hole over there (just my feeling --- probably not true). Anyway, if nothing else perhaps I could get some feedback to see who else is interested in some of the fancier 3D UI stuff like display and world overlay. Some of the following are new thoughts and others are perhaps better formulated versions of earlier ones. Since it appears that real display overlay is probably far off here's an idea for the interim that could help in approximating display and other forms of overlay... In addition to a near clip plane also define a "really near" clip plane. Then allow objects to be designated as belonging to the "world" or "display" space. Objects belonging to the world would be subject to normal near and far clipping. Objects belonging to "display" space would be subject to clipping between the "near" and "really near" clip planes. This way you could approximate display overlay (and other forms of overlay) by locating and scaling objects within this pseudo "display space" (which is actually quite easy to do and fun for the whole family as my book will show). Of course, to prevent other views from seeing the "display space" objects one of my earlier suggestions would have to be implemented. As I'm sure you recall, I suggested that objects could be assigned to a given view and they would only appear in that view and no others. Thus, if you wanted a billboard to appear in a two-view system then you'd create two billboards at the same world location and assign one to one view and the other to the other view. The same goes for objects in "display space". They would automatically be assigned to their associated view and therefore only appear in that view. Many overlay scenarios require knowing the position of the view and a given target object. What is desparately needed is some way to query the scenegraph for view and node local-to-vworld info, make a computation based on this info, and then update the node position accordingly in the view. For third person camera control (i.e. twirl a knob and move the view) you need a variation on this theme where you query node position and update the view position accordingly. These kind of "behaviors" are also useful in collision detection and update scenarios. What is needed is a way to sample and update the scene graph in the same rendering "cycle", of course without event loops occuring. This can be done. It was proven in the Cosmo Player VRML browser. We used it all the time to do some pretty fancy UI work. The only problem of course was the stability of the overall VRML platform and its ease of installation -- but I digress. Anyway, perhaps you guys should take a peek at the Cosmo code or talk to those guys to see how they were able to pull it off so well. I'd like to think that Java 3D can at least attain the level of functionality and approach the performance of VRML. --jon ____________________ Peculiar Technologies ____________________ Jon Barrilleaux 3800 Lake Shore Ave. Purveyors of [EMAIL PROTECTED] Oakland, CA 94610 Alternate Reality 510.444.4370 voc Augmented Simulation 510.444.0231 fax www.augsim.com and 3D Solutions =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
