We are starting to get to the point where our scenes are complex
enough that we are seeing poor framerates even on top end cards.  Since our
scenes can have an almost arbitrary complexity we need to be "smart" about
what we show the user and what we don't.  Java3d currently does view
fulstrum culling, but does it at the shape level.  This means that
everything infront of you in the view is sent to the card no matter if it is
occluded or not.

        When you work with traditional 3d API's you control everything that
is sent to the card each frame.  Thus you can sort your geometry and cull
out even triangles on each frame.  A common data structure for this is to
use a binary space partition tree.  The issue at hand is to figure out the
best way to solve this problem within the java3d API.

        One possibilty would be to put every single shape below a switch
node, index the switch node using a BSP and selectively switch nodes on or
off on each frame.  I have not tried this yet and wanted to get a feel for
whether this might work before going down this road.    So some questions:

        1) What is the total memory overhead of creating a SwitchNode?

        2) Is there ANY performance penalty to switching nodes off or on?
For example, does Java3d do anything under the hood that will have it making
new retained versions, or re-optimizing the tree or do anything that will
cause changing the toggle on several thousand children to negativly impact
framerate?

        3) It is of course necessary to set the compatibility bit on the
switch node so the children mask can be set.  Of course the node is usless
if you can't do that, but you still have to set the bits.  What will be the
consequences to the scene graph optimizations to having the switch nodes in
front of each shape.

        4) Are changes to switch nodes done in a behavior guarenteed to be
synchronized with the view?  I ask this because the culling algorithm needs
to take into account the view, and that frame will need to turn off all
shapes fully occluded or not in view.  So if there was a one frame delay, as
people turned in place or rotated, it is likely that the scene would be
missing shapes that had been turned off for the prior frame.

        5) Is there any advantages to culling items outside the view
fulstrum if you can do it from an application level?  For example if you
have a grid layout for a large area, you could turn off all the cells out of
view on each frame, even through Java3d will do this for you.  But at the
application level you could be very smart and shut off huge numbers of
shapes with one switch node, which Java3d has to look at every shape and
make a decision.

        Had anyone gone down this path before?  Any information would be
helpful.

        I think the following test would be helpful:

        1. Define 20 box primitives from the util class and arrange them all
in the same view.  measure the framerate.
        2. Define 20 box primitives arranged under switch nodes and measure
the framerate and increased memory usage.  Hopefully framerate will be the
same and there would be a slight memory increase.
        3. Define 40 boxes, each under the switch node, and on each frame
switch half the nodes on and half off, alternate every frame.  Measure frame
rate and memory usage.
        4. Increase the number of test boxes and perform test 3, do this
until there are several thousand shapes.  Measure changes in frame rates and
memory usage.  Hopefully framerates will remain consistant.

        Dave Yazel
        Cosm Development Team

===========================================================================
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