This is a bit of an old topic, but it relates to two active bugs, 8357 (affecting Everquest) and 14608 (affecting Warhammer Online)
The rough summary of the situation is that these two games use d3dx9_30 and d3dx9_34 respectively, and at least the former uses ConvertToIndexedBlendedMesh.
Anyway, they both show an odd behaviour where if the device caps report MaxVertexBlendMatrices <= 2 (or <2 maybe) then the d3dx apparently generates odd behaviour and unrecognised vertex entries, the upshot being that the character's vertices all end up on the ground at the model's world transform.
If MaxVertexBlendMatrices is > 2 then the vertices come out fine, and everything seems to work.
A d3d trace from Warhammer Online indicates that D3DRS_VERTEXBLEND is only ever set to 0 (only tested up to the character select screen, which is the first screen where the bug is visible) both with and without the patch.
From what I understand from here and on MSDN, indexed multimatrix blending in the fixed function pipeline is generally emulated except on certain older ATI Radeon cards, so I guess that D3DX ConvertToIndexedBlended actually ends up emulating the index blending without actually using the D3DRS_VERTEXBLEND renderstates.
The current workaround is to patch Wine to report MaxVertexBlendMatrices 4, but that will cause bad behaviour in programs that do use the multimatrix vertex blending, as I understand.
Anyway, what I'm wondering is would it be worth throwing together a patch that implements the multimatrix blending in drawStridedSlow for cards that don't support ARB_VERTEX_BLEND (ie all of them under Linux)
If this is sensible, any pointers towards the right thing to do would be greatly appreciated, this isn't an area I'm massively experienced in.
The only other option I'm aware of is to await the shader-based fixed function pipeline replacement which might contain an implementation of the D3DRS_VERTEXBLEND renderstates.
The last time I'm aware of this being discussed was [1], in February last year.
[1] http://www.winehq.org/pipermail/wine-devel/2008-February/062433.html
The only other option I'm aware of is to await the shader-based fixed function pipeline replacement which might contain an implementation of the D3DRS_VERTEXBLEND renderstates.
I worked on a pipeline replacement using GL_ARB_vertex_program a few months ago but hit some roadblocks, so I never finished it. The main problem was that the performance was awful. Even in apps like 3Dmark 2000, which are hit rather badly by drawStridedSlow it resulted in a net slowdown. I am pretty sure my code can be optimized(the lighting code is *awful*), but it certainly complicates things if I have to be really picky wrt performance from the start to avoid causing regressions.
-
Paul TBBle Hampson -
Stefan Dösinger