Original Post
The use of spatial-"sorting" routines, such as BSP-trees and Quad-trees and Oct-trees and what-have-you, seem to be immensely popular these days.
Unfortunately, in API''s such as OpenGL state-changes, like changing the current texture, are pretty expensive procedures, and sorting poly-rendering order by location it is not unrealistic to suppose that the current texture is changed as often as once for every 2 or 3 rendered surfaces.
So it seems tempting to base the rendering order on textures, and thus render all the polygons textured with a particular texture before moving on to the next texture.
The problem is that doing that restricts you to using some sort
of depth-buffering technique, and z-buffering isn''t exactly a free operation either.
So, my question is this: How high overhead is incurred by changing the current texture umteen times per frame compared to using a z-buffer? Is it, in effect, worth it to render polygons based on which texture they are mapped with (and use a z-buffer for depth), rather than doing e.g. BSP-trees?
I realize that BSP-trees have other uses than merely rendering-order (such as simple collision-detection, view-culling, etc.), but I''m not really worried about that here.
Any thoughts on this?
-Neophyte
- Death awaits you all with nasty, big, pointy teeth. -
