You can't possibly need that many. By declaring 64 entries of 3x4 you are also breaking the vs_1_1 rules. vs_1_1 only guarantees 96 4-float constants (although some cards support more). Your 64-bone entry requires 174 (64x3) 4-float entries on its own, before you even consider other parameters. So your shader is not guaranteed to be compatible with all vs_1_1 hardware. And when it fails, it won't fall back nicely because you're breaking the rules.
Either reduce the number of bones (highly advisable), or change to vs_2_0 (which supports 256 4-float consts) and accept that poor owners of vs_1_1 cards will have to use software skinning.
Actually, speaking of hardware skinning, on my bosses machine, with a GF FX card (not sure which one) the walking robots demo (from the pre-compiled windows binaries off the site) tries to use hardware skinning in DX9, and all we see is streaks off into infinity.
We used a different renderer (GL I think) and it used software and was fine.
58 bones? Your animating the ant's feelers, I bet. Bugger that
[Edit]PS: When will I get off Newcomer status! [/Edit]
i'm not a designer of this model. and target is to make this all run on at least one card so vs_2_0 support is not a problem.
i already changed to "profiles vs_2_0 arbvp1". but still fourweights shader makes some bodyparts stretch to 0,0,0 .
@PeterNewman: that may be a driver issue, I have an FX card and it's fine on Dx9 here.
@vdl: Does Entity::mNumBoneMatrices reflect the right number of bones? Also, put a breakpoint on line 253 of OgreGpuProgram.cpp, to see if all 58 matrices are being passed to the program.
If they are, it may be an issue with the 'four weights' program itself. I would appreciate a test model since I have none myself (I appear to have lost the one I used to test the software skinning version fo multiple weights)
Sinbad, I wouldnt be surprised if its a driver issue. My bosses machine is still running the original Dell drivers it came with. "If it ain't broke, it don't need updating", more or less.
I cant test it on my machine, its a GF4MX, and it barely does the dot3 bump demo (drool...)
PeterNewman wrote:Sinbad, I wouldnt be surprised if its a driver issue. My bosses machine is still running the original Dell drivers it came with. "If it ain't broke, it don't need updating", more or less.
Heh, stock-installed drivers are almost always way old, and drivers have bugs all the time (believe me, I know ). There were certainly plenty in the early versions of the nVidia 5x.xx driver branch. Update. Now.
I know this, you know this. He know this? Heh. I'll have to wait till me and the art guy produce an incredible demo that works on our machines because our drivers are up to date, and barfs on his. THEN he will update. (Good boss, just doesnt like fixing what dont need it, in his mind.)
Now we just need something that will look good on a GF4MX and barf a GFFX... oh, a challenge!
I am having a set of character which use 4 weights and 33 bones. I would like to be able to use the hardware skinning on them.
I did make the change in the .cg for having more bones:
e.g:
/*
Four-weight-per-vertex hardware skinning, 2 lights
The trouble with vertex programs is they're not general purpose, but
fixed function hardware skinning is very poorly supported
*/
void hardwareSkinningFourWeights_vp(
float4 position : POSITION,
float3 normal : NORMAL,
float2 uv : TEXCOORD0,
float4 blendIdx : BLENDINDICES,
float4 blendWgt : BLENDWEIGHT,
out float4 oPosition : POSITION,
out float2 oUv : TEXCOORD0,
out float4 colour : COLOR, // Support up to 33 bones of float3x4
uniform float3x4 worldMatrix3x4Array[33],
uniform float4x4 viewProjectionMatrix,
uniform float3 lightPos[2],
uniform float4 lightDiffuseColour[2],
uniform float4 ambient)
{
// transform by indexed matrix
float4 blendPos = float4(0,0,0,1);
int i;
for (i = 0; i < 4; ++i)
{
blendPos += float4(mul(worldMatrix3x4Array[blendIdx], position).xyz, 1.0) * blendWgt;
}
// view / projection
oPosition = mul(viewProjectionMatrix, blendPos);
// transform normal
float3 norm = float3(0,0,0);
for (i = 0; i < 4; ++i)
{
norm += mul((float3x3)worldMatrix3x4Array[blendIdx], normal) *
blendWgt;
}
norm = normalize(norm);
float3 lightDir0 = normalize(lightPos[0] - blendPos);
float3 lightDir1 = normalize(lightPos[1] - blendPos);
Everything goes well on the animation side but some of my characters get culled. E.g they disappear time to time based on the camera position. If i use the software skinning it goes well.
Does someone was able to try hardware skinning with more than the vs_1_1 24 bones limitation?
Crashy wrote:hello, I'm just askin a little question: is it possible to "reunificate in one object" meshes loaded separatly,in order to increase FPS?
I have the same question. Is there a way within Ogre to combine objects into one mesh..... so that we can deal with the art tools using simple meshes but have ogre combine them (during program startup say) so that we can get good performance out of the 3D card?
You could use Ogre::StaticGeometry to let Ogre batch handle them. This has of course some trade-offs as outlined in the API documentation. As long as you use different materials for the meshes batched in the StaticGeometry the performance boost won't be too big. Best way would be to layout the unwrapped texture on one texture for all batched models so they can use the same material but access different parts via their uv coords.
tanis wrote: Best way would be to layout the unwrapped texture on one texture for all batched models so they can use the same material but access different parts via their uv coords.
Maybe someone could develop a compiler like tool (wtih Ogre?) to compile mesh objects into a larger mesh? Using the same coordinates as ogre... so you could layout using ogre then not have to go back to the previous tools.
tanis wrote: Best way would be to layout the unwrapped texture on one texture for all batched models so they can use the same material but access different parts via their uv coords.
Maybe someone could develop a compiler like tool (wtih Ogre?) to compile mesh objects into a larger mesh? Using the same coordinates as ogre... so you could layout using ogre then not have to go back to the previous tools.
This is a job for your modeller. StaticGeometry will do it for you too, but this is mainly designed for large numbers of repeating objects. Optimising individual meshes is a job for your artists.
sinbad wrote:
This is a job for your modeller. StaticGeometry will do it for you too, but this is mainly designed for large numbers of repeating objects. Optimising individual meshes is a job for your artists.
Sinbad... I respectfully say that there are many of us programmers here who can do layout geometry work and would rather not have to get the artist involved every time we want layout and model swaps (change out this model with this...).
Plus, think of the case where you are using Ogre as a tool to build your world... do you really want to have to go back to the mesh editor?
I know how it is typically done (mesh done in model editor)... but trying to think outside the box here
I mean once you have the art laid out in ogre, how hard would it really be for someone who understands this stuff to build such a compiler (external to OGre, but uses Ogre's coordinate system)? Anyone looking for a project... $250 bounty to start?
This will only be useful if you have objects you want to merge built out of approximatly the same materials, though. Otherwise, merging them is not possible.