HI Dave,
I've written an example app which uses Switch nodes in the way you describe.
My motivation was to render a set of geometry with more triangles than the
hardware could cope with and maintain a reasonable frame rate. I broke the
geometry up into a set of tiles, each under a Switch node. I then enable/disable
the tiles depending on the viewers location and orientation. My tests showed
that there was a performance advantage in having the application cull the
tiles rather then relying solely on the Java3D view frustum culling. My tiles
were relatively large so the app was culling a lot of geometry and then
the Java3D view frustum culling would work on the remaining tiles.
I was using 100's (not 1000's) of Switch nodes.
So the approach you propose should work fine.
Rgds
Paul
N.B.
There is a performance in the current versions of Java3D if you include Link
nodes under the Switch nodes. This should be fixed soon....
----------------------------------------------------------
Paul Byrne Email : [EMAIL PROTECTED]
Sun Microsystems Phone : (650) 786 9926
Visualization Software Group Fax : (650) 786 5852
----------------------------------------------------------
>MIME-Version: 1.0
>Date: Thu, 30 Nov 2000 11:03:07 -0500
>From: "Yazel, David J." <[EMAIL PROTECTED]>
>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".
