render state management

Started by
2 comments, last by Richy2k 14 years, 3 months ago
What I'm concerned about is trying to render the scene with as few state changes as possible. For example, in an RTS with 1000 units of 5 different types, if we render all units of each type in a row we can render all 1000 units with just 5 state changes, but if we render them in some undefined order we could have up to 1000 state changes. I'm wondering what kinds of solutions people have to this problem. I know it's highly game dependent, but I'm willing to see what people have done for any type of game. Right now I'm thinking about having a scene manager that stores a list of all the things that need to be rendered, sorted by a "draw order". For example, the skybox would have a draw order of 1, and the terrain a draw order of 2, game objects would have a draw order of 100 or something, and special effects a draw order of 200. By rendering the objects based on their draw order you can avoid having to alpha sort some things. Alpha objects that are always close to the terrain, some special effects, etc, could have a draw order of 5, or something, and then they would always be drawn after the terrain, but before the game objects. With the objects all sorted by draw order, I could start drawing. Starting at the lowest draw order, I could cache any draw command in a bucket based on its render state (shader, texture, number of lights, whatever). I could have a specific number of buckets, like 5 or so, to limit the linear searching necessary to find the correct bucket. Anything with the same render state would go in that bucket. If I ran out of buckets, I'd take the most full (or least recently used or some other policy) bucket and flush its draw commands out to the GPU, then start filling it with draw commands with the new state. When I run out of objects to draw with the current draw order number, I'd flush all buckets and move onto the next draw order. Obviously I would have to profile to see what actually works best for my project, or if this brings any benefit at all. But it seems like a good way to reduce the number of state changes the device has to make, and with different bucket replacement policies based on my rendering patterns it could be pretty effective. I like this idea because it doesn't sound like a lot of work to implement. But I'm still wondering what you guys think? Any suggestions or advice? Maybe you could let me know what you've done before in your projects and what you found effective?
Advertisement
Hello.

That's batching. You group everything that shares rendering properties and render each group with the relevant states. Not much to discuss there. [smile]

What you have suggested seems fine for an RTS, but would not suffice for a world where the camera has more freedom of movement.
Batching! That's the word I was looking for. That should help me find some more resources about this type of thing.

Quote:Original post by zyrolasting
What you have suggested seems fine for an RTS, but would not suffice for a world where the camera has more freedom of movement.


I'm not sure why the system I suggested above wouldn't work for a game with more camera freedom? Does it have something to do with culling objects that can't be seen? Or are you talking about the draw-ordering thing? I can see how that doesn't work well for alpha-blendable objects in games with more varied cameras.
This popped up on my radar a while ago, and has been mentioned a couple of times on the forums recently. So far I've implemented this and it's covered me reasonably well - especially for depth sorting alpha blended objects. Should help reduce switching around your render states, but isn't the be all end all solution.
Adventures of a Pro & Hobby Games Programmer - http://neilo-gd.blogspot.com/Twitter - http://twitter.com/neilogd

This topic is closed to new replies.

Advertisement