Offering cash for a proper script!
I will pay anyone $100 if they can make me a script that can actually BAKE THE ACTUAL ROTATIONS of a figure that is:
- has limbs pointing at stuff
- and therefore undoes or zeros all the point at and constraint dials so that it is truly the rotation of the character's bodyparts that I am seeing
So all the script needs to do is:
- Scan the scene for anything with a "Point At" or "Constraint"
- Calculate the rotations relative to world space > and up the hierarchy of the figure so that you get the accurate rotation of the limb
- you don't have to take into account whether or not the point at or constraint dials are dialled in or not. Rotations are rotations.
- cycle past all the dials and put them to zero (along all relevant keyframes)
- then load all the relevant rotations as keyframes (and please not ALL the morphs too like poser does, that's needless keyframe bloat)
So basically a script that does: what you see is what you get. Poser's Bake Transforms fail, just in case you were wondering.
PS: I am serious about the $100
PSS: if it could work within a given range too, that would be fab!
are you saying that when you open the Joint Editor, (with a Joint or a figure selcted), in the lowest part of the window,
You see => Figure => Zero Rotations does not work?
It should ZERO-out all rotations on the figure selected.
Or am I missing something from your explanation?
best regards, Tony
What I also do is "lock" certain Joints.
Like knees and elbows joints where we humans can not do a "side-side" movement.
But you have to set these limits manually in the Joint parameters of the knees and elbows. => Euh, shins and forearms. LOL.
The same with figures that only have a toe bone/group. Lock the twist and side-side on those. (Set limits to 0.000)
Best regards, Tony
@vilters no its totally different.
For example, I'm building a framework with all kinds of mechanical actions working on it, incl bullet physics. There are a number of ways to harness all those rotations, but the easiest and most ideal way would be to just get the figure to get its correct bodyparts pointed at some of these moving points, or even constrained. When the figure is set up within the frame, its magnificent, but the problem it it takes a lot of time to set up. So I wanted to make some animations using this framework, bake it down to simple rotations of the figure and save those as animations... but alas Poser doesn't bake it down properly at all. I have the feeling that the bake transforms was meant only for conforming clothing or something, because in my situation its totally useless.
PS: I cannot use the framework in a scene either because conforming clothing just totally dies on the constrained figure (M4 & PE).
Ironically, its probably the limits that is the problem. I work with nothing else but limits, and I've seen several examples of how poser struggles with limits when using IK, and thus also stuff like this. I cannot imagine this stuff to be that hard to calculate... or maybe I'm wrong
Tony, I think I understand and it's not what you're thinking.
Ero wants to use secondary pose capabilities, such as "point at", to create various rotations, without manually performing those rotations. The prop he's using to make the limbs point at a position in space is not going to be saved, nor applied to any future figure. The intent is to bake the pose as a saved preset pose file in the library, and Poser doesn't do this correctly. If you save a pose involving pointing, the pose is not saving the effective rotations, because those are not reflected in the pose dials AT ALL, and the pose dials are what gets saved.
As an illustration, here is an Andy rendered in three frames of an animation. I have his upper arm, lower arm, and hand set to Point At the ball, each with a different % of point at. I can move the ball and the arm appears to naturally move ALL BY ITSELF in such a way as to mimic the action of throwing the ball. (Or any other movement I would like, where the three parts are evolving in a logical and natural manner.) Note that the apparent rotations, as reported by the dials, do not indicate any change in rotation. The change is not involving the visible controls that one would use to create the same rotation without the ball. Attempting to set up the three rotations by manually moving them is far, far more tedious than what I've set up using the Point At feature. Yet, because Poser's pose file saving is busted, that is what you have to do.
If I save this pose (or animated pose sequence), the resulting file is garbage. Any attempt to load it on a fresh figure results in either the original static pose (as if the point at never happened) or some sort of spasm - the rotations are bizarre. Poser is not capable of handling its own math - which is astonishing to me, by the way. Really SM - come on.
Meanwhile, I'll look into the Python API and see if the necessary calls exist.
I am relieved to see that I'm not the only one noticing these things. Yes they should fire their mathematician... there's plenty more problems in Poser of the same nature.
I seem to recall this dude that lived a few THOUSAND years ago... Pythagoras maybe...? SM cannot get right what he sucked out of his thumb while plucking olives?
Ugh. So far the only solution I can see is going to involve quaternions. I've never used these and I don't know the math. Reading ...
Poser must have a module that can read any given point in any given space. So if you have a dude getting pulled around by a ball, at some keyframe I would imagine that you could (should) be able to request the XYZ of that point. So starting from the contrained limb, it will have an origin point and an end point, and with that you can work out the vector. With that vector you can work out the angle it should have with respect to the limits of its parent, and so forth you keep subtracting untill you're at the root bone... or actually the universe... which brings me to another thing I don't understand: why don't limits work properly with IK on? I can twist M4's hand into a vortex of vertices despite his limits. That would make a script like this hard to write because then the angles become seriously guesswork...
With that vector you can work out the angle it should have with respect to the limits of its parent
No! I have determined that the joint setup includes an "alignment" that means you can't work out the angle between two bones without taking that into account. Also, the order of the axes must be taken into account and there are six ways this can be set.
There is no simple mechanism to go from orientation of a limb relative to its parent backwards to find what settings of the joint would produce that orientation if you ONLY pay attention to the orientations of the limbs. Or more specifically, to the quaternions, because that's all I can read out.
I have made some progress. I have quaternion math for some things working in a consistent way with the models. However, I haven't yet figured out how the joint alignment and axes order must be dealt with exactly. Also the quaternion library I selected doesn't have any reverse method to give back the joint rotations I'd need to plug in to produce the given orientation.
All I can do at present is accurately read out the orientation and position of the limb and make some other prop align with it using xRot, yRot, zRot on the prop, and only because I specifically know that the prop has no non-zero joint alignment values and is using YXZ axes.
Note, the default or standard order, YXZ, corresponds to the airplane mnemonic
First we taxi (yaw or Y rotation)
Then we take off (pitch or X rotation)
Then we bank to a new heading (roll or Z rotation)
Formulas for converting a quaternion to YXZ are easy to find. I haven't found the other 5 formulas.
Aha - I just found a nice paper on converting quaternions to Euler angles. (Note - the rotations we type into Poser like Twist or Bend are Euler angles)
I just found a different python library that has all 24 (!!!) Euler combinations (we only use 6). But it's not object oriented so not as convenient to use.
But I'd rather use it than type all that stuff myself. The license seems to indicate I can redistribute it as is so I should be able to use it.
dude if you pull this off, you'll be my hero for all time, and you'll have proven a point too... and I'll be $100 poorer :D
I just hope you don't hit 'gimbal lock' ;)
I'm not taking the money. It's an interesting puzzle. I'm doing it for the same reason people do sudoku.
do you have any idea how many sudoku books you can buy with $100? ;)
Also there's humor in science. In the Euclidean space paper I linked above there is this:
"For an Euler Rotation Sequence where the first and third axes are the same, called a repeated
axis sequence, singularities occur ... The mechanical manifestation of this mathematical singularity is the dreaded "gimbal lock" of the stable reference platform made infamous in the movie Apollo 13.
This was not a serious problem for mariners and most aeronauts before the advent of the space age; if a ship had achieved a pitch angle of 90 degrees, the fact that its Euler angle derivatives had become infinite was probably of little concern to the crew.
haha, nice catch!
that movie was brilliant btw
Respect BB, you have all my respect.
And I used to call the Advanced Material Room ; "The Math Room".
Now we are on another planet.
just wait until BB breaks out Fourier Transforms!
Ha-ha-ha, I am a digger, but this is not my cup of tea. (at all)