#### Archived

This topic is now archived and is closed to further replies.

# Batching problem

## Recommended Posts

I haven''t been able to get an answer to this one yet, thought I might try phrasing the question a little differently. Say I have a simple model (under 50 vertices) that I want to render 1000 times in different locations. Everything I read says BATCH, BATCH, BATCH! Everyone seems to agree that 1000 calls to DrawIndexedPrimitive for only a few dozen tris each has a lot of overhead. What I don''t get is how to batch this? Don''t I have to change the world matrix before each model is rendered? If I batch everything into one buffer and DrawPrim, I don''t see how I can do that. And if I transform the vertices beforehand so that I don''t need any world transformation calls, doesn''t that completely circumvent hardware acceleration? As you can see, I''m totally screwed up here. Please help me see what I''m missing.

##### Share on other sites
One solution is to use a manager object. Basically, instead of having 1000 CFoo objects, each with their small meshes, have CBar objetcts, which group together the smaller CFoos into lists of the smaller objects, all sharing one buffer.

That may work for groups of static objects, like rocks for example, but what about moving objects I hear you cry, or even objects that need to do "something", like rotating to face the camera?

In this case I would suggest using a shader. Batch them into CBar objects again, (lists of CFoo objects), then you have 10 objects, each with a vertex buffer of some 5000 vertices each. Now, as you know what''s in the buffer, you can use a shader that takes whatever info you need to translate each CFoo.

Hope something here helps.

-Spiral

-- Give me a hard copy right there ---

##### Share on other sites
I would think have one and only one object with the actually mesh, that would be your model. Then for the actually "in-game" objects, you create each of the individually (which means they should be able to manage themself, positions etc) and have each of them point to the mesh object to draw.

##### Share on other sites
Note that you can''t batch this although it will be pretty damn more efficient to just go ahead and make X number of calls to render the object. Why? Video/System Cache FIFO buffers should speed it up quite a bit.

E.x.

//loop
Transform()
Render()

This is essentially same as vertex shaders, but will use T&L if it is available. You really have no other choice. I''d bet it be a lot faster than rendering 10k arbitrary models. You wont be using much bandwidth so you dont have to worry about that, only one model will be sent down to the v-card.

-------
"Programming is like sex make one mistake, and you have to support it forever."
Homepage: http://students.washington.edu/andrey

##### Share on other sites
"You wont be using much bandwidth so you dont have to worry about that, only one model will be sent down to the v-card." - >>> That is if the v-card has T&L.

-------
"Programming is like sex make one mistake, and you have to support it forever."
Homepage: http://students.washington.edu/andrey

##### Share on other sites
Another Option for batching is to have a static member VB/IB for your class.

class Mesh{static LPDIRECT3DVERTEXBUFFER8 VB;static LPDIRECT3DINDEXBUFFER8 IB;static DWORD last_vb;static DWORD last_ib;static DWORD num_mesh;}

If num_mesh==0 in the constructor the create the VB and IB. When you load a mesh you offset the Vertices and indices by last_vb and last_ib (and then add the vertex and index count of your mesh to that figure). Obviously this adds complexities elsewhere but you should be able to figure out how to get around them.

Neil

WHATCHA GONNA DO WHEN THE LARGEST ARMS IN THE WORLD RUN WILD ON YOU?!?!

[edited by - thedo on October 2, 2002 12:20:50 PM]

##### Share on other sites
Either I''m even thicker than I thought or I don''t think you understand my question.

I understand the concept of having one large buffer and pushing 1000+ vertices to the video card at a time. I could easily put the vertices for 500 rectangles into a single buffer. But what if each of those 500 rectangles is expected to be in a different location? At that point, don''t I HAVE to make 500 calls to SetTransform and DrawIndexedPrimitive. That''s all I''m asking.

Let me put it like this... is the primary reason for batching to eliminate 500 calls to DrawPrim or to eliminate changing vertex buffers 500 times?

##### Share on other sites
quote:
Original post by l99057j
Either I''m even thicker than I thought or I don''t think you understand my question.

I understand the concept of having one large buffer and pushing 1000+ vertices to the video card at a time. I could easily put the vertices for 500 rectangles into a single buffer. But what if each of those 500 rectangles is expected to be in a different location? At that point, don''t I HAVE to make 500 calls to SetTransform and DrawIndexedPrimitive. That''s all I''m asking.

Let me put it like this... is the primary reason for batching to eliminate 500 calls to DrawPrim or to eliminate changing vertex buffers 500 times?

Both. There are several concepts you seam to be intermingling here. First, it is (almost) always more efficent to keep memory on the video card rather then in system memory.

Second, state changes are always expensive. The order of expense is usually shader changes, then texture changes, then vertex buffer changes, then everything else.

I find it unlikely that you have a need to be transforming each triangle independently. You should be able to group them into fairly large sets. If this is not the case, you should do this transform host CPU side and put it in an DYNAMIC vertex buffer.

##### Share on other sites
[This is the conclusion of all the other answers]

quote:

At that point, don''t I HAVE to make 500 calls to SetTransform and DrawIndexedPrimitive. That''s all I''m asking.

Yes, unless you transform them yourself.

• ### Forum Statistics

• Total Topics
628300
• Total Posts
2981894

• 9
• 9
• 11
• 10
• 10