Hi Mike,
The memory increase comes from Java 3D making a copy of the geometry
internally. In 1.2, we have included geometry by reference which
gets rid of this copy.
As for the slow performance, if you send your test to [EMAIL PROTECTED],
we can look into it.
Thanks,
Doug Twilleager
Java 3D Team
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
> Subject: Re: [JAVA3D] Performance benchmarks?
> To: [EMAIL PROTECTED]
>
> > 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".
===========================================================================
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".
