One thing about the "per Shape3D culling in Java3D...
In most Scene Graph API's and as I understand it in Java3D, it's not really per Shape3D, it's per BoundingBox or Sphere at the Group/Node level. So if a particular Group that contains allot of nodes and Shape3Ds has a Bounds that is not in the view frustum, then the entire sub-graph is culled.
For very large terrain, proper database organization (QuadTreeing is one way) is usually all that needs to be done, and then this Bounds based culling will work great. However, for interior environments with allot of occlusion, BSP's or other some of occlusion culling technique is often needed.
Still, in the end the app can know best if it knows some about the views motion, for example, if the view is on a track and can never go backwards. In some thing like that, the app could help improve the culling.
Yazel, David J. wrote:
[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 t! he 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".
-- ___________________________________________________________
Shawn Kendall Full Sail Real World Education Course Director 3300 University BLVD Real Time 3D for Gaming Winter Park FL 32792 [EMAIL PROTECTED] http://www.fullsail.com ___________________________________________________________
=========================================================================== 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".
