I noticed that HLSL can use a D3DXEffectStateManager which will call a SetFVF before the rendering begins. I take that this FVF is the composite of the requested elements being transfered from the App to the Vertex program. So, what i'm wondering, is if HLSL will do this for us, then why create /set a vertexDecl, or even set and FVF (which according to the DX docs, are the two most costly calls) maybe i'm missing something in terms of understanding wrt vertex decls? thanks FROG!

FVF and vertex declarations describe your vertex data. They describe for each element (position, normal, diffuse), it's stream, data format, and offset (position is 3 floats at offset 0 of stream 0, normal is 3 floats at offset 12 of stream 0, etc.).

A shader may only require position and diffuse, but the hardware needs to know where that data is, and what format it's in. Whether or not you've got normals between position and diffuse makes a big difference. Whether your position is float3, or compressed into a D3DCOLOR makes a big difference.

HLSL and .FX files don't contain FVF or decls, because it's the wrong place for them. The data required for a shader is the MINIMUM an FVF or decl may contain. You may include more elements. You may choose non standard formats for the elements that are required.

Quote:
HLSL and .FX files don't contain FVF or decls, because it's the wrong place for them.

So why does SetFVF get called during a Shader->Begin()? That implies to me that some sort of FVF data has to be calculated / stored in the shader..

FROG!

The docs don't say what the FVF is for in ID3DXEffectStateManaged::SetFVF(). It certainly can't describe your data, as an effect won't know it. It may be an FVF indicating what the shader requires, allowing you to see which data your vertex stream is missing, but an FVF isn't enough data to describe all vertex data cases. An FVF can't indicate that you have 2 diffuse colors for example, while a decl could, so that's likely not it's use.

Perhaps it's just there for cases when an effect DOES specify an FVF, as a way of passing that information along. The idea of an effect setting the FVF on the device is just totally broken, and the docs don't supply enough information to explain what they intended the SetFVF callback to be used for.

I'd just throw in a breakpoint and see if it's called on effects that don't try to specify an FVF. If it is called, I have no idea why, or what it's purpose could possibly be.

If you really want to know, you can ask on DirectX Dev, the official DX mailing list where Microsoft developers can try to explain themselves. If you don't want to register on there, but you really, really want to know, I can ask around on the private MVP newsgroups.

Why is the idea of a shader setting the FVF a bad one?

From what I've seen, the FVF requires that your structure be set up in a specific order, so that the enumeration can just set offsets. Where as the decl allows you to move your data around, and use the interface tags. If your vertex struct is compatible to pre-dx8 drivers (ie, you keep w/ the fixed function structure type) then the FVF would be identical to the Decl, so, a shader setting that really wouldn't be a problem..

anyhow, i'll jump on the mailing list. Thanks!

FROG!

If your data is compatible with an FVF (same types, and offsets, no tangents, etc.) then yes, an effect could represent that as an FVF. However, say you have an effect which doesn't require normals. Your shader will now have an FVF without normals. If you attempt to use this FVF and your vertex buffer actually DOES contain normals, then things stop working. The effect only knows the minimum required vertex elements. It doesn't know their offsets, or their types. It doesn't know what data you have that isn't required for this effect.

"Ah, but what if I declare my full vertex as the vertex input, whether I use each element or not" you say.

There are some effects that you're going reuse over multiple models, which may have differing vertex formats. Embedding an FVF in the effect means you'll need an effect per vertex format. Leaving out the FVF means the effect will just automatically work on every model whose vertex format contains the needed elements, regardless of their offests, types, or other data which may be present.

Putting an FVF in the effect moves the effect from "works on all vertex formats" to "works on specifically crafted models". I can't think of any reason you'd opt to incur this sort of penalty. In DX8 a shader was tied to one specific vertex format. In DX9 they removed that limit. Putting an FVF in your effect effectively restores that limitation. Thus... I say "FVF in effect = bad".

Humm.. seems logical.

thanks NTNBET.

FROG!