• Advertisement
Sign in to follow this  

Optimizing the render pipeline

This topic is 4335 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This is the method I was told to use to render all objects in a frame: 1) Create a list of things that need to be drawn. 2) Sort the list so that the pipeline is well-optimized. 3) Draw all the objects from the list. On step (2), the list would first be sorted by which vertex shader is used to transform the vertices. This is because swapping to a different vertex shader takes longer than any other call to SetRenderState, SetFVF, SetStreamSource, etc. Objects that use the same vertex shader are then sorted secondarily by pixel shader because it is the next slowest render option to change. The list is then sorted to reduce the number times the following are render options are changed: vertex buffer, index buffer, texture, all the different render states, etc. Another important thing is to render transparent items last, which is fairly simple. Questions / Comments on that? So if you understand all that, I have a question. I think I can do all this fairly easy, its just a matter of what data the list contains. I'm assuming the list must contain ALL the data needed to render each object. This means that each entry in the list will need the following items to draw each object (these are the render options that the list will be sorted by, in no particular order): vertex shader pixel shader vertex buffer index buffer parameters to call DrawIndexPrimitive (vertex/index offsets, # of polys) texture (lets not multitexture for now) which lights to turn on for the object which render states to set for the object (transparency, zbuffer, projection matrix, etc) *World Matrix (each objects position/rotation) Anything else? (this is just a list off the top of my head) So, does this technique sound reasonable? *A little optimization I noticed while writing this: Lets say your game draws 20 cubes to the screen. Instead of putting 20 entries into the list, just put 20 world matrices in one entry and draw all 20 cubes with the same render states, etc.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by blaze02
On step (2), the list would first be sorted by which vertex shader is used to transform the vertices. This is because swapping to a different vertex shader takes longer than any other call to SetRenderState, SetFVF, SetStreamSource, etc. Objects that use the same vertex shader are then sorted secondarily by pixel shader because it is the next slowest render option to change.

Sorting implies doing this with some type of list structure. It is much easier (and faster) to do this with a simple tree. Check this out.

Share this post


Link to post
Share on other sites
Another factor to consider is that of semi-transparent geometry. If you're planning on using this then you will need to store two lists/trees - one of opaque geometry and another for the semi transparent stuff. Opaque geometry needs to be rendered (in any order) first, whereas semi-transparent geometry must be rendered back-to-front and after any opaque geometry.

Quote:
Original post by blaze02
*A little optimization I noticed while writing this: Lets say your game draws 20 cubes to the screen. Instead of putting 20 entries into the list, just put 20 world matrices in one entry and draw all 20 cubes with the same render states, etc.
The tree method that circlesoft suggests should be able to handle this one pretty efficiently. Upper nodes in the tree configure the geometry source (VB's, IB's, textures) and then you have 20 sub-nodes with the appropriate world matrix with a Draw**() attached to each of them.

I've been meaning to write up my notes on it, but an alternative to the tree and list approach is to use regular graph algorithms. I'm not sure if it's any more efficient, but it'll definitely work. Consider each vertex in a fully connected graph a combination of states required for a draw-call, and the edge weight is the number of steps required to transition between them. The problem then becomes an example of MST or TSP (okay, TSP isn't a nice problem to solve [lol])...

hth
Jack

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement