> From Norihito Hiruma <[EMAIL PROTECTED]>
> Right now, I am trying Java3D but Java3D's attribute change performance is
> too bad.
Your program has exposed a performance problem with Java3D 1.2. If there are
too many shapes with the same appearance the performance can suffer due to an
n^2 algorithm. In your case there are 10,000 shapes with equivalent
appearances, so the slowdown is more severe. The problem is being addressed,
it won't be fixed for 1.2.1 beta, but it should be fixed for the final release
of 1.2.1.
In the meantime, you may find that the performance of smaller data sets is much
better, due to the n^2 factor of the algorithm. On my system making the data
set 4x smaller makes the performance more than 8x faster.
> > From: Justin Couch <[EMAIL PROTECTED]>
> > - You may be stumbling on something j3d is doing with the rendering
> > process if it is taking so long. Have you tried calling stopRender(),
> > changing all the values, and then calling startRender() again?
> Yes, I had tried this too.
> ( call stopRender() -> setDiffuseColor() -> startRender() )
> But the result didn't change, so I deleted the code.
This is another problem. When making many changes to the scene graph outside of
a behavior there is no way for Java3D to know when you are done and Java3D will
probably update before you are ready. Stopping/starting the renderer or
detaching/attaching the scene graph can fix the problem, but both have
unnecessary overhead. A better way is to use Behavior.postId(). The idea is to
set up a behavior which can be triggered when the edits need to happen. The
edits happen in the processStimulus() method for the behavior. This way Java3D
can hold off on updating the display until after processStimulus() has returned.
See the updated Test.java for an example of this. Search for "updateBehavior".
Doug Gehringer
Sun Microsystems
Test.java
