Loading constraints VS jme3 limitations

Hey everyone,

recently I was preparing for implementing inverse kinematic constraint for blender importer.
But I came accross some problems that could occur during constraints loading and I am afraid that I will need to add
some limitations to the constraint loading system.

Large part of the constraints depend on some target. For example a bone in object_1 can be constrained by the movement of bone in object_2. Because the importer transforms blender actions into jme3 animations it makes actions very much independed from one another.
The constraints are baked into the bones’ tracks but when I come accross a situation like the one mentioned before I do not know which action from object_2 should be used to bake constraints for the bone in object_1 because the target bone in object_2 might move very differently in each of its actions.

So I have an idea, and would like to know your opinion about it, to limit the constraint loading only to the situations when bone is targeting a bone in the same skeleton. Then for each action I could easily determine how to bake the tracks for a bone.

Very similiar problem is with objects’ animations. If a node’s constraint tagets another node how should I bake it if the target node has an animation defined ?
The node can only have one spatial animation. Should I use it for baking or should I use the static transforms of this node ?
The same question is for bone targeting a node.

Another solution (even though rejected before if I recall correctly :wink: ) would be adding some sort of ConstraintControl. But it must have been added to the core of jme so that everyone would use it. This would solve the baking problem for constraints with target because the control would alter movements during rendering.
If I remember there was someone who already made some sort of IK control :slight_smile: I wonder if it still works and is being developed.

Please let me know what do you think about it. I would love to add IK constraint but as I see it the constraints system needs some preparations first :wink:

Cheers,
Kaelthas

@Kaelthas said: Another solution (even though rejected before if I recall correctly ;) ) would be adding some sort of ConstraintControl. But it must have been added to the core of jme so that everyone would use it. This would solve the baking problem for constraints with target because the control would alter movements during rendering. If I remember there was someone who already made some sort of IK control :) I wonder if it still works and is being developed.

Kaelthas

First, thank to your devoted effort in this problems. I’ve wait for this since your post about constrainst a while ago.

As an 3d animator, I want to use blender’s constrainst the most in 3 things (consider 3 level of difficulties) :
1) Bake Rigged Bone animation -> Normal Bone animation =>
This should NOT be difficult! If in some situation the rig is two complex, go to 2)

2) Preserve that Rig system to use in the engine (Ex: IK for foot, spine, facial animation…) . =>
Idea: I thought about a python script which can make sure every Blender to JME3 import process success. That’s it! The script checked and cleaned un-support things in Blender files and make JME3 smoother its import action. One more step, the script can also clean the dependencies of Rig system to make sure the target engine can understand. This is how we often do it in 3DSMax to import to Orge before with MaxScript.
I can help writing this if you looking for some help.

3) Automatic rigging! I’m not kiding. This is current solution to have both Animation and IK from Blender to JME3. Image you have a clean T-Pos Character, and you name the bones appropriately, you can travel the bones and add IKControl in java code. (Not just in Blender). Then the rig is still pretty neat and workable. No imported constrainst!

Please dont overkill the problem, because consider Blender a big issies, this one may be the biggest feature so far.
In fact in the industry, they don’t really like the idea of keeping rig system in game engine because it consider SLOW! But time passed by and the situation changed.
Now hopefully we keep some light-weight rig and bake or delete completely some heavy-weight constraints. After all, this is still a game engine, not a real animation engine. We need animation for game, it should be run smoothly indeed.

That’s my POV. Glad to hear from you and the other.

Yeah, we can simply add a python script that runs in blender and tells / helps the user to bake and adapt their animations maybe :slight_smile: The IK is mainly useful for posing and content creation so I agree with @atomix generally.

On the other hand we can inform user after loading what has not been supported.
I always log a warning when some feature is present but not supported either by importer or by JME.
I can always create a list of such warning that can later be viewed by user or displayed by JMP for instance.

As for the complex bone systems. I can of course abandon the IK constraint ans simply not support it. But I think that the more models we load (without
loosing the performance of the engine) the better.

Yes ofc we’d have to do that at the importer level, just that we could also supply tools to fix these common issues quickly :slight_smile: For many things it will be no problem at all to quickly bake the IK to an animation and if its not good just redo it…
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless theres emotes that hint otherwise or theres an increased use of exclamation marks and all-capital words.