Sign in to follow this  
deh0512

(MDX) GetDeviceCaps is (apparently) wrong about MaxVertexBlendMatrixIndex

Recommended Posts

Hi all, I've come across something I find to be a bit strange... My code for creating the D3D device is remarkably similar [wink] to the SDK. Reference the last few lines of CreateDevice and ChangeDevice in the SDK Framework class if you want to look at code. The machine in question is a laptop with an ATI Mobility Radeon HD 2300 card. During the process to determine what device settings are best, a call to Manager.GetDeviceCaps returns a Caps structure that tells me the MaxVertexBlendMatrixIndex is 37. A few (seemingly irrelevant) lines later, the device gets created. I'm using the same adapter and device type (hardware) parameters to the call to GetDeviceCaps and the constructor for the device. Here's the confusing part: the DeviceCaps associated with the device tells me MaxVertex... is 8. The SDK code seems to imply the GetDeviceCaps info is reliable enough that an application can expect to get a device with the specified capabilities. Any ideas why the device I'm creating doesn't have the same caps as GetDeviceCaps reports? I've considered the other parameters to the constructor might make a difference. Is there anything about the PresentParameters that would affect the value of MaxVertex... (that doesn't seem likely to me at all)? My constructor call is attempting to create a pure device with hardware vertex processing in this case, and no other creation flags are being set. The only other parameter is the window/control (which I doubt has any effect). I'm beginning to think matrix indexed skinning is a waste of time. Most hardware doesn't support it, and the cards that do just screw it up... That doesn't make me any less curious about what's going on here, though [smile]. Thanks in advance for any info.

Share this post


Link to post
Share on other sites
Well, a little research might have cleared things up before I posted...

The remarks about GetDeviceCaps in the documentation:
Quote:
The application should not assume the persistence of vertex processing capabilities across Microsoft Direct3D device objects. The particular capabilities that a physical device exposes might depend on parameters supplied to Device.Device. For example, the capabilities might yield different vertex processing capabilities before and after creating a Direct3D Device object with hardware vertex processing enabled. For more information, see Caps.


That still leaves things somewhat open-ended, but at least they tried to make us aware that GetDeviceCaps isn't always correct.

Share this post


Link to post
Share on other sites
Reflecting my PM to you (info for others)-

Prior to device creation on my ATI x500 series

caps.MaxVertexBlendMatrixIndices, via d3d object:
hal - 37
sw - 0
ref - 255

after device creation (hardware processing accepted):
hal - 37 (both from d3d->GetDeviceCaps and pDevice->GetDeviceCaps in case there's a difference for some reason :p )

Share this post


Link to post
Share on other sites
Hi.
The SDK say's this....
MaxVertexBlendMatrixIndex
DWORD value that specifies the maximum matrix index that can be indexed into using the per-vertex indices. The number of matrices is MaxVertexBlendMatrixIndex + 1, which is the size of the matrix palette. If normals are present in the vertex data that needs to be blended for lighting, then the number of matrices is half the number specified by this capability flag. If MaxVertexBlendMatrixIndex is set to zero, the driver does not support indexed vertex blending. If this value is not zero then the valid range of indices is zero through MaxVertexBlendMatrixIndex.

bit of interest is if you have normals do you.

If normals are present in the vertex data that needs to be blended for lighting, then the number of matrices is half the number specified by this capability flag.

Share this post


Link to post
Share on other sites
ankhd,

Yeah... I'd read that, and I do have normals. Last I checked, half of 37's not 8 though[smile].

I found some website (maybe not reliable) that said GetDeviceCaps isn't exactly reliable until a window has been created. It suggested creating a dummy window before calling GetDeviceCaps, then creating the actual window. I am setting up the device before creating a window, like the SDK. That may be the problem, but I really don't know.

Thanks anyway ankhd.

Share this post


Link to post
Share on other sites
Just use a shader. Anything that support blend matrices supports a shader, but not everything that supports a shader supports blend matrices. Blend matrices are gone in D3D10, along with the rest of the fixed pipeline. It just seems like an utterly pointless investment of your time.

You're trying to use a poorly supported feature, and that feature is only supported (for hardware vertex process) on cards supporting an alternate method, which is the accepted way forward.

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