Skip to main content
gamedev.net
🔒 Locked

Sorting VertexBuffers?

Started by FxMazter 1 reply 600+ views
Original Post
FxMazter
FxMazter
Hi! I'm currently sorting my rendering accorting to Materials. Depending on which Shader/texture the material has. Now the thing is that I'm currently creating all my VertexBuffers "dynamic" in DX9. So basically now, lets say I have 3 meshes: Mesh1: Material1 VertexBuffer1 - Pos, Normal, UV Mesh2: Material1 VertexBuffer2 - Pos, Normal, UV Mesh3 Material1 VertexBuffer3 - Pos, Normal Here VertexBuffer1, 2 & 3 are SEPARATELY created VertexBuffers. And when It comes to sorting the Materials, there is no problem. The problem is that I have SO many SetStream(...) calls, even though the objects have the same materials. One SetStream(...) call for each Mesh. So I was wondering how you guys manage the creation of VertexBuffers ? I was thinking about something like this: Instead of creating a new VertexBuffer for each Mesh, I would let my implementation of CreateVertexBuffer manage all the VertexBuffers. I would then create a LARGE vertexbuffer for each new vertextype, that is requested. So, the above example with 3 meshes would be like: VertexBufferManager: VertexBuffer0 - Pos, Normal, UV & very LARGE VertexBuffer1 - Pos, Normal & very LARGE Mesh1: (a triangle) VirtualVertexBuffer - pointing to VertexBuffer0 with offset 0 Mesh2: (a triangle) VirtualVertexBuffer - pointing to VertexBuffer0 with offset 3 Mesh3: VirtualVertexBuffer - pointing to VertexBuffer1 with offset 0 Now for each material I would only need to make a certain amount of SetStream(...) calls. In this case: Material1: SetStream(..., VertexBuffer0, ...); for each geometry render it using the offset 3in VertexBuffer0 SetStream(..., VertexBuffer1, ...); for each geometry render it using the offset in VertexBuffer1 Material2: ... Would appreciate any thoughts on how this should be designed, will my design be flawed when updating vertexdata in the buffers? For eg. I want to update the vertexData in Mesh1: Lock(VirtualVertexBuffer)... This will lock VertexBuffer0 and thus it may not be used for rendering ? Do you think things like that will be a problem? Thank you!
emosoft05
emosoft05
do materials determine the vertex format, or is it mostly dependant on the mesh? this will probably determine how the manager should allocate vertex buffers. also how "dynamic" are your meshes? you may want to create two types of meshes. static and dynamic (or something that is less confusing to the dynamic flag on vertex buffers). basically static would be for vertex buffers that only need to be written to at load time, and dynamic would indicate that you may want to write to this buffer after its been setup. it might help resolve some of the locking situations.

if most of the locking is occuring with these "dynamic" meshes you should probably have the manager create seperate vertex buffers based on some other heuristic, perhaps something relating to render order (not in a front to back sense but in a stage sense. like world geometry might be one stage and character models might be another). if you aren't constrained by time, you may want to implement your idea as is, then try to identify if the locking problem occurs. try to find out which vertex data is conflicting with each other. this may help you determine how to setup the vertex buffer manager.
duhroach
duhroach
Sort your geometry by the shader first, then by sub materials, then by rendering format (lines strips etc.)
Then, combine geometry that have identical shader/mats/format into singular vertex buffers.

This usually has to be done during runtime, so that you can cull out all non-visible geometry, and make a best-attempt batch approach for the visible ones. So, 10 identical meshes can be batched into one draw call (and 1 set stream..)



~Main

Topic Locked

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

Sign in to reply to this topic.