All I can say, is that you appear to be one of a very few (or a one project) that has noted all these problems. Maybe the project you're working on isn't suited to Java3D, maybe the way you're thinking about it isn't suited to Java3D. Either way, you're not talking about a general case here..
In many cases (more general in my opinion) people have found that the benefits of Java3D (scenegraph, input abstract, sound abstraction, independent loaders and of couse the strong community) have far out weighed the option of "rolling your own" in any OpenGL binding. As to the Java3D API not being complete enough! Its complete enough for a number of projects to be up and running.
And back to a comment I made somewhere here, if you're looking for flat out speed then why not go use C++? I program C++ for a living (although I've done java there too). I don't find either one particularly more difficult than the other, as long as you keep yourself to good programming practices. If you need speed, and you don't care about time to market, code reuse or platform independance, then sure goto a direct GL binding. But I can't really understand what huge benefit working in Java would then give you (apart from its nice to work in, and has quite a few built in utilities but most of these are a matter of looking for C++ version).
Kevin
PS. Insisting on your opinion isn't listening any more.
MisterXen wrote:
Hi Jeremy,
I´m sorry that I have to insist on my opinion and I can't agree with you. I don't see the point, why using scene graphs makes your life easier!?!
erm, cause it does everything I need without having to re-write it myself, if I load an object from say an AC3D file I have one of two choices, embed GL calls into internal representations of the model components, or load them, and bung it in a scene tree. Embedding gl calls means that special cases can easily be coded round, but I now have to work out how I'm going to get all my transparencies sorted properly to render in reverse depth order as the camera in my scene sees them. A scene tree I can traverse and find all these transparent bits, and work it out from my 'View' object combined with each geometry, turns out that now it's a piece of cake to do, or even better, in the case of java3d, it's done for my behind the scenes with no worries, 'It just works'.
Okay, that's an argument! I wasn't well informed about "automatic" transparency Java3D can do! From that point of view a scenegraph makes sense! But I can try to illustrate you the problems I had using a scene graph! I have ~1000 objects (spheres) to draw every frame. And I don't know which and how many spheres to draw beforehand. Thus using a scenegraph is a huge overhead, since I have to manage "visible"-state for each sphere primitive and management of the states is a real pain! And building a complete scene tree for each frame is impossible! In OpenGL I can do per frame (immediate mode) what I want to draw! Any ideas how I could do that with Java3D??? I think no!
First, I thought that scene graphs are fine. But now, where I can compare the Java3D code with the (ported) OpenGL code, I see that OpenGL code is shorter and very clear.
shorter?, clearer?, I think your java3d code is wrong, to place an object with transparency, textures, texture coordinates, normals, and of course vertecies is just a few lines of code, GL on the other hand, isn't, it's still not rocket science, but it's not short and sweet either. Then you have to worry about depth sorting the transparent bits, turning on and off the depth buffer and depth buffer writes, loading the texture and binding it each time you draw the object. Granted that setting up an initial scene in java3d takes some effort, but the rewards are worth it.
I understand what you want to say! But depth sort isn´t such a pain .... :)) ) And I can't use the benifits of a scenegraph, because of the immediate mode problems described above! 2nd the incomplete implementation of Java3D is a pain, since I cant do what I want!
To solve a certain issue in Java3D I need twice as much code in Java3D than in OpenGL.
are you making the calls direct each time in GL, or are you creating objects that know how to render themselves and placing them in a world, if your doing that latter, you are using a basic (very basic) scene tree anyway
If an object knows how to draw itself this makes no scenegraph, not even a very basic scenegraph! The tree structure of the scene graph is not always the best representation of a scene. (see problem above!) The problem are the vertices (thus the links) between the nodes!
Apart from that one can influece the depth buffer in OpenGL (but not from within Java3D because the access of OpenGL functions is not allowed).
View.setTransparencySortingPolicy View.setDepthBufferFreezeTransparent RenderingAttributes.setDepthBufferEnable RenderingAttributes.setDepthBufferWriteEnable
Fine, but there are still important functions missing. Can you access any buffers in Java3D? I think no!
Eventually ..... thats the point. I don´t know what Sun will do in the future and thus I don't know, when the feature I need is available! ... I´m dependent on Sun :(((
you are dependant on the OpenGL group with GL for new features, you don't know when they will be put into GL4Java (which is currently only on gl 1.3), it's true that jogl can be recompiled against new GL libraries for new releases. If you need bleeding edge technology you wouldn't have looked at java3d for long in the first place though :)
1. GL4Java source is available, thus I can add those functions of OpenGL I need :) 2. 2 years ago, Java3D seemed to do a good starting point .... but my hope, how Java3D would develop in the future, wasn't fulfilled! And now it seems that there won't be a new release of Java3D. I can't wait for years to have Sun doing what I need!
Yaa, you are right. A scenegraph on top of a binding would be nice. But that scenegraph has to be complete and extendable. (not that indication of a scene graph Java3D uses!)
so you agree that scene graphs are good now?
I said, that a scenegraph has to be complete and extendable .... not the scenegraph itself (by adding nodes), but the scenegraph nodes which should do what one needs!
Maybe, maybe not ..... but why should I risk to sink :)))
if you jump you may drown before someone rescues you :), on the other hand, with less weight the ship might float longer :P
Baaah, what a bad metapher :)))
Regards
MisterXen
===========================================================================
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".
=========================================================================== 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".
