Batching and the rendering of mixed-attribute vertex buffers
Author
I've been doing a lot of research and experimenting with my rendering system, slowly understanding Yann's Material/Shader Implementation more and more (and in some cases indirectly coming to the same conclusions, which is optimistic).
One thing though, I think I understand but I'm hoping I don't since I want there to be a better way. :) In Yann's discussions, he talks about vertex buffers being divided into slots, with each slot containing the geometry for a single mesh, in whatever vertex format needed for the shaders that render it. This is great and solves a lot of other problems (especially when grouping the attributes sequentially within each slot for easy copying), but it also means that the entire vertex buffer (or large blocks of it) can't be rendered as a single batch. Because each slot (mesh) in the vertex buffer uses a potentially different combination of attributes, theres no way to know how to map them consistently into one draw call.
As far as I can tell, each slot has to be rendered individually (one draw call per slot), so that the API can be told what attributes and streams need to be setup. Which fits in with Yann's discussion about shader setup and cache filling. But I keep wondering if this is the only way, drawing them one by one, or if there is anything I'm overlooking. Is it normal for geometry within the vertex buffer to be drawn one at a time, despite being combined into one big buffer? Are the old rules about batching as much as possible no longer an issue?
Hey!
there is a R2VB animation sample in ATI SDK that deals with batching of dissimilar objects. Everything is encoded into a texture and converted to vertices on the fly.
there is a R2VB animation sample in ATI SDK that deals with batching of dissimilar objects. Everything is encoded into a texture and converted to vertices on the fly.
Author
panzer3001: Interesting, but that sounds like something very different from what I've described.
I already have all of the vertex data in the vertex buffer, grouped by attribute (all vertex positions, then all texture coordinates, then all normals, etc.). The problem is keeping track of the size and position of each of these attributes so that the renderer knows how to setup the stream states to get the mesh rendered. Each mesh will vary in size, and so will have different combinations of attribute sizes and positions within the vertex buffer. Some may use attributes that others don't use. This all needs to be known in order to be rendered.
Anyone? Any ideas on how this might be done? Keeping yet another struct for each mesh that is in the vertex buffer just to record a lot of attribute size/position data seems wasteful, but I haven't come up with any alternative.
I already have all of the vertex data in the vertex buffer, grouped by attribute (all vertex positions, then all texture coordinates, then all normals, etc.). The problem is keeping track of the size and position of each of these attributes so that the renderer knows how to setup the stream states to get the mesh rendered. Each mesh will vary in size, and so will have different combinations of attribute sizes and positions within the vertex buffer. Some may use attributes that others don't use. This all needs to be known in order to be rendered.
Anyone? Any ideas on how this might be done? Keeping yet another struct for each mesh that is in the vertex buffer just to record a lot of attribute size/position data seems wasteful, but I haven't come up with any alternative.
Firstly a disclaimer, its been a while since I read that thread [smile]
However they way I see/remember it is that given any given vertex buffer (the whole thing not just a single slot) filled with vertex data of all sorts and you want to render it, at this point there are two possibilities:
1) The vertex buffer is full with vertex data with identical semantics.
2) The vertex buffer has vertex data with different semantics.
In the first case you can render the entire buffer in one call right, so simple enough, forgetting about things such as per-object transformation etc.
In the second case (the case you seem to be most interested in) then you only want to render those portions of the buffer that are of the same semantic anyway, since the slots were filled by the shader your about to render with in the first place. In this case you could render each slot separately, or if your slot manager is any good then theres perhaps a good possibility that some, if not all, of those slots are contiguous anyway and you can render them all in one go.
Is that any good? Im just recalling this from memory.
I think the main point of having larger vertex buffers isnt so it can all be rendered in one call its so that it is already in VRAM when it is necessary to render it, so rendering individual slots isnt too much of a performance penality as far as i can remember.
However they way I see/remember it is that given any given vertex buffer (the whole thing not just a single slot) filled with vertex data of all sorts and you want to render it, at this point there are two possibilities:
1) The vertex buffer is full with vertex data with identical semantics.
2) The vertex buffer has vertex data with different semantics.
In the first case you can render the entire buffer in one call right, so simple enough, forgetting about things such as per-object transformation etc.
In the second case (the case you seem to be most interested in) then you only want to render those portions of the buffer that are of the same semantic anyway, since the slots were filled by the shader your about to render with in the first place. In this case you could render each slot separately, or if your slot manager is any good then theres perhaps a good possibility that some, if not all, of those slots are contiguous anyway and you can render them all in one go.
Is that any good? Im just recalling this from memory.
I think the main point of having larger vertex buffers isnt so it can all be rendered in one call its so that it is already in VRAM when it is necessary to render it, so rendering individual slots isnt too much of a performance penality as far as i can remember.
Hi, guys I've been following this for a while as well, can anyone post the relavent links (to past threads) on the subject again? I've done a reinstall and forgot to back up my old favourite folder.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
