Sign in to follow this  

Batching and the rendering of mixed-attribute vertex buffers

This topic is 4071 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'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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites

This topic is 4071 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this