There have been a few good suggestions already, here are a few more.
The application can always help Java 3D by doing some rough culling
at the scene graph level. A while ago I wrote Quake2 and JediKnight
loaders on top of Java 3D and used their extra visibility data structures
to do some scene graph culling for Java 3D. At that time I used switch
nodes, and performance was fine. If I was to do it over with the latest
Java 3D, I would switch to using a combination of
RenderingAttributes.setVisible() and the AlternateAppearance node. It
should make the scene graph a little less node heavy, a little easier
to control, and probably less stressfull on the Java 3D runtime system.
I don't have any evidence that this is the case, just a gut feel.
Switch nodes can be expensive because of all of the semantics surrounding
them.
As for how Java 3D does culling, it is a two stage process. We use our
spacially orgranized geometry structure to do a rough cull - which is
a sphere surrounding the viewer. Then, when we render the objects, we
do an exact cull to the view frustum. The bounds that we use on the
exact cull depends on a number of things. For instance, if two geometries
share all the same rendering attributes and transform, the bounds we use to
cull will be the union of the two geometries.
Hope this helps.
Doug Twilleager
Sun Microsystems
>MIME-Version: 1.0
>Subject: [JAVA3D] BSP, Switches, Memory and Performance
>To: [EMAIL PROTECTED]
>
> 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".
===========================================================================
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".
