• Advertisement
Sign in to follow this  

Best setup for effect render loop?

This topic is 4575 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

I believe I know the answer to this question but I need to be sure. When rendering lots of geometry with the same effect is this the best loop setup?
begin effect

for each pass
	for each mesh
		set mesh specific constants
		commit changes
		draw mesh
	end
end





Or is this?
begin effect

for each mesh
	set mesh specific constants
	for each pass
		draw mesh
	end
end





I would think the first loop would result in less state changes, particularly if the effect were set to restore state.

Share this post


Link to post
Share on other sites
Advertisement
This REALLY depends on what you're doing. In some cases, the first would be more efficient, and in some, the second.

If, for example, all your meshes use the same vertex buffer, and the same texture, the first option is more likely to be faster, since each mesh would require less changes.

However, if each mesh has it's own VB and texture, and you have quite a few meshes, theres a good chance the second method would work faster.

Basicly, you're going to have to see which one fits your situation best, either by what's easiest to program, or by which runs faster (you're going to have to do some testing to figure this out).

Share this post


Link to post
Share on other sites
Ok, that makes sense.

So if I sort geometry by effect -> texture -> mesh the first loop would be better assuming that there are many meshes that share the same effect and texture.

The second option would work better for some what unsorted meshes.

Hmmm... I currently sort everything be effect -> texture -> Z guess adding the mesh check shouldn’t be much of a performance hit.

Testing this will involve a significant change to my renderer, its using the second method right now.

Share this post


Link to post
Share on other sites


Don't forget a mesh could be made of many materials. each material could have it's own effect.

based on that, i'de go with choice number 2.

Share this post


Link to post
Share on other sites
Quote:
Original post by vidalsasoon
Don't forget a mesh could be made of many materials. each material could have it's own effect.


This is a good point, and can easily be overlooked until you get a model that breaks your renderer [wink]

I have found that the easiest way to do this is to change the definitions of the common geometry objects in the rendering engine:

Mesh: A mesh is a group of vertices, all composed of the same effect. So in a mesh you don't have vertices 0-2000 using Effect1.fx and 2001-5000 using Effect2.fx.

Model: A model is a collection of meshes. This allows you to have models that are composed of multiple materials. An AnimatedModel can also contain animation info, such as bone transforms. A TerrainModel can contain dynamic LOD info.

Node: A node is a game-wide object that contains all information about a specific object in the game. Based on its type, it can contain multiple models (for multiple LODs). However, a Node like a Light probably wouldn't have any model. Node also contains all of the game-state info - like the character's health, velocities, ect...

If you redefine your game objects, it may make your rendering pipeline much simpler and easier to understand.

Share this post


Link to post
Share on other sites
My definition of a mesh is the same as circlesoft.

I'm not using D3DX mesh objects at all.

All geometry is stored in a scene graph which breaks everything down. Geometry nodes have renderable leaf nodes, each of which has a vertex and index buffer (both of which may be shared by other renderables) and a set of attributes (one of which is the effect). The renderer never sees models; it only sees renderable nodes with their attributes. And before the renderer sees the renderable nodes they are extracted from the scene graph and placed in a sorted display list.

My renderer is very simple and has only one code path (well... as simple as it can be with all the stuff it supports).

So, I don’t need to worry about meshes having multiple materials, once the renderer gets a display list, I'm sure all meshes in each subset have the same texture, effect, and now maybe mesh data.

Thanks for the input all, I think I'll attempt to rework the render loop so each pass renders multiple meshes if their attributes are the same.

Now that I think about it, I do have one special case system that I may be able to eliminate. I always hated having a mesh special instancing loop, now maybe I can merge my standard render loop with the instancing loop.

Share this post


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

  • Advertisement