Hi,
I keep on hearing a lot about how batching and sorting can greatly improve rendering performance. Can someone elaborate more on this?
I guess the properties which you can sort by are:
textures
shaders
vertex/index buffers
materials
render state changes
The problem I have understanding is all these properties together with batching may conflict. This seems to me an np-complete problem and may take more time sorting than just basically sorting at random. Am I missing something here?
Thanks.
sorting by material,shaders,textures, and batching
Started by dj, Sep 04 2005 08:18 AM
3 replies to this topic
#1
Posted 04 September 2005 - 08:18 AM
#2
Posted 04 September 2005 - 03:04 PM
It is not generally much work to sort like this. (An you wouldn't sort per TRIANGLE, but "object", where I define object as the biggest unit that share all these properties.)
Also, this tends to not change much from frame-to-frame. So you could (theoretically) sort a little bit each frame.
Also, this tends to not change much from frame-to-frame. So you could (theoretically) sort a little bit each frame.
#3
Posted 04 September 2005 - 07:20 PM
Hello,
I give you two examples.
Z-buffer allows to avoid back objects to overlap front object thanks to a test over Z axis. But even if occluded objects aren't displayed, they may have been sent to the buffer (if they passed the test because front objects weren't rendered yet). If you sort objects front to back, then you can avoid this because back object won't pass the test, since front objects will have been rendered already.
The other problem is the cost of changing states. Changing testure unit, material properties, and so costs much. If object are rendered in random order, then states will be switched often, while if you set a state and render all objects needing this state, they will switch less often.
Indeed it will cost even more to find the best solution, but there is no need to do so. All you need is reduce time waste. The book Real Time Rendering (a very good book by the way: I highly recommend it) has an interesting part giving some hints about how to track where a 3D program is wasting time.
I give you two examples.
Z-buffer allows to avoid back objects to overlap front object thanks to a test over Z axis. But even if occluded objects aren't displayed, they may have been sent to the buffer (if they passed the test because front objects weren't rendered yet). If you sort objects front to back, then you can avoid this because back object won't pass the test, since front objects will have been rendered already.
The other problem is the cost of changing states. Changing testure unit, material properties, and so costs much. If object are rendered in random order, then states will be switched often, while if you set a state and render all objects needing this state, they will switch less often.
Indeed it will cost even more to find the best solution, but there is no need to do so. All you need is reduce time waste. The book Real Time Rendering (a very good book by the way: I highly recommend it) has an interesting part giving some hints about how to track where a 3D program is wasting time.
#4
Posted 05 September 2005 - 10:39 PM
Quote
If you sort objects front to back, then you can avoid this because back object won't pass the test
If you find your shaders are becomming the bottleneck, you might benefit from a separete z-pass. It means you will render everything only to the z-buffer first, so not state changes at all. Then, you sort your stuff and draw it with zero overdraw.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users











