Animation Sets : can anyone get these to work correctly?
@anomalaus Thanks, this was a lot of good information.
I have one follow-up question:
What do you use them for? Do you use them to export partial sequences? As far as I can tell, you can select rows and frame ranges and that's all an "animset" actually is -- ranges of frames across certain rows (aka parameter dials)
eclark1849 last edited by eclark1849
@h.elwood.gilliland Is there anyway to easily set up and save Walk and flight paths in Poser? It would be extremely convenient if you could set up a Camera flight path to follow a character down a hallway or just have a camera fly down a hallway on it's own and save those paths to the library.
I could parent it to a character like this, but I have little to no control over the movement of the camera then.
@eclark1849 Have you explored the Path Palette? This is a way to create a path that you can control separately to an object's keyframes. We specifically supported this for cameras as well as physical objects and figures. It is probably an area we are enhancing with additional features in an upcoming release, but the feature should work fine with the current version (11.1.0 or newer)
eclark1849 last edited by
@h.elwood.gilliland I did try and use it. It was rather difficult for me to understand and all I wanted to do was create a circular path around a figure. If the path was a little more like the way Poser currently let's you create a walk path it would give you a lot more control.
@eclark1849 The "Walk Path" feature barely works. The paths are actually not that bad once you get used to them. You create a path, move the endpoints to where you want it to start/begin, then you can add additional nodes from the palette and move those to control movement to various waypoints. Make sure to set the begin/end frames early on. I suggest giving it another go, it's way more powerful than the Walk Path feature, as it lets you move any object. Wim was able to create planes landing and all sorts of movements. Rafael made a space car move with it. You can also then combine it with keyframing to do more subtle movements and tweaks.
anomalaus last edited by anomalaus
@h.elwood.gilliland I am a heavy user of what was originally labelled "Morphforms" in the DAZ V4 era. They currently appear as "Master Parameters" in Poser's API (valueParms when saved in pose, character and scene files). I use them as shortcuts for posing multiple limb and torso actors with one dial driving valueOperations on joints and associated morphs. Default library pose saving routines in Poser currently just save rotation and translation transform parameters, morphs (targetGeoms and their controlling valueParms) can additionally be saved as an all or nothing selection, with Body transforms distinguished separately from limb transforms (I assume, as a distinction between figure pose, and figure location.). AnimSets then came along and appeared to be a finer grained filter for what pose information is saved, but currently only work to filter the list of actors whose parameters are saved. Great if you want to save a pose which will only affect a figure's arms, when applied, but less useful, if you want to exclude all of the figure shaping full body morphs from the pose, or, as I do, rather than start by pose individual limbs, use Master Parameters on the Body to shortcut prototyping the general pose, before refining it with subtle limb rotations. Many of these Master Parameters will move a pair of limbs in relation to each other, e.g. scissor/swivel/roll/yaw.
AnimSets are the perfect place to store the "Pose Type" information that I want to filter poses with for Shape vs Attitude, but the understandable assumptions about workflow, made in early versions of Poser have now become restrictive. We need to be able to hide the tedious tasks of posing figures (visit every actor and set every transform parameter) and make more use of Master Parameters. (I know that dragging limbs in the GUI is a useful shortcut, but it can be unpredictable and non-deterministic, and can become uselessly unresponsive when a scene is straining the platform's memory limits. It's a lot easier to remember and repeat a few dial settings when prototyping poses, than exactly recreate a pose in the GUI if you have to reset and start again.)
If I have a library of poses categorised by pose style (standing, sitting, crouching, lying, etc.) and limb subsets (arms only, legs only, head and torso, etc.), I want to be able to mix and match (these sitting legs with those standing arms and that torso/head attitude) poses on a single figure without impacting the character defining full body morphs I've already dialled in, and vice versa, change character without affecting limb attitudes. I want Poser to make it easy for me to create these poses, without having to subsequently open them in a text editor and tediously strip out the morph or transform categories I don't want. AnimSets can do that, if Poser actually uses the information in them (these parameters in, those parameters out, scales and shaderNodeParms and hidden parameters included if I want). (Hidden parameters especially, as their values can be unexpectedly corrupted by interpolation)
As I noted, Poser's standard pose saving routines currently ignore the AnimSet information except to filter actors. The parameter list is overridden by the dialog's check box settings, and scales, etc. are never saved. Nor is the frame range information stored in the AnimSet ever used when saving, it gets immediately overwritten by the library frame range selection dialog (though that is less of a concern for me). Perhaps an option to only use the selected animSet's parameter and range information would be a useful addition to the save dialog, if it can override or skip the subsequent check box and frame range (use one or the other method, not both).
Until the day AnimSets fully integrate into the pose saving process, I will continue with my scripts, though I'm still dying for an UnaffectedValueFrame() method to extract a parameter's dial setting from an arbitrary frame, other than the current frame. ;-)
@anomalaus Some good info there, too. The concern I have is that there is overlap between "AnimSets" and "Animation Layers" .. couldn't much of this be achieved simply with "Animation Layers" as a feature to isolate things? I'm not sure how the mix and match can be achieved without file hacking. I personally feel you shouldn't need to use a text editor to modify poses, but I guess a lot of people do and it's been a part of the workflow since way back.
From what I've gathered, AnimSets was implemented around the time they supported VRML, for reasons that are now no longer relevant. Recently added "Keyframe Categories" feels like yet another chance at overlap. I feel like there is a lot of odd similarities between these features pointing at each of them being not quite enough of a solution to solve the real problem, so AnimSets may be an area for improvement.
I'd love to tell you what I'm working on right now but it's best if we just wait and see. I will say that I've read everything you've said and want to figure out the best step forward. Thanks.
anomalaus last edited by
@h.elwood.gilliland there's no problem with where the information is stored within the currently open scene, the issue is with how you filter that information during the save pose to library process. Animation Sets are already an established feature of the library save process. When you click on the Select Subset button, you get to choose the actors to save from the scene hierarchy, or one of the AnimSets, which contains more information than just a hierarchical list of actors. The parameter (and frame ranges, which I don't currently bother with) list contained in the AnimSet provides a symmetrical parallel to the detailed parameter selection process available when saving facial expressions to the library (though far less tedious when one has literally hundreds of parameters one might wish to be able to filter quickly). This template is a very useful time saver, which is then utterly undone by the single neuron brutishness of the guardian check boxes in the following dialog.
In my perception, Animation Layers, especially when saved in scene files, (multiple hierarchies of control over the value of a parameter at each frame) are an abstraction that needs the option to be excluded from saved poses. If I save a snapshot of a figure's state at a single frame, I may need that to be distilled into the exact, final state of all the parameters, so as not to be concerned with how that pose might interact with a completely different scene with probably entirely different animation layers. No, I can't always keep track of the previous layer state when I re-apply a pose I saved ages ago. It has to apply itself to a single layer with no confusion as to what will happen when loaded from the library.
I have been, rightly or wrongly, regarding AnimSets as a template, not the data of parameter keyframe values, as opposed to Animation Layers, which are exactly the keyframe data, helpfully layered into logically distinct components of an animation. E.g. Separate layers for walk animation, hand gestures, facial expressions, etc. AnimSets are the adjunct which assists getting the exact, necessary information from the Animation Layers, into and out of the library.
The keyframe categories you describe, which I admit I have yet to delve into, do seem like a parallel concept to AnimSets, and development may very well have re-invented the wheel, if there was no overlap in oversight during that process. I will have to read further to judge whether the concepts could or should be merged. I think, from my brief purview, that keyframe categories are a better way to provide immediate visibility of animation components within the Animation Palette. While labelling groups of keyframed parameters and actors with a common label is an excellent step forward in animation development productivity, it may be that there is still room for the relatively simple template concept that AnimSets encapsulate. Whether one should or could be part of the other is hard to say. Maybe using an AnimSet as the storage template for a keyframe category is redundant. If they can both do the same thing, then, in my opinion, one of them is superfluous.
Whatever happens going forward [damn market-speak], I mean in the future, I will remain a happy camper if there are methods exposed to Poser Python to manipulate and interrogate these objects in at least the same level of detail as the user can through the GUI. At least! Prepare the path for automation at every step, then novice users can have their posing experience amped-up by those with the knowledge and motivation to distill their power usage into script form.
Imagine that, a programme and community that builds itself! Go Poser!
As architect of my company's main product, I crafted the SDK, and we have a policy that the SDK we publish for customers to extend the product must be used by our own engineers to make the product.
It's not perfectly enforced but close enough that we just don't run into the problem of something the main application can do but programmer-users can't.
I'd love to see Poser go to that approach. If the UI does something, make it do it using the official API or just don't do it.
We call it "eat your own dog food".
The parameter (and frame ranges, which I don't currently bother with) list contained in the AnimSet provides a symmetrical parallel to the detailed parameter selection process available when saving facial expressions to the library (though far less tedious when one has literally hundreds of parameters one might wish to be able to filter quickly). This template is a very useful time saver, which is then utterly undone by the single neuron brutishness of the guardian check boxes in the following dialog.
It's not exactly a similarity. Categories have no effect other than to color-code the animation palette's keyframe/layer.
It seems like AnimSets are the same as selecting arbitrary nodes on the parameter hierarchy, but it also seems that selection is basically ignored in the export. It's just a bit of a foreign concept. Animation Layers is like having multiple keyframe sheets, AnimSets seem to be merely selecting frame ranges (which have no use? or is it that you don't use them?) and omitting parameters, or picking them across multiple objects.
anomalaus last edited by
@h.elwood.gilliland the only reason I don't bother with the frame ranges when having my scripts save pose information, is that the extreme flexibility of having a separate range of frames saved for each specified parameter doesn't align with what I'm using AnimSets to provide a template for: that being to save the state of multiple, selected actors, and a chosen subset of their parameters to one of either: a single, multi-frame animation pose; a series of single frame static poses over the chosen range; or, a single frame. The frame range selection for those options is, I find, best chosen at the instant of saving to the library, rather than planned beforehand and configured in the AnimSet template.
It doesn't mean I cannot or would not use the frame range information from AnimSets, just that I haven't found a reason to spend the effort to configure the AnimSets I create to include anything other than the first frame, since I can't predict at AnimSet creation time, what frame ranges will be used by any particular scene. Unless, of course, I choose to create an AnimSet which only relates to a single, fixed-length scene, as a one-off.
[Somewhat off-topic discourse for background]
My typical scene scenario, though I do occasionally do animations, is a variously clothed base figure, which has multiple AnimSets devoted to being able to save complete or partial poses (arms, or legs only, for example), with or without the full body character defining morphs, but including pose related morphs which simulate (without actual simulation) soft-body dynamics. Then a series of AnimSets associated with each item of clothing (which typically don't include any of the transform parameters, as they are inherited by conforming), to allow me to save the poke-through-correcting or style selection morphs which are required to match that piece of conforming clothing to the figure's current pose (whatever the conforming does not automatically compensate for).
The scripts I have written, include using CustomData for each figure to encode the frame number (for my internal reference) and the Pose File Name (including full path) applied (or to be applied). In that way, a single script run can automatically parse a selected folder in the library, and apply all the pose files to the relevant base and conformed figures (using readScript lines to apply a pose and then call a subordinate python script to select the next figure in the scene or skip figures with no relevant pose). Conversely, another script can make use of the CustomData to create a series of poses for each figure and save them in the defined folders in the library (one per base or clothing figure) labelled with the Pose Name.
After the multi-figure, multi-frame save, I can then peruse the library folders for each base or clothing figure and see the individual saved poses, with appropriate, pre-defined names for later use, knowing that commonly named clothing poses will match the base figure's pose. As an adjunct, I can build a single pose file, which, when applied to the base figure, will also apply the matching clothing poses to the appropriate figures.