Sign in to follow this  
YasinUludag

Vertex buffer layout <---> Input layout

Recommended Posts

Hey, I'm new here :)

Getting right on topic, my mesh compiler compiles a mesh producing the final vertex and index buffers, optimizing whole lots of stuff at compile time.

It also generates a description (BLOB) of what the buffer contains such as [POSITION, FLOAT4, COLOR, FLOAT4, TEXCOORD, FLOAT2]. Just enum values.
Now i can use this description to construct the appropriate InputLayout in directx 11 to actually work with this buffer at runtime.

But I noticed something. Say the shader vertex input structure ONLY needs POSITION and COLOR. Even if the generated InputLayout contains those in addition to TEXCOORD, NORMALS, BINORMALS the application runs just fine.

I thought the signature had to match on a 1-1 ratio, but it seems like as long as the InputLayout contains atleast the required stuff by the shader, it runs completely fine, even if I provide unused/undeclared stuff in the shader such as NORMALS, BINORMALS.

So is this valid? Instead of actually reflecting the shader and creating an InputLayout it expects, i'm creating an input layout out of what my mesh buffer actually contains, mapping it to the correct offsets, indices thanks to the enum values above, and if the shader doesn't declare them, no problem I can still run the same shader on that one mesh.

Of course now if the shader would expect NORMALS and the buffer doesn't contain it, thereby the generated input layout doesn't contain it, this would throw an error but that's another thing, maybe I can default point everything else that is missing automatically to offset 0 where position lies, so reading from those missing would give garbage or some weird looking output in the end.
Example: COLOR is missing in the vertex buffer so it's gonna be missing in the generated input layout aswell, so default COLOR semantic to offset 0 so it actually uses the POSITION instead.

Is this actually valid at all? It sure works though. The idea is I want to be able to work with several different vertex buffers in the same shader without crashing the engine or throwing errors. But I'm not sure if this causes alot of bandwidth problems.

Enlighten me please :)

Share this post


Link to post
Share on other sites
Yeah it's perfectly valid to have [i]more[/i] than the required vertex elements, so for instance you can use the same vertex buffer for depth-only rendering which only requires positions. It's only invalid if the shader requires a vertex element that isn't present in the vertex buffer. I've never tried adding dummy elements for vertex elements not present in the vertex buffer, but I don't see why it shouldn't work.

Share this post


Link to post
Share on other sites
[quote name='Yasin' timestamp='1318163897' post='4870773']
So is this valid? Instead of actually reflecting the shader and creating an InputLayout it expects, i'm creating an input layout out of what my mesh buffer actually contains, mapping it to the correct offsets, indices thanks to the enum values above, and if the shader doesn't declare them, no problem I can still run the same shader on that one mesh.

Of course now if the shader would expect NORMALS and the buffer doesn't contain it, thereby the generated input layout doesn't contain it, this would throw an error but that's another thing, maybe I can default point everything else that is missing automatically to offset 0 where position lies, so reading from those missing would give garbage or some weird looking output in the end.
Example: COLOR is missing in the vertex buffer so it's gonna be missing in the generated input layout aswell, so default COLOR semantic to offset 0 so it actually uses the POSITION instead.

Is this actually valid at all? It sure works though. The idea is I want to be able to work with several different vertex buffers in the same shader without crashing the engine or throwing errors. But I'm not sure if this causes alot of bandwidth problems.[/quote]your vertexbuffer can be bigger, but the vertex layout shall match the vertexshader, that's why you need to pass the binary blob to the creation function.

but you are right it's not very critical, the driver can fix that miss match, as you just provide too much date, I think if you set D3D to debug mode, it will report a warning about this.


In general, if you are unsure about some behavior of D3D, check with the debug runtime, it's a good reference point. I'm always developing in debug mode, it can save you quite some time seeking bugs due to wrong usage of the API (e.g. you just accidentally swap to parameters for a function and you won't get anything visible on the screen).

Share this post


Link to post
Share on other sites
Yup, and just to elaborate on the 2nd idea - I've implemented that in our engine. If the shader is expecting any component that's missing from the currently bound VB, we map all the missing elements to an additional VB on a second stream.That has a single float4, initialized with known (bad) values (so it's easy to detect in PIX), and we set up the instancing parameters so that all verts read the same data. It's low overhead, and makes things much more flexible during development, when people might be experimenting (or making mistakes).

Share this post


Link to post
Share on other sites
Hey, thanks all for your replies!

MJP Yeah I notices that too while experimenting and it works :)

Krypt0n thanks for your ideas! I already run in debug mode and I have no warnings about this, as MJP and osmanb said I think this works quite well for flexibility during development :)

osmanb thanks for the idea about a second VB this seems like a great solution which also provides flexibility I wanted in the first place! I like that the values are known and set by me instead of mapping to offset 0 on the main vertex buffer which would be vertex positions for me.

Thanks again!

Share this post


Link to post
Share on other sites

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