From: Allan Schaffer (allan++at++sgi.com)
Date: 04/24/2000 12:58:02
On Apr 10, 2:29pm, Bryan Housel wrote:
> Since geosets use ushort* for the index lists, this limits the number of
> verticies, colors, normals, texcoords in an indexed geoset to 65536...
>
> Are there plans to increase this limit in a future release of
> Performer?..
Not too likely; geoset attribute sizes were originally designed to
keep the memory footprint under control, which is now more important
than ever given the large extent of many programs' scene graphs. In
addition there are backwards-compatability / porting considerations
that would make such a change undesirable.
But to the bigger picture: There's a multidimensional tradeoff to be
made with regards to geoset size, in traversal overhead vs isect vs
cull vs draw efficiency. Offhand I'd suggest that it all roughly
balances at a length of ~50-100 tris/gset or so; but t the point
being, 65000 is quite unbalanced.
Consider, in a geoset with that many triangles:
- ISECT is evaluated against the pfNode bounding volume as it
traverses the scene graph, but upon the final "leaf" of a
successful intersection the _specific triangle_ from the isect'd
geoset is found by linear search. This is the primary objection
to having such a large geoset.
- It's more common than not that a great number of the tri's fall
outside the view frustum and could have been culled, reducing the
DRAW workload.
However: If it's true that all the triangles are on-screen (ie a
very finely-tesselated object fully within view) it is more
common than not that the individual contribution of each triangle
is less than the size of a pixel. A lower-triangle-count LOD
could probably be used with no real change in visual quality.
> To get around this limit I am assuming that we can:
> 1. split the geoset into two geosets..
Given that length it would be better to split it into about 1000
geosets.. ;-)
Allan
(getting over jet lag..)
-- Allan Schaffer allan++at++sgi.com Silicon Graphics http://reality.sgi.com/allan
This archive was generated by hypermail 2b29 : Mon Apr 24 2000 - 12:58:17 PDT