[Bf-committers] Q about poses/channels + A from Ton + follow-up Q

[Ton Roosendaal]

Hi,

OK... cool feature! But I suggest you take a different approach then.  
If you like this to be an action/nla feature, you should only evaluate  
the data that comes from actions and nla, and not force the  
armature/pose to recalculate. That latter will only bring you (and  
Blender!) big troubles, especially since we want a proper dependency  
handling and very strict & consistant flow of recalculus of data only  
on singular occasions. (meaning; a where_is_pose() call inside of NLA  
is not allowed!).

By using action channel data only, you also benefit from the pure  
quaternion information in pose channels. Interpolating quaternion  
values is much more advanced than using derived information from  
matrices.

-Ton-


On 18 Nov, 2005, at 18:04, Roland Hess wrote:

> Ton wrote:
>
>> With Toni I've looked at a nice Python API call to do "arbitrary"
>> actions. He now has a call like this (forgot the real naming);
>>
>> Object.Pose.extract_from_action(Action, framenr, blendfactor)
>
> I looked at that code yesterday. The version of pose.fromAction() I  
> saw calls extract_pose_from_action, which is what I'm already doing in  
> my code. I've found that the pose_mat's from the extracted pose's  
> pose_channels show only the identity matrix, though.
>
>> This is unclear to me, it would help if you can indicate how that
>> functionality fits in the current system we have.
>
> Here's a full explanation (and I mean full, sorry it's so long, but I  
> didn't want continued vagueness on my part to further confuse things)  
> of what I'm working on, and why I need to get accurate pose_mat's from  
> pose_channels, given an arbitrary action and frame for an armature  
> object.
>
> Let's say I have this setup in the NLA:
>
> http://www.harkyman.com/animprop/matchbone01.gif
>
> Both the actions "ReachDown" and "Backflip" are full-body actions, and  
> the feet at the end of the "Backflip" action are at a different  
> location in object space than the feet at the beginning of  
> "ReachDown". If I use normal NLA tools, both feet will slide along the  
> floor when transitioning from the end of "Backflip" to the beginning  
> of "ReachDown", creating unrealistic animation.
>
> The feature I am building examines the action of the NLA strip above  
> the "ReachDown" strip, corresponding to the place in time of the first  
> frame of "ReachDown":
>
> http://www.harkyman.com/animprop/matchbone02.gif
>
> What happens in the GUI is that the user sets a "MatchBone" on the  
> "ReachDown" strip. What happens in code is that the bone position of  
> the MatchBone (in this case the main bone of the left foot, for  
> example) is determined in object space at both the first frame of the  
> "ReachDown" Action and the frame of "Backflip" (in this example it  
> lines up with frame 23 of "Backflip") that is in line with the  
> beginning of "ReachDown" in the NLA timeline.
>
> The difference is found between the object-space matrices of the  
> MatchBone in the different actions at the given frames (1 for  
> "ReachDown" and 23 for "Backflip"), and cached within "ReachDown"'s  
> NLA strip. This caching is cumulative, so that you can have entire  
> chains of NLA strips, each possibly using a different MatchBone to  
> match it's starting point to that of the preceding strip. When NLA is  
> evaluated for display, the cached matrix of only the final relevant  
> NLA strip is applied. When used with blendin in the NLA strip, it  
> gives a smooth, anchored transition between Actions that may or may  
> not line up properly within the armature's object space. This in turn  
> allows you to build Actions without regard to where they take place  
> within object space and align them in NLA - great for creating  
> libraries of actions, and even better (later) for putting together  
> animation procedurally.
>
> Because the matrices are cached within the strips, and only the last  
> one is applied at display time, the feature is very fast in effect.  
> Recalculation of the caches takes place on NLA edits (resizing strips,  
> moving strips, etc.).
>
> To make this work, I need to be able to cause Blender to fill the  
> pose_mat matrix for the pose_channel that corresponds to the  
> appropriate bones. Since Blender will not be displaying these poses,  
> and in fact they will be evaluated while an armature is under control  
> of the NLA system, I don't think that the DAG is the way to go.
>
> I almost think that I'm going to have to, for each action, temporarily  
> set the armature object to evaluate the action while ignoring NLA,  
> setting cfra to the action time (frame 23 in the "Backflip" example),  
> evaluate the armature object, copy the matrix for the bone in  
> question, then set everything back to its original state. In fact, it  
> seems like that's what was done in drawarmature.c for ghost armature  
> drawing. Is that the route I'm going to need to take on this, or is  
> there a more direct way?
> --  
> Roland Hess - harkyman
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org