David,
We are using switch nodes in our application, though I can't say what the
performance impact has been between using them and not using them. In our
application we have a variety of locations in which certain collections of
objects in the scene will not be scene. We have created a list of which
groups of objects should be visible from a particular location and we
switch off the groups based on this information as the user navigates
through the environment.
Our options were:
1) Leave all of the objects on even if occluded--this is clearly a bad
idea except for the simplest of environments
2) Delete or set invisible all objects which are occluded
3) Use a switch node
My experience with other 3D APIs has been to use something similar to a
switch node.
Additionally we are using the J3D scene graph to group collections of
geographic objects such that J3D can more efficiently cull whole sections
of our scene graph when they are out of view by testing the bounding box on
the group rather than each individual object. Scene graphs can be your
friend...
Anyway, if you want to use a BSP-tree than you should do so, but I wouldn't
recommend putting a switch node above each and every object. Rather I
would try to create a small number of hierarchical levels representing
geographic space -- similar to an octree. Each object can be assigned to a
region and each of these sub-regions should appear under a switch node.
My $0.02.
--Mark
At 11:03 AM 11/30/2000 -0500, you wrote:
> 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".
Mark Ferneau 240-462-6262 (cell)
Director of Adv. Technology 801-437-4608 (efax)
Xtivia Technologies, Inc. 732-469-5954 x629 (NJ office)
[EMAIL PROTECTED] 301-279-5703 (home office)
http://www.xtivia.com/ [EMAIL PROTECTED] (wireless email)
===========================================================================
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".
