[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Undefined qsort behavior
- To: firstname.lastname@example.org
- Subject: Re: Undefined qsort behavior
- From: Steve Baker <email@example.com>
- Date: Thu, 05 Dec 2002 17:09:31 -0600
- Delivered-to: firstname.lastname@example.org
- Delivered-to: mailing list email@example.com
- Delivery-date: Thu, 05 Dec 2002 19:51:12 -0500
- Mailing-list: contact firstname.lastname@example.org; run by ezmlm
- References: <20021124110121.GC2021@ypisco.com> <3DE0EE31.email@example.com> <3DE1733E.firstname.lastname@example.org> <3DE19C32.email@example.com> <20021125191244.GD27874@fysh.org> <3DE2B388.firstname.lastname@example.org> <20021129180109.GB26555@fysh.org> <3DEF8287.41A19@gbl.com.br> <3DEFCE42.email@example.com> <3DEFBAE3.F9C9026C@gbl.com.br>
- Reply-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
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 () )
...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: <email@example.com> WorkEmail: <firstname.lastname@example.org>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net http://tuxaqfh.sf.net