Can anyone point to material which help reduce the number of state changes, eg gl.glBindTexture(). Preferably so that it could sit with say a binary partion tree.
Thanks,
SNR
I recently put a lot of thinking into the kind of optimization you are referring to. I am using an aabb/oobb tree structure instead of a bsp tree but for the following ideas it shouldn’t matter, so I’ll just try to describe my thoughts and the conclusions I have drawn (weighten validity with my rank as yabb newbie 
)
When I traverse my tree, I pick primitives (well, actually groups of primitives stored as vertex arrays for faster rendering) according to current visibility. What I end up with is a long list of vertex arrays which require rendering. Now there are two things to set for each array, material (render states, like texture) and transform matrix. So I had the choice to sort by material, and save on material changes, or sort by transform group, and save on matrix operations.
After reading a lot of incoherent stuff on the expense of loading matrices versus that of setting texture states, I came down on the side of sorting by material. The reason is that I can set a transform simply by loading my custom transform matrix into OpenGL, because as I have a scenegraph structure, I always know exactly how to transform for a given set of primitives. State changes, on the other hand, are massive, make that massive, because I do detail mapping, cube mapping, shadow mapping and projective lights. So the question was to save some glLoadXXX calls or to save dozens of glTexXXX calls … easy decision.
If you have a structure where you have to track your transforms using glRotate, glPushMatrix etc. and, at the same time, have fewer state changes than I have, perhaps you could try sorting by matrices. However, with today’s multitexturing demands, I would think that sorting by material is the way you should do it generally.
Hope this helps
Wolfgang