d3d9 equivalent of D3DXFVFFromDeclarator?

[Misha Koshelev]

Dear All:

Thanks a lot Henri for your wonderful D3DXDeclaratorFromFVF patches.

It is wonderful to be exposed to the "right" way to implement this
function.

I am starting to look at D3DXDeclaratorFromFVF, as this would be the
next step before implementing ID3DXMesh.

I am looking again at d3d9, but feel like I am running in circles a
little bit trying to chase down where convFVF and convertedDecls is
coming from.

If you have any hints/advice, much appreciated. If there is a better
place to look as well (like wined3d), please let me know.

Thank you!

Misha

[Henri Verbeet]

On 28 August 2010 02:44, Misha Koshelev  wrote:
> I am looking again at d3d9, but feel like I am running in circles a
> little bit trying to chase down where convFVF and convertedDecls is
> coming from.
>
> If you have any hints/advice, much appreciated. If there is a better
> place to look as well (like wined3d), please let me know.

We only convert from FVF to declaration in d3d9 / wined3d, not the
other way around. Converting from declaration to FVF may be a little
harder, but essentially you'd do FVF to declaration conversion in
reverse. I.e., you consume declaration elements from the declaration,
and check if they (exactly) match something that can be mapped to an
FVF.

Suppose for example that you have the following declaration:
{
    {0, 0, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_POSITION, 0},
    {0, 12, D3DDECLTYPE_D3DCOLOR, 0, D3DDECLUSAGE_COLOR, 0},
    {0, 16, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_NORMAL, 0},
    D3DDECL_END()
}

You'd check the first declaration element, and see that is matches
D3DFVF_XYZ. Then you look at the next and see that it matches e.g.
D3DFVF_DIFFUSE. The next element would match D3DFVF_NORMAL, but you
can't have that, because normal data should come before color data in
the vertex buffer, so this declaration can't be mapped to an FVF.
I.e., ordering of declaration elements matters, you can't have holes /
padding, etc. It may be interesting to test if just the order of the
data in the vertex buffer matters, or also the order of elements in
the declaration. Example:

{
    {0, 0, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_POSITION, 0},
    {0, 12, D3DDECLTYPE_D3DCOLOR, 0, D3DDECLUSAGE_COLOR, 0},
    D3DDECL_END()
}
and
{
    {0, 12, D3DDECLTYPE_D3DCOLOR, 0, D3DDECLUSAGE_COLOR, 0},
    {0, 0, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_POSITION, 0},
    D3DDECL_END()
}

describe the same vertex buffer layout, but may behave differently for
D3DXFVFFromDeclarator().

[Misha Koshelev]

On Fri, Aug 27, 2010 at 10:53 PM, Henri Verbeet  wrote:
> On 28 August 2010 02:44, Misha Koshelev  wrote:
> > I am looking again at d3d9, but feel like I am running in circles a
> > little bit trying to chase down where convFVF and convertedDecls is
> > coming from.
> >
> > If you have any hints/advice, much appreciated. If there is a better
> > place to look as well (like wined3d), please let me know.
>
> We only convert from FVF to declaration in d3d9 / wined3d, not the
> other way around. Converting from declaration to FVF may be a little
> harder, but essentially you'd do FVF to declaration conversion in
> reverse. I.e., you consume declaration elements from the declaration,
> and check if they (exactly) match something that can be mapped to an
> FVF.
>
> Suppose for example that you have the following declaration:
> {
>    {0, 0, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_POSITION, 0},
>    {0, 12, D3DDECLTYPE_D3DCOLOR, 0, D3DDECLUSAGE_COLOR, 0},
>    {0, 16, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_NORMAL, 0},
>    D3DDECL_END()
> }
>
> You'd check the first declaration element, and see that is matches
> D3DFVF_XYZ. Then you look at the next and see that it matches e.g.
> D3DFVF_DIFFUSE. The next element would match D3DFVF_NORMAL, but you
> can't have that, because normal data should come before color data in
> the vertex buffer, so this declaration can't be mapped to an FVF.
> I.e., ordering of declaration elements matters, you can't have holes /
> padding, etc. It may be interesting to test if just the order of the
> data in the vertex buffer matters, or also the order of elements in
> the declaration. Example:
>
> {
>    {0, 0, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_POSITION, 0},
>    {0, 12, D3DDECLTYPE_D3DCOLOR, 0, D3DDECLUSAGE_COLOR, 0},
>    D3DDECL_END()
> }
> and
> {
>    {0, 12, D3DDECLTYPE_D3DCOLOR, 0, D3DDECLUSAGE_COLOR, 0},
>    {0, 0, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_POSITION, 0},
>    D3DDECL_END()
> }
>
> describe the same vertex buffer layout, but may behave differently for
> D3DXFVFFromDeclarator().

Thank you for the thorough explanation.

One point of clarification if possible.

The need for D3DXFVFFromDeclarator() from the standpoint ID3DXMesh is
for the GetFVF() function.

It seems, per dlls/d3d9/tests/vertexdeclaration.c test_decl_to_fvf
that the same functionality (to return an FVF from a device) exists in
d3d9 as well.

I was wondering how this is done, and whether a similar mechanism
would be acceptable for ID3DXMesh?

Thank you
Misha

[Henri Verbeet]

On 28 August 2010 23:35, Misha Koshelev  wrote:
> One point of clarification if possible.
>
> The need for D3DXFVFFromDeclarator() from the standpoint ID3DXMesh is
> for the GetFVF() function.
>
> It seems, per dlls/d3d9/tests/vertexdeclaration.c test_decl_to_fvf
> that the same functionality (to return an FVF from a device) exists in
> d3d9 as well.

Possibly. If you look at the tests in (d3d9)
test_fvf_decl_conversion() you'll see that only the first two
declarations return anything other than 0 (D3DFVF_XYZ and
D3DFVF_XYZRHW), and those are marked as todo_wine. This is
"implemented" by vertexdeclaration_init() *not* setting convFVF, and
IDirect3DDevice9Impl_GetFVF() returning "decl->convFVF" when a vertex
declaration is set. So declarations created by the application will
always have 0 for FVF, while the ones created by getConvertedDecl()
will have a non-zero FVF associated. It may well be the case that the
test is simply flawed; I wouldn't call any of the declarations that
return a 0 FVF reasonable. Most of them don't include position data,
and the ones that do can't be expressed as an FVF at all.
Nevertheless, the simple fact is that d3d9 doesn't currently implement
conversion of vertex declarations to FVFs.