I can’t reproduce that.
=> maybe the problem comes from the model ?
EDIT: @FrozenShade : after double checking sc.isHardwareSkinningUsed() always returns false. Sorry I’m not sure I’ll be able to help
EDIT (2nd) : after triple checking it works on one of my models, but it looks as usual.
At the moment only one instance of a monster is present in 3d models tree.
But the model is loaded twice from assetManager: first time for initialization, where I read constant values (animation times etc) for my internal purposes. After that the model is loaded once again and placed on 3d scene.
Do you by any chance play the animations before setting the hardware skinning?
I had this kind of issues when switching on the fly between software and hardware skinning, because software skinning actually alters the position buffer.
Is that a problem ? If so, why ?
I couldn’t find much information other than the source code about hw skinning. I’m interested by any documentation on the subject.
Well that’s the question we’d have to answer if it was the issue
In short : software skinning is done on the CPU by computing each vertex transformation from the bone transformations. Then those transformations are applied to the position buffer of the mesh.
That last operation can be expensive especially if you have a lot of skinned models in your scene.
Hardware skinning consists on computing the transforms and sending them to the vertex shader and transform the vertex there before projecting it to screen. It’s a lot faster, but uses a fair amount of the allowed uniforms that you can send to a shader program.
I may provide models for which sc.isHardwareSkinningUsed() always returns false but I’m not sure it’s related to FrozenShade’s problem.
They all share the fact that they were made using makehuman et partially animated using makewalk …
So if you have some time to look at those models I’d gladly provide them to you. If you have no time or no will to look at them it’s fine I’ll stick to soft skinning.
ha …time…
I may provide some tracks to follow though.
I think that when you try to enable HW skinning and that it fails, it ouput a warning with some relevant information. you have to scrutinise the log.
What can happen is that your hardware doesn’t support the extensions needed for HW skinning (but that’s probably not the case since some of them are working).
Another track can be that there are too much bones in the skeleton and that that would generate too much data to be sent to the shader. Also not sure, but the number of vertices could be a problem too (if there are too much).
Maybe @Momoko_Fan can comment on that he knows a fair deal about HW skinning in JME.
Ok I see.
Now that I understand it a bit better I’ll take a deeper look at my models when I’ll have time too.
People think money is the rarest resource but time is even more rare Too bad we haven’t yet reverse engineered space-time.
@FrozenShade: I may try your model if you want me to do so but I can’t guarantee it will help.
Nah, I think it’s generally accepted that time is really the only resource. All life is about buying time or using time. Money is potentially the grease or catalyst but really it’s all about manipulating the finite resource of time we are given.
Before import, delete EdgeSplit Modifier - importer dont like it. I going to remove IK bones before final import for monsters. Workaround for IK bones and importer - it dont see deformations: keying visual position of yellow bones (in IK chain)
@nehon it does not changed anything. I tested it and I’m sure that I’m enabling HW skinning at the very beginning, before any animation is played.
EDIT: important question: does the animation animates when the geometry is outside camera’s view? I found that there is a problem, shadows on walls ‘jumps’ when I don’t look at the mob but they are ok when I look at the animating mob.
EDIT2: seems like it is true. When the mob is transformed by me (my own control changes its rotation) I can see the change on shadow. But when the mob does only the animation in loop, without any transformations, the shadow stands still… I really need a good workaround, even dirty one. Any idea?
EDIT3: I did the trick… In my own MainShadowRenderer (where I collect all other shadow renderers) I add a code in the PostQueue:
for (int i = 0; i < occluders.size(); i++)
{
Geometry g = occluders.get(i);
if (g.getName().charAt(0) != '_') continue; // Ugly test if it is an animated geometry
//TODO: test if it is close enough to the player's cam
Node n = g.getParent();
SkeletonControl sc = n.getControl(SkeletonControl.class);
if (sc == null) continue;
sc.render(_renderManager, _viewPort);
}
Say, how much dirty it is, and any idea to make it a bit more clean?
Yes, I know
But this one is much faster.
I’m using ‘_’ prefix in few other places in the code that executes every frame several times.
From the very beginning I try to optimize everything and I don’t want to waste cpu time. Even some of my nodes does not pass updateLogicalState/updateGeometricState to their children.