> what we really need to know is whether Java3D can handle a heavy
> graphics load without getting bogged down.
In its current form, I would say 'no'.
This is one particular beef that I have with Java3D. Why is it so slow, and
why does it balloon up in size as more items are added to the scene graph?
Is it because there was a conscious effort to reduce the amount of native
code in the current Java3D implementation? If so, then this decision should
be revisited. The native component isn't going to go away, and, well, "in
for a penny, in for a pound", you know?
Shouldn't a retained mode graphics system be at _least_ as fast as an
immediate mode one? Java3D is not. A quick example of this can be seen if
we compare Java3D with "In3D for Java", which is a high level graphics API
designed for business visualization. In3D is implemented as a large native
component (4MB DLL) with a thin Java layer on top. It has its own retained
mode architecture, and renders via immediate mode calls to OpenGL. It's the
closest thing to an "apples vs apples" comparison that I could find without
looking too hard...
Test platform: 500 MHz PIII, 128 MB RAM, TNT video card
Test case: 20 x 20 grid of boxes, all individually rotating in a 1280 x
1024 window.
In3D for Java: 20 fps, 34 MB
Java3D: 1.6 fps, 59 MB
Test case: 33 x 33 grid of boxes, all individually rotating in a 1280 x 1024
window.
In3D for Java: 9 fps, 34 MB
Java3D: memory use went to 90 MB, then crashed the JVM (1.2.1) before
showing a single frame.
Believe it or not, this is somewhat of a worst case scenario for In3D. It
has more efficient constructs for sets of graphics primitives if they all
have the same orientation but have different location, color, dimension etc.
We didn't use them because they would tip the comparison unfairly in In3D's
favour :)
But this is not spam for In3D; I would like to know if there are plans afoot
to address these issues in Java3D. I would also like to echo the concerns
of a previous poster -- as graphics hardware performs more of the rendering
pipeline on desktop boxes (who else here has asked Santa for a GeForce?),
will Java3D be able to take advantage of this fact? Or have they
implemented transforms and lighting in Java, for the sake of purity (gak)?
Regards, Mike Chapman at Visible Decisions Inc http://www.vdi.com
__________Changing Your View__________ mailto:[EMAIL PROTECTED]
===========================================================================
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".
