Java3D isn't a High-Level-API: Okay, maybe it is what some people think high-level is, but in detail it is no more than a wrapper for OpenGL, touching the concept of scenegraphs. Most calls seem to be a 1:1 wrappers for OpenGL .... and the more I got involved into native OpenGL the more the parallels between Java3D and OpenGL showed up. What do I need this "high- level" API for? The scenegraph-"capabilities" of Java3D are more debilating than of any use. Most features are nearly 1:1 "calls" to OpenGL .....Wow, we definitely see it from a different perspective. There are two main advantages for us, namely:
- that we can develop our code on any platform we wish and deploy it many environments, including our CAVE, without modification (using the ConfiguredUniverse utility). The abstraction of InputDevices, the inplementation of head-tracking, and many other details allows us to take external apps and make them VR apps very easily because the scene and the final display are uncoupled. Perhaps it's not that Java3D isn't high-level, but that for just showing a 3d object on a monitor you don't really access these capabilities. I'll bet you a lot of people develop code to use Java mouse events, instead of the provided Java3D InputDevice interface.
You are right with the abstraction of InputDevices. I forgot that point! Thats a nice feature. But on the other hand, the flexibility of output devices is too limited. We use a stereo projector for our application but I was not able to produce that format with Java3D (it needs field sequential stereo view or column interleaved) thus it's kind of worthless :(
The main point I want to emphasize is that the basic idea of Java3D is brilliant, but due to a lack of features and extensibility the API is restricted or even not usable!
- the standard scenegraph representation allows us to use behaviors we construct, such as dissection in virtual reality, on any kind of data we import. The Java3D makes it so we don't have to hack other people's code to be able to manipulate their scenes. Our behaviours get loaded into the other app through the ConfiguredUniverse. Once again, if you're only going to do one app, or don't expect to use external products, perhaps you don't need this modularity.
The modularity is fine as I mentioned above, but the implementation is not complete :(((
Exactly, that's the point!So perhaps it's not that it's not high-level, but that for your applications it doesn't have enough benefits to make it worthwhile.
What should happen to improve Java3D:
-make Java3D open source so the community is able to improve or extend Java3DAt last year's SIGGRAPH, it was mentioned that Sun would like code contributions for the 1.4 API. But I'm sure it won't be open source. If what you mean is that the source code is available, yes that's the case I think, but you won't be able to start branding new versions of Java3D, as you could in OSS. All the Java APIs have the same Community Process to make them stable AND reflect user needs at each major revision.
Maybe I´m wrong, but I believe the effort to improve and extend the current version of Java3D is not too heavy for a community. (if its OpenSource) But as long as I don't even have a chance to make improvements, I have to rely on Sun for the next improvement :(
:))))I'd like that too.-Sun should continue Java3D and release version 1.4 as soon as possible and with the most wanted features
Right, in this sense the current Java3D is only a subset of a complete API!-introduce a real high-level api, which supports VRML, 3D file loaders, advanced intersection, NURBS and what elseThe intent of APIs thought is not to provide all the loaders, but to give access to the framework. Plus issues of updates for things frequently changing like xj3d would bog down the main API revision process.
:)That being said, I'd love for someone to come up with NURBS loaders with LOD management :-)
-low-level access to OpenGL or DirectXUnfortunately, you're asking for the Impossible Program. One that has very high level functionality that should be portable and efficient, but allows the user to muck around with the implementation. It'd be nice, but it's not possible to any great extent.
I totally agree. And due to the most wanted platform independence it's kind of impossible! What could happen: 1. Java3D becomes OS, thus people can improve and extend the brilliant base of Java3D. 2. If Java3D won't become OS, nothing could be done, except hoping that Sun becomes sensible and implements as many features (from OpenGL and Java3D) as possible!!!!
Regards
MisterXen
P.S. On the other thread, good to know the source of the "holding pattern" stuff. Thanks. I'll remain optimistic that new graphics developments will be amenable to Java3D stuff. Why waste all that effort?
I´m feeling sad, reading the whole stuff about "Java3D is dead" and seeing Sun somehow discarding the brilliant concept of Java3D, but on the other hand I'm happy, that I did the right thing three month ago, did't continue with Java3D and instead used an OpenGL-binding!
=========================================================================== 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".
