Re: LOD structure and performance

New Message Reply Date view Thread view Subject view Author view

Allan Schaffer (allan++at++southpark.engr.sgi.com)
Mon, 2 Nov 1998 18:22:02 -0800 (PST)


On Nov 2, 11:40am, Stephen Maher wrote:
> I'm interested in comments on performance related to pfLODs and scene
> graph structure, as described in the following two cases:
>
> Tiled terrain with each tile having one pfLOD with numerous children (say,
> 10)
> VERSUS
> Tiled terrain with each tile having numerous pfLODs, each with one or two
> children (total children the same as in Case 1.
>
> Without doing exhaustive tests, I'd like to be reassured that Case 2 won't
> come back to haunt me.

I'd first say "it depends".

A high number of children per node (6+) means a larger aggregate
bounding sphere, and so the CULL and Intersect traversals are more
likely to have to visit each of the children to evaluate whether
they're within view / being hit, instead of just knocking off the
whole subtree with one bounding sphere test. By comparison, a low (1
or 2) number of children per group node means more groups to check,
guaranteed -- ideally you'd want more "work" to be done per check.

So no answer is ideal for every situation but I've always used ~4
adjacent children per group node as a rule of thumb.

Once the database has been modelled check your CULL stats for lots of
tested, but trivially rejected nodes. This means you're too heavy
with case #1 above. Lots of non-trivially culled nodes implies case #2.

I talked in some depth about this during my Performer Tuning lab at
the Developer's Conference last year, you're welcome to look through
the slides, which are online:

 http://www.sgi.com/Technology/Performer/presentations/euroforum98-pflab.sc

(showcase format)

This is a link from the Performer Tech Info page,

 http://www.sgi.com/Technology/Performer/technical.html

Allan

-- 
Allan Schaffer                                                allan++at++sgi.com
Silicon Graphics                               http://reality.sgi.com/allan

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Nov 02 1998 - 18:22:06 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.