I currently do a "rough" culling at the terrain level, the specific
situation I am talking about is in "town". It does not take many houses
before the frame rates start to drop sharply. So my thought was to consider
cities and towns to be special cases of a large, controlled static
environment and use a BSP tree. Thus for example the back wall of a house
would not even be rendered if you can't see it from the front of the house.
Thus I am concerned that any one frame would require me to switch on and off
possibly 100's of shapes.
Dave Yazel
> ----------
> From: Mark Ferneau[SMTP:[EMAIL PROTECTED]]
> Reply To: Discussion list for Java 3D API
> Sent: Thursday, November 30, 2000 12:36 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JAVA3D] BSP, Switches, Memory and Performance
>
> 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".
>
===========================================================================
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".
