Re: Undefined qsort behavior

[Steve Baker <sjbaker1@airmail.net>]

Miguel A. Osorio wrote:

>   Excellent, this is indeed better than what I had in mind. It seems that
> the detail I missed to get to your solution was that it's ok to group a
> set of states (textures, materials, etc); even if we have tons of
> textures and materials, the combinations for actual objects in the
> application is still small. I was thinking in general terms, like the
> problem was more of arbitrary combinations of states, which could yield
> a combinatorial explosion :)
Right.  The thing is that in most OpenGL implementations, the most
costly thing to switch is the Texture - and it's also the thing you
most often need to switch.  Hence, you pretty much end up with one
GeoState per texture.

HOWEVER:  If your artists are an undisciplined, unruly mob (as is
frequently the case), you may find that you have 14 different
GeoStates all identical except for a 1% difference in shininess...
this is to be frowned upon because it fscks up the entire system.

> You can't imagine how greatly this works out for me.
Sure I can - all implementations of 'rendering engine' asymptote
towards the same general solution space.

> > If you find there are a lot of empty buckets in your 'typical' scene,
> > then you might want to make a linked list of non-empty buckets so you
> > can skip over them quickly - but that's rarely a useful optimisation
> > because of the additional per-GeoSet testing...remember that there
> > are usually vastly more GeoSets than GeoStates.
> 	Yes, it's a good optimization, but not essential.
It may actually be a pessimisation - if there are only a couple
of empty buckets in each frame, the extra time taken to say:

     if ( bucket -> isEmpty () )
       skip it

...may be negligable compared to saying (for each GeoSet):

     if ( myGeoState -> bucket -> isEmpty () )
     {
       move the bucket from the set of empty
       buckets into the set of full buckets
     }

...because there are likely to be far more GeoSets than buckets.

But your application may be atypical and benefit from this change.

>  Sure, I already had that in mind, even with my original solution. I
> would treat opaque objects first, then the translucent ones in another
> operation. Of course, with your solution this comes out naturally, just
> as you said, just put those translucent buckets at the end.
...and you may still need to take special care if you decide to sort
the translucent GeoSet's by range or something...then your neat bucketing
scheme fails because you need to render by range order - even if you'd
prefer to sort by GeoState.

> 	Thank you very much for your suggestion, it really helped a lot.
Glad to be of service.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net>    WorkEmail: <sjbaker@link.com>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
           http://tuxkart.sf.net http://prettypoly.sf.net