Re: [Plib-users] Bug report

[Steve B. <sjb...@ai...>]

Fredrik Sandström wrote:
> 
> On Sun, 1 Apr 2001, Steve Baker wrote:
> 
> > Per Liedman wrote:
> >
> > > Interesting and annoying. Should we just refuse to load too large models?
> >
> > More than 65535 vertices in a single ssgLeaf is "A Bad Thing" anyway because
> >
> It crashes at the 10922:th (int / 6) vertex....

Ick!  I'd forgotten about that.

> ...which still qualifies to the
> "Bad Thing" category but is quite common for 3ds meshes. I've got a big
> neanderthal human skin which contains just above this number of vertices.
 
Well, perhaps - but it's still a bad idea to store that many vertices in a
single ssgLeaf.  Think about the situation where your Neanderthal is half
on screen and half off.  You have to weigh the cost of stuffing half of
those 10922 vertices down the graphics pipe - versus the cost of a handful
of bounding sphere tests.

When the whole mesh is entirely on-screen, the bounding sphere tests are
wasted (but even a dozen of them will be negligable compared to the cost
of redundantly fetching and stuffing all those vertices.  But when the end
of the Neanderthal's nose is the only thing on screen, those few extra
tests will make the model run a thousand times faster.

So, I think you should aim to keep your triangle meshes under a thousand
vertices - with modern T&L hardware.  With older pre-T&L hardware, you
should keep leaf nodes down at a few dozen vertices since a bounding
sphere test is *FAR* cheaper than drawing even one triangle more than you
need.

> Well, it's more the incompatibility of the int return type of the possible
> number of vertices and the actual short counter limit that I feel is the
> bug.

I disagree on that point...the number of vertices is an integer value (in the
mathematical sense) - if I choose to return a number with a larger potential
range than the actual range, that's my business.  If you were measuring objects
in inches that could only be a foot long - you wouldn't demand that I define a
4 bit variable to hold the number.  The original C manuals said that 'int' is
the most *efficient* type on whatever machine you are running on - so you should
only use a 'short' where storage space is at a premium.  I think that's a *good*
rule and I try to stick by it.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net
                         http://freeglut.sourceforge.net