I will be working on coding this tonight, I have already done some digging into the well documented cough ASE format regarding pivot points.
My use case is as follows. Essentially I am using fairly basic animation based on joints. The classic example of this is a human figure - with the arms attached to the body, and the legs etc.
Currently the ASE loader just loads in all the geometry relative to the origin. For example, if you have a box at (10,10,0) in your scene, it will be loaded in at (10,10,0). Attempts to rotate that box will result in it orbiting around the origin instead of rotating in place.
What I wish to do is load the box in relative to its pivot point which is normally the center of the box or an arbitrary pivot point set in MAX, then translate the box to (10,10,0). This way if you rotate the parent TG - it orbits, but if you rotate the child TG, it rotates in place - what we want.
Fortunately the ASE format supports this. I managed to find the attribute (*TG_POS) and it is used like so (example):
*TM_POS 48.2319 18.4686 -0.3690
That indicates that the model’s pivot is at (48,18,0). This is currently ignored by the ase loader however.
To achieve the desired behaviour using the current loader you would need to have all your “limbs” in separate ASE files - all positioned relative to the origin to the get your desired pivot point.
Adding this support in is not trivial - it changes the BranchGroup that the getModel() method would return. Instead of the BranchGroup simply containing the geometry it would need to contain some TG’s so that everything is in it’s correct place. The only way around it would be to convert the Geometry in the TG’s to the branchgroup but I’d rather avoid having to do that if possible.
Will anyone mind if the BranchGroup that they currently get using hte getModel() method has a few child TG’s in it? provided that the resultant BranchGroup appearance wise is essentially unchanged.
Now has nothing to do with groups. They are slightly more tricky pivot wise. As there are no attributes to the *GROUP node, but the group’s pivot can be exported as a helper object. This looks like so:
*HELPEROBJECT {
*NODE_NAME "Group01"
*HELPER_CLASS "Dummy"
*NODE_TM {
*NODE_NAME "Group01"
*INHERIT_POS 0 0 0
*INHERIT_ROT 0 0 0
*INHERIT_SCL 0 0 0
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 1.0000 0.0000
*TM_ROW2 0.0000 0.0000 1.0000
*TM_ROW3 -5.7069 1.1255 -0.3690
---> *TM_POS -5.7069 1.1255 -0.3690 <-----
*TM_ROTAXIS 0.0000 0.0000 0.0000
*TM_ROTANGLE 0.0000
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*TM_SCALEAXISANG 0.0000
}
*BOUNDINGBOX_MIN -76.9889 -16.2177 -13.6531
*BOUNDINGBOX_MAX 65.5750 18.4686 12.9151
}
NB. To export the helper objects you must have that ticked - this is currently not the default setting as recommended by the GSG. Indeed I was quite lucky to have stumbled upon it.
Each object in the group retains it’s original TM_POS - therefore if the concept of groups isn’t implemented nothing would change. I however would like to implement groups which was the original purpose of this thread -but now I would like correct relative translations as well. As such, I will be adding support for the *HELPEROBJECT as well.
I shall illustrate an example using a human.
The human has a body. Attached to it are two legs and two arms (due to an unfortunate accident the head and other body parts are missing). The arms have hands, and the Hands have fingers.
The TG tree is like so:
Body
___Arm
_____Hand
_______Fingers
In MAX and the ASE file, the fingers and palm would be grouped together into the Hand, which would be grouped with the arm and finally the body.
Using getNamedNodes, it will (if I make those changes) be possible to waggle the fingers. Using getNamedGroups, it will be possible to move the hand at the wrist or the arm or the entire model.
Before I charge ahead - are their any suggestions or comments regarding this idea?
If there is strong objection to these modifications in the current ASE loader I can fork the code - but I’d rather not do that and I can’t see how anyone would be disadvantaged by the changes.
Needless to say, I am not just going to merrily commit my changes - I shall post the modified code which people can test with their current code - and I’ll do up a few test cases. Once there are no issues then in it will go.
Cheers,
Will.
