Hi Joachim,
[EMAIL PROTECTED]">
For 3D-graphic issues you may be right, but Java3D is much more, because
instead of GL4Java, .. it provides an excellent vetor math package, and
everthing (Materials,..) is straight OOP. Further OpenGL alone doesn't

Sure that's right but on the other hand you would gain full access on
display lists, vertex, buffers, etc. And coding a rudimentary vector-math
package which would fit most of the things one would need would
propably just take a day (or there are already alot available on the
internet).

You're right, most of us already have an own vecmath package, material classes, ..
Neverless it would be nice to have one OOP standard for 3D gfx in java.

The full acces on displaylist, vertex buffers, .. isn't what I want, because then Java3D would be dependent on OpenGL.
In Java3D I needn't  work with Extensions (ArrayRange, Multitexturing, .).All I have to do is telling J3D whehter the Geometry is STATIC or BY_REFERENCE.
And again I guess - even if it's possible - it is much more confusing to work together with JMF for using videos,..


[EMAIL PROTECTED]">
Summing up, Java3D's pure immediate mode is even a great benefit for
developers.

Hmm someone who's only focused using on pure intermediate mode is
throwing around 80% of Java3D away IMHO. Ok besides he doesn't have to
think that much about state changes of course (which is a benefit yes :)
).

That's my argumentation, Java3D should contain more immediate mode related classes, e.g. picking classes could implemented for immediate mode and these ones used for the scenegraph..

IMHO scenegrpah rendering is perfect for 'little' web-applications, because it shortens the developing time. But for games, e.g. which uses a portal engine, .. it can be even more complicated, because a good visual scenegraph needn't to be a good game scenegraph.
Evil voices may tell that's why java3D developing isn't as fast as other APIs ;-)


gretetings
 -Michael Nischt






[EMAIL PROTECTED]">


Reply via email to