Constraints for constraints

Contribution Depot
1

Hey everyone,



I’m currently working on refactoring the constraints system for blender loader.

The current version has some errors and is not good enough for many models.



But because blender is a huge issue and (at least now) has more features than jme allows, I will have to skip some of them

just because the implementation is not possible or would now be too complex to implement.



So my question is: how to constraint the constraints :). In other words what features could be skipped (at least for now).



Lest have a quick look at what blender offers.

  1. Constraints can be applied to: object node (containing mesh, ligh or camera, armature) and to bones.
  2. Constraints work for static objects (all kinds mentioned above).
  3. Constraints work for moving objects (bones and object nodes).



    How the things look like in jme3.
  4. Objects are imported as follows:

    a) object nodes: mesh → Spatial, Lamp → Light (different kinds), camera → Camera, armature → Skeleton

    b) bone → Bone

    In JME3 the classes: Spatial, Camera and Bone can have constraints applied, but the Skeleton cannot because it has no ‘Transform’. The same goes for some of the Lights (but not all).

    So here are my first questions:

    1. What should I do with Light constraints ?? Apply only to some of the Light descendant classes? Not apply to any? Wrap light into a Node an then apply transforms ? (the worst move in my opinion)

    2. Should I apply constraint to camera ? Is it necessary ? Or maybe I should create an empty class for camera constraint logic that will not do anything and will be ready for future implementation (this is a nice way to prevent crashes when someone applies constraints to camera so I would prefer this one)?


  5. This one is not very troublesome. The only problems with this are mentioned above (not all classes can have constraints).


  6. Here is the difficult part. Blender loader creates two types of animation: spatial and bone animations.

    Many of the constraints have target object specified. It means that the constraint uses the current transform of the taget object to modify the animation.

    With static objects there is no big problem. Troubles begin when target objects are moving.

    If the constraint’s owner have tracks I can try to modify them. If it hasn’t I create him non modifying tracks and then apply the constraint.

    And this gives us the new bunch of questions.

    1. Should I apply constraints for a bone that targets bone in a different skeleton ??

    2. Imagine we have two cubes. The owner of the constraint is not moving and the target have tracks and can be animated (object animation). This will force me to add tracks to the owner and then apply constrains. But in blender when I play animation of the target object the owner is also moving (because it has been constrained). In JME3 when I play the target animation the owner will remain still unless I play his animation too.

    Should I not support such situation ? Or maybe I should give a warning that to get the required result is to play both animations ?





    If I have more questions I will definitely ask. If something is unclear (hopefully not everything :wink: ) please ask I will try to explain it in a different words.



    Cheers,

    Kaelthas
2

I don’t understand why you have to do this at all as blender should care about the constraints and the resulting animations should just contain the results of the donstraint solving. If theres no animation theres no need to export anything. Generally the loader still fails too often with basic imports and should rather concentrate more on getting the base data (meshes, textures and animations) over without failing in trying to bake something (and if it does it should still import the data it acquired until then).

3

Constraints are solved when you export the model using Ogre exporter.

The raw blender file only contains the data for the animation as it would look like without constraints.

And constraints themself are stored separatly so I have to compute it myself.



And the reason I decided to do this is because many models fail because of the constraints.

I’ve recently started testing the loader using models from blendswap. Most of them crashed because the constraint system was inapropriate.



And as I have noticed one constraint (Inverse Kinematics) is quite often used in animation so it would be a good idea to support it in the future.



If you want I can add and entry to the BlenderKey that will allow to disable constraints loading but I would rather get the system to work and warn about unsupported stuff.



And by the way I’m still watching other things too and made several fixes just yesterday not connected with constraints :wink:

4

I see but wouldn’t it be easier to just bake the animation constraints? A half-assed solution isn’t really one at all. It should either support all constraints or none and expect abked animations…?

5

Baked constraints would of course be best solution. As I belive there is a python script in blender to do that, am I right?

Is it shipped with blender or does the user need to find it somewhere else ?



If you want I can discard the constraint system completely but I still belive that they should be there even if not yet fully operational.

Hopefully they will be in the future.





Btw. is there also a tool to bake textures ?? :slight_smile:

6
@Kaelthas said:
Constraints are solved when you export the model using Ogre exporter.
The raw blender file only contains the data for the animation as it would look like without constraints.
And constraints themself are stored separatly so I have to compute it myself.

oh god...that's something I didn't realize before, but it make sense that the blend file store all data and recompute them.....

What is unclear about your post is why you want these Constraints in?
1. As helpers to bake the data into JME anim system?
2. For them to be part of JME anim system?

Only 1. is affordable IMO.
So all my following answers will assume the "baked into animation" option

to answer the questions
InverseKinematic of course is the first constraint to support, but rotation axis constraints for bones are kind of mandatory too.

1. What should I do with Light constraints ?? Apply only to some of the Light descendant classes? Not apply to any? Wrap light into a Node an then apply transforms ? (the worst move in my opinion)

The best move in my opinion :p. We have a LightNode that is made for this. Just create an animation for this node and bind the light to it.

2. Should I apply constraint to camera ? Is it necessary ? Or maybe I should create an empty class for camera constraint logic that will not do anything and will be ready for future implementation (this is a nice way to prevent crashes when someone applies constraints to camera so I would prefer this one)?

same as 1 : CameraNode with spatial animation on it.

1. Should I apply constraints for a bone that targets bone in a different skeleton ??

Delicate matter...i'd say no...because users should keep their rigs as simple as possible....BUT...that's what the rigify plugin does...so in 2 clicks you can have a rig that has those type of constraints in blender....
Anyway the rigify rig was made for making animated models in movies, it's not really suitable for games. so i'd say : targeted bones must be in the same rig.

2. Imagine we have two cubes. The owner of the constraint is not moving and the target have tracks and can be animated (object animation). This will force me to add tracks to the owner and then apply constrains. But in blender when I play animation of the target object the owner is also moving (because it has been constrained). In JME3 when I play the target animation the owner will remain still unless I play his animation too.
Should I not support such situation ? Or maybe I should give a warning that to get the required result is to play both animations ?

erf....this one is touchy.....
There would be a way...that would be to make a special Track (the JME class) for this situation, this track would play the animation of the target.
The issue with this is that it's an open door to animation mayhem since one object would be able to play anim on other objects...
I'd say this is a small corner case, and i guess it won't occur that often. So the warning should be enough, and we could add a note about it in the Blender wiki page.

On a side note, not completely related, IK bones should not be included in the skeleton if they don't deform the mesh. They are just useless overhead in the skinning process. But of course the constraints they imply should be baked upon loading.

Of course all of this is open to discussion.
7
@Kaelthas said:
Baked constraints would of course be best solution. As I belive there is a python script in blender to do that, am I right?
Is it shipped with blender or does the user need to find it somewhere else ?

If you want I can discard the constraint system completely but I still belive that they should be there even if not yet fully operational.
Hopefully they will be in the future.


Btw. is there also a tool to bake textures ?? :)

Yeah. I get now why you "mirror" all this stuff in the importer.. I didn't want to sound too negative but if its only half of a solution it should at least be very robust and transparent else it will bring more issues like the one I mentioned. Btw I plan to add kind of a logging system to assetloaders so they can store different messages and warning about the import process that can be looked into after the import so you can kind of prepare logging these issues and implementing workarounds. Again, sorry if I came off too negative, its just that with blenders antics lately and the "unofficial" ogre exporter the asset import path is kind of a "nervous" topic atm ;)
8

@nehon

the constraints will work as they work at the moment :slight_smile: they alter the tracks in a way that the result should be as close to the one in blender as possible. They are not a part of jme anim system (although I came up with such idea and it was quite tempting :smiley: ).



Thanks for the information about LightNode and CameraNode.

But what do you think, should I wrap all lights and cameras in those nodes or only the ones that have constraints ??

I think that wrapping all would be better solution. It will give us less complicated implementation for the constraints.



@normen

in every part of the importer I found something that cannot fully support blender features. Mostly because JME3 does not support them. Blender has a very large features set and it is impossible to support them all. So actually there is no exception here that not all of the constraints will be supported (for example python constraint :wink: ). Nevertheless I think that it is good that such features as constraints (or modifiers) can be supported.

If I create a basic system now, that could be easily extended, then maybe in a future wise people will implement the rest giving us the full constraint set.

That is why I would rather keep the constraint system, although you’re right that there are many basic issues that still cause troubles. I’ll take care of them too :wink:

9
@Kaelthas said:
@nehon
the constraints will work as they work at the moment :) they alter the tracks in a way that the result should be as close to the one in blender as possible. They are not a part of jme anim system (although I came up with such idea and it was quite tempting :D ).

Well that's exactly what I call "baking constraints into animation" so that's perfectly fine IMO.

@Kaelthas said:
Thanks for the information about LightNode and CameraNode.
But what do you think, should I wrap all lights and cameras in those nodes or only the ones that have constraints ??
I think that wrapping all would be better solution. It will give us less complicated implementation for the constraints.

Yeah wrapping all of them would be better IMO.
10

What do you mean by bake the contraints? I am also having some trouble with importing animations with bone constraints into jme3.

11

http://bfy.tw/2lRv

12

Lol XD