Hi Justin,

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!

Sure. Use the RenderingAttribute class and call setVisible(). Only call it on objects that have changed state this frame.
Thats exactly what I did :))) It's not an apropiate solution for the
problem described above, since I (still) have to manage the visible-states!

So far from your comments, you are appearing to be extremely ignorant
about what scene graphs are and how they function in general.
Ignorant isn't the right word. As I wrote in the beginning of the thread,
the scenegraph implementation used in Java3D is not complete in my opinion.
And I´m sure to know the features and benefits of a scenegraph in general.
I said, that most (and that means not all) features the Java3D scenegraph
provides are 1:1 mappings to OpenGL. Java3D provides just too less
scenegraph features, which would make it worth using. (see below)

I tried not to make any statements like: Java3D can't to this and that. But
concerning the buffers I wasn't right, thats true.

I suggest
you do a heap more reading first before you claim anything more about
what j3D can and cannot do. Other very salient points you seem to have
completely ignored are things like culling, multipipe rendering, state
sorting inbuilt picking and many many more features that would take you
hundreds of hours to implement if you were to start from scratch.
Concerning your last sentence: If you think, that is true, I have to
disappoint you. It took me ~20hours to adapt my application to use an
OpenGL binding instead of Java3D. And this concerns features like picking &
selection, depth-sorted transparency and two different kinds of stereo view
(field-sequential and column-interleaved), which I had to implement myself.
(and which couldn't be achieved because of the missing StencilBuffer
functions in Java3D) So maybe I´m not able to use Java3D properly or Java3D
just isn't so "well-designed" as you claim! The adaption was so easy and
quick because Java3D is a somewhat 1:1 mapping to OpenGL.

Apart from that, how can you explain, that my application runs a factor 2
faster using an OpenGL-binding, if Java3D is such a well optimizing
scenegraph system???

Additionally it took me 10hours to implement picking and selection with
Java3D (first bounding boxes to make estimations which objects the click
concerns, then detailed intersection tests). On the other hand it took me
10hours to make the same selection routines in OpenGL which are faster by a
factor of 10. So Java3D is such a well optimized system! =:)


Best 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".

Reply via email to