🔒 Locked

Sorting entities by texture ...

Started by paic Oct 21, 2005 at 9:07 AM 3 replies 750+ views

Original Post

Oct 21, 2005 at 9:07 AM

Hi, I have a conceptual problem about texture sorting. For the moment, my meshes can have a lot of subsets, each ones with different texture sets. BUT they are stored in a single vertex / index buffer. So each frame, I have a code looking like this one :


// set the FVF and the vertex / index buffers
m_pd3dDevice->SetFVF(m_FVF);
m_pd3dDevice->SetStreamSource(0, m_pVertexBuffer, 0, m_VertexStride);
m_pd3dDevice->SetIndices(m_pIndexBuffer);

for (int i = 0; i < m_NumSubsets; i++)
{
   m_pd3dDevice->SetMaterial(&m_pMaterials);
   m_pd3dDevice->SetTexture(0, m_Textures[0]);
   m_pd3dDevice->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, m_BaseVertexIndices, m_MinIndices, m_NumVertices, m_StartIndices, m_PrimCounts);
}

(To keep it simple, I assume all the materials use only one texture channel ^^) Well, now imagine I want to implement a renderer. Now, my meshes would pass their buffers, textures, etc. to a renderer. This allow me to sort all the data by texture (for example) But i'm stuck : a single vertex / index buffer uses many different textures ! So, thought about 2 solutions : 1) 1 vertex / index buffer == 1 texture set. So I don't have any more problems. The drawback is : I have a lot more SetStreamSource, SetIndices to do. And I now have a lot more small batches, which is not really good. 2) I sort by texture, but I don't consider drawing of an entire vertex / index buffer, only a subset. But this way, I'll have many redundant SetStreamSource and SetIndices. So, anyone has an idea on the performance issues of these solution ? Or can suggest me another one ? Well, thx in advance for any help / pointer ^^

circlesoft

Oct 21, 2005 at 11:14 AM

Quote:
Original post by paic
1) 1 vertex / index buffer == 1 texture set. So I don't have any more problems. The drawback is : I have a lot more SetStreamSource, SetIndices to do. And I now have a lot more small batches, which is not really good.

This is the right idea, you are just missing one important piece: software instancing. Instead of just storing one copy of the subset in the buffers at once, store multiple copies of them. This way, you can render multiple copies of the same subset at once.

To do this, each vertex has to have an InstanceID. This way, you can tell what instance each vertex belongs to. Your vertex structure may look like this:

struct VERTEX{   float3 position  : POSITION;   float3 normal    : NORMAL;   float2 texCoords : TEXCOORD0;   float  instanceID;};

Then, in the vertex shader, you can look-up all of the transforms and stuff based on that InstanceID. For example:

worldViewProjMatrix = wvpArray[ thisVertex.instanceID ];

The number of copies to store is up to you. It depends on the number of vertices your meshes have, how big you want the buffer to be, and how many meshes you are actually going to have to render. If a buffer doesn't contain enough copies to render all of the meshes at once, you can always just draw the same buffer twice.

paic

Oct 24, 2005 at 2:55 AM

Thx for the reply (couldn't check the forum during the WE ^^)

But I can't use what you say, I'm willing to use the FFP as much as possible (I'm the only "graphic programmer" and I can't possibly write the graphic engine, and all the shaders ^^''

MasterWorks

Oct 24, 2005 at 3:51 AM

Could you sort by texture and use a large dynamic VB/IB? I know they get good performance if done properly but I have no idea if this is appropriate at all for what you're trying to do.

paic

Oct 24, 2005 at 7:22 AM

Yes, I was thinking of using a system with dynamic VB / IB. But I don't think it's faster than using more smaller static VB/IB. Ahh ! I need to do a lot of tests, but I don't have time T_T

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.