Jump to content
  • Advertisement
Sign in to follow this  
ElFrogo

FVF and SetDcl not needed in HLSL?

This topic is 4872 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 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!

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!