Sat, Feb 1, 5:50 PM CST

Renderosity Forums / Poser - OFFICIAL



Welcome to the Poser - OFFICIAL Forum

Forum Coordinators: RedPhantom

Poser - OFFICIAL F.A.Q (Last Updated: 2025 Feb 01 3:31 pm)



Subject: Time Reverse Keyframes in Poser


an0malaus ( ) posted Thu, 07 November 2019 at 11:37 PM ยท edited Sat, 01 February 2025 at 5:50 PM

Is anyone aware of a macOS Poser compatible utility or script to mirror a sequence of keyframes, so that they occur in reverse time order and correctly deal with spline breaks and transitions between constant, linear and spline interpolation?

Before I have to sit down and write one, which would hopefully be made redundant by such a feature directly built into Poser 12, I hopefully presume.



My ShareCG Stuff

Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.


starfish34 ( ) posted Fri, 08 November 2019 at 5:40 AM

A reverse script would be very useful, especially if it could be applied to individual parameters and not just elements and figures, like with Resample Keyframes.


almostfm ( ) posted Fri, 08 November 2019 at 10:11 AM

If it's for an animation, the recommended procedure is to render individual frames and then assemble them into the finished animation. Could you do that, and just assemble them in reverse order?


starfish34 ( ) posted Fri, 08 November 2019 at 10:54 AM

If your figure is doing pull ups and there are intermediate keyframes to pull up, it would save time to be able to copy, paste and reverse those keyframes to come back down. The more complex the motion, the more useful a Reverse Frames script would be.


SeanMartin ( ) posted Fri, 08 November 2019 at 2:51 PM

Actually, it's pretty easy. YOu have your start frame and your finish frame, with everything else carried out behind the proverbial scenes. Let's say your start frame is 1 and your finish is 20: twenty frames of animation. Highlight Frame 1 so you're capturing all the contents, then shift-drag it over to frame 40. Between 20 and 40, you should now have a reverse. If you want it saved as a separate sequence, just delete 1-19.

docandraider.com -- the collected cartoons of Doc and Raider


starfish34 ( ) posted Fri, 08 November 2019 at 7:57 PM

In your example all the motion is tweened between two poses so there are no intermediate keyframes to be reversed. If there were keyframes on frames 5, 10 and 15, they would need to be copied and positioned in reverse order onto frames 25, 30 and 35. A script, or having a Reverse Selected Frames function built in, would save you the time of manually copying and repositioning each intermediate keyframe.


SeanMartin ( ) posted Fri, 08 November 2019 at 8:38 PM

Well, yes, but considering how easy it is to move keyframes, we're not talking about a major challenge. Not everything has to be resolved with a script; sometimes it's just taking the two or three minutes to do it.

docandraider.com -- the collected cartoons of Doc and Raider


an0malaus ( ) posted Sat, 09 November 2019 at 3:52 AM

SeanMartin just imagine how tedious that would be if you have a 1000 frame sequence at 30fps that you need to reverse 100s of keyframes in and preserve the interpolation. Nobody wants to drag 100s of keyframes exactly the right distance when the animation palette has to scroll interminably before you even get there, and worse, doesn't respond to horizontal mouse or trackpad scrolling actions at all.

This is intended to displace exactly that kind of tedious scenario.

The question I'd like people to suggest answers to is: Should the reversal occur "in place", meaning you copy a block of keyframes you want to be reversed, to its final destination, then reverse it, or should the reversal appear immediately after the selected block like a reflection, whether inserting itself before any subsequent keyframes or just overriding them. What would you like to see for maximum usability?

In the first iteration, I will most likely just collect a sequence of interpolated values between start and finish and reverse them as a block of keyframes with no gaps. That is the simplest method of guaranteeing that the interpolation is preserved on reversal, regardless of spline breaks or missing start or finish keyframes in the selection.

If I can, I'll try to find out what the current selection in the animation palette is and use that. Failing that, the user would be prompted for start and finish, reverse-in-place, reflect-after-overwrite/insert.

Let me know what you'd prefer.



My ShareCG Stuff

Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.


an0malaus ( ) posted Sat, 09 November 2019 at 4:00 AM

The conditional tests for preserving interpolation on reversal of a sparse set of keyframes are quite onerous to derive, since the interpolation is not symmetric. Just try making a sine wave with the fewest keyframes. If you have enough cycles, the interpolation is very close to perfect, but the closer to the first or last keyframe one gets, the less accurate, since the interpolation is affected by what comes before and after. In those cases, copying ante/penultimate keyframes from adjacent to the nodes/derivative zeroes of the interpolation is the best way to preserve the desired shape near the start and end keyframes. Doing that algorithmically will be virtually impossible, meaning manual cleanup would always be required for spline interpolation. Linear and Constant are relatively trivial to deal with, only requiring transfer to the immediate prior keyframe.



My ShareCG Stuff

Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.


starfish34 ( ) posted Sat, 09 November 2019 at 6:23 AM

When there are numerous keyframes for multiple elements, and sometimes more than one figure, it can be tedious and easy to make a mistake, then if you refine the first half you have to revise or manually recreate the reversed half as well, instead of a quick copy/paste/reverse. Rather than a script, I'd prefer this function was built in, like it is in other 3d apps. Even Daz3D can do it.


an0malaus ( ) posted Sat, 09 November 2019 at 6:53 AM

I've already made such a request to the devs, but until they clear the queue of higher priority issues, this could serve instead. I'd prefer to see it built in, too.



My ShareCG Stuff

Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.


starfish34 ( ) posted Sat, 09 November 2019 at 9:57 AM ยท edited Sat, 09 November 2019 at 9:59 AM

an0malaus: A simple reverse-in-place function would suffice, even if further editing was needed to preserve spline interpolation. If there are existing keyframes you don't want to overwrite, you could reverse first, copy and paste, then restore the first half by reversing it again, and if you do want to overwrite you could just option-drag then apply the reverse script.

I was just going to ask for advice on the feasibility of writing a script that would enable hiding parameters from the animation palette (because scrolling through hundreds of parameters I'm never going to animate and dealing with the resulting screen lag is such a pain) and discovered that it's already possible. When you hide a parameter dial in Parameter Settings, it's also removed from the Animation Palette. This is not mentioned in the manual, at least not that I could find. It also doesn't mention that you can compress existing keyframe data by changing the Min Limit and Max Limit. So, for example, if you've animated people watching a tennis match, and decide to change the interpolation from linear to spline only to discover the curve is making their necks twist too far, you can change the limits and reduce the neck twist for all the keyframes (but save first because it's not undoable). It makes me wonder how many other things I want to do are already possible.


an0malaus ( ) posted Sun, 10 November 2019 at 1:58 AM

It would probably be useful to have a script which can remember a set of animation parameters to have their hidden state toggled, so they can be returned to their correct default after unimpeded animation palette editing and before saving the scene. I'll give it some thought. It probably ought to be a non-modal floating palette that can be docked or hidden and still remember what the user has configured. Might take a little bit of time.



My ShareCG Stuff

Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.


starfish34 ( ) posted Sun, 10 November 2019 at 6:17 AM

Only parameters can be hidden unfortunately, and only one at a time. It could take an hour just to hide unwanted parameters for a single figure that has morphs loaded, but animating would be so much easier afterward. Selecting Show Hidden Parameters toggles them all back on globally, but also includes all the parameters hidden by default.

As far as I can tell you can't inadvertently keyframe a user-hidden parameter unless you apply Resample Keyframes, which means if you want to resample a single parameter of an element you can't do it by temporarily hiding the othersโ€“you still have to duplicate the figure or prop first, apply the resample, then copy the resampled keyframes back to the relevant parameter of the original figure or prop.

It would be so nice to be able to hide props, lights and cameras. Adding a toggle on the Hierarchy Editor so that anything made invisible there would also be hidden on the Animation Palette would make sense. That should be the default anyway. I can't think of a reason why I'd want to keyframe something when it's invisible.


an0malaus ( ) posted Sun, 10 November 2019 at 8:13 AM

The reason for keyframing something when it's invisible is exactly the situation where the visibility flag has been made animatable, in which case you want keyframes specifying where the changes in visibility are to occur.



My ShareCG Stuff

Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.


starfish34 ( ) posted Sun, 10 November 2019 at 8:59 AM

Understood, but I was referring to animating other parameters of something temporarily made invisible, not animating visibility. Regardless of the default setting, having the option of only displaying visible figures, props, etc. in the Animation Palette would be a big improvement.


Richard60 ( ) posted Sun, 10 November 2019 at 12:54 PM

Given the history of the Poser Developers I wouldn't trust them to put any animation functions in to Poser itself. Maybe if they made all the Animation features available via Python that would be as far as I trust them. AS an example for Poser 10/2014 they added the collapse feature that was suppose to combine the movements of several layers into the base layer. For all of Poser 10 and through SR4 IIRC of 11 it was broken. That is the program took a frame added all the layers together and then was suppose to place that value onto the base layer. It added all the values together and also added in the value from the prior frame. So what you got was a value that could quickly skyrocket to extreme values. A Sine wave that should have gone up and down around the Zero axis became a stair case heading for the sky (or basement if starting in the negative direction). Even after they fixed it so that the prior value was not added in to the current frame when you applied the collapse the movements would not look like the motion before the collapse as Poser does not fully calculate the effects each layer has. AS some layers just replace the base movement and others add a correction to the other layers. So something that was nice and smooth started to jump all over the place because of Spline overshoot.

As another issue add in more then 2 layers and then try to use the dials or movement graph when the layers are not set to replace. Depending on the level a layer has in the chart (anything below the uppermost) then the effects become unpredictable. Also in the layers menu you can state a start and end frame for the layer. Then go outside of that range make a change to a parameter and the layer expands to include that change. Causing other parameters to change their Spline movements (depending on Key Frames).

SO if your script is only going to be for a base layer only animation you might have a change. If it is used with Layers then you will have a great number of checks you will have to do to make sure it does a simple reverse.

Poser 9 had some issues but was easy to use. Poser 10 got worse and 11 even worse then that. I had hope that when the last Dev Team did a survey about 2 years ago on the SM site about Animation features that they were finally going to fix it so it works like it should (or at least how the manual implies it should work). Now that it has changed hands I have no clue where animation falls on the priorities of things to improve. That is why all they should do is make all functions available via Python.

Poser 5, 6, 7, 8, Poser Pro 9 (2012), 10 (2014), 11, 12, 13


starfish34 ( ) posted Sun, 10 November 2019 at 9:17 PM

Working with layers in the Animation Palette is super frustrating. I don't know why they hobbled it by making it impossible to copy keyframes from layer to layer, or even from one element to another within the same layer. All you can do is make new keyframes and option-drag to duplicate them. Also, the inability to collapse a single layer doesn't make sense. There is a workaround if you don't mind deleting all layers but the one you want to collapse, collapse it, copy the resulting merged keyframes and then paste them back into the base layer of the original.

I suspect problems with layers in Add mode are caused by conflicts with the Min Limit and Max Limit values in Parameter Settings. As mentioned in a comment above, the settings affect existing animation. You can fix spline overshoot by changing the values, sort of like compressing or limiting audio. For example, here's an animation with keyframes set at -5 and +5, with spline overshoot caused by moving the two middle keyframes closer together.

one.png

Changing the Min Limit to -5 and Max Limit to 5 with "Force Limits" selected flattens any value exceeding the limit and adds a representative black line, as shown below. Any keyframe with a value between 5 and -5 is unaffected. This is non-destructive, so you can always go back.

three.png

Here's the same animation with the Min and Max Limits changed to 2 and -2. This time all the keyframe values get changed and the overshoot is flattened as well. The flattening can still be removed by increasing the Min and Max Limit, but you can't Undo the change to the keyframes.

two.png

Here's another animation with keyframes set at -9, +9, -7, +7, -5, +5, -3, +3, -1 and +1.

four.png

And here's what it looks like after changing the Min and Max Limits to +4 and -4. Any keyframe values exceeding the new limits are changed. The rest are unaffected.

five.png

The graph can be confusing when working with layers, partly because the display doesn't update when you select or deselect "Include in playback" or change Composite Method (Add and Replace). To refresh the display, select a different layer and then reselect the one you're working on. The red line represents the currently selected layer. The black line represents a composite of all the layers that have "Include in playback" checked. Unlike with the base layer, changing Min and Max Limits doesn't change keyframe values, it just flattens non-destructively the same way spline overshoot is flattened.


an0malaus ( ) posted Wed, 13 November 2019 at 2:08 AM ยท edited Wed, 13 November 2019 at 2:09 AM

Wow! Thanks for the buckloads of caveats that have been exposed. It's good to see that there are still major usability problems with animation before I started spreading a script whose initial scope was way too narrow to provide anything but a neverending stream of "it doesn't work the way I expected".

Those are sincere thanks, indeed. Absolutely no sarcasm implied at all.

The first draft of my script did what I needed it to do, but will obviously require much more thought before it can be presented as anything other than one piece of a complete animation toolkit. I quickly determined that using parameter.ValueFrame() was never going to be useful, as that does not return the actual keyframe values, without any consideration of layers, which I must explore the Python API for details of. Incrementing through all frames in the reversal range, and collecting values using parameter.UnaffectedValue() at least gives me meaningful keyframe values, but still ignores anything to do with layers. So, back to the script editor.

If I'm keyframing sinusoids, I never trust a simple minimum and maximum per cycle, since your frame adjustment shows that a keyframe gives no assurance of any particular phase in such a spline. It always requires the zero crossings (maximum and minimum slope or first derivative) to be keyframed as well. At the start and end of the wave, multiple, adjacent keyframes need to be specified to conform to a sinusoid, too.



My ShareCG Stuff

Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.


starfish34 ( ) posted Wed, 13 November 2019 at 12:57 PM

Good luck making it work with layers. Attempting to paste keyframes into a layer can make Poser crash. You can't apply "Resample Key Frames" or "Retime Animation" independently of the base either. I'd be happy with a script that just reverses the selected keyframes on the base, and Collapse All first if needed.

Trying to reverse a layer that's in add mode might be asking too much, unless there are already keyframes at the beginning and end of the selection to be reversed. For example, reversing a selection from this layered animation would require adding keyframes to the layer, and that would change the spline.

Screen Shot 2019-11-13 at 1.06.23 PM.png

In the left screenshot, the base layer is selected. In the right screenshot, layer 1 is selected. The black line is the two layers added together.


Richard60 ( ) posted Wed, 13 November 2019 at 10:49 PM

One of the first things I did after Bondware bought Poser was to file a report about the issue with layers. The problem with layers has been there since they were added. A lot of the problem is the programmers only planned for two layers. You can see this in the scene file if you look at the movement values. Below is the report I submitted.

Animation Layers Issues

To see the issue open Poser and it is easiest to put in a simple prop such as a box. Go to the last frame and move a single channel such as Y Translate to a value. This puts in two Key frames one at 1 and the last at 30. Now open the Animation Palette and put in a new Layer with a start of frame of 10 and end of 20. With The Base layer selected you will see a nice line going from 0 to the value at 30. Now select the new Layer and put the cursor at frame 15 (somewhere in the middle of the layer) making sure to be the same channel as in the Base Layer. On the Graph click on the RED line and it will create the start and end points and the point in the middle. The Start point of the RED line will be placed Above Zero on the BLACK line. The Middle point will be placed at a random location. The End point will be on the Zero line like it should be. Since all Three points are Zero and you can see that if you look at the PZ3 if you save it they should all be on the Zero line instead of having a shape that looks a shark fin.

This problem has existed ever since Poser put Animation Layers in with Poser 7, although with slightly different symptoms. In Poser 9 if you added a layer the adjustment line (RED) would start at zero and end at zero and the middle adjustment would show the actual value. At least for the first couple of clicks and then it goes bonkers. This is especially true if you add in more Layers. The Problem is that for the Base Layer Poser only adds a in a K value format of (k 29 1) Where k stands for Key Frame the 29 is the Frame where the Key is placed and then 1 is the movement value of the channel movement. When you get to the Layers not only do you get a K input you also have another Key called KDF (Key Difference Frame???). This is in the format of (kfd 0.172414 -0.310345) the first value (at least in Poser 11.1.1) appears to be the Value the channel is suppose to have. The second value is difference between the Base Layer Value at the frame and the Key Value. Listed is the condensed list of values from a Layer. layer kfrm Layer_1 k 0 0.310345 kfd 0.310345 0 k 5 0.172414 kfd 0.172414 -0.310345 k 10 0.655172 kfd 0.655172 0

The problem is the KDF as it appears to be an attempt to be able to toggle between Add and Replace a Layer. This might work if all you can have is TWO Layers Base and One more. However You can have a large number of them and they can be toggled On and Off to add the effect of the Layer to the overall Value. So if you have Three or more Layers what is the First Value of KDF suppose to be? The way the manual explains Layers is that if you are in Add Mode then if the Base Layer (Total of all layers added together) is say 90 if you Add in -20 then the overall value should be 70. 90-20=70. In Replace Mode the values below the Layer that is Replace should be removed from the calculation and the Value of the Replace Layer and any Layer above it that is in Add Mode should be what the channel value becomes. And the RED line should start off at Start Zero and End Zero until the User moves the Points instead of trying to connect the points outside the Layer Range into a smooth graph.

@an0malaus If you find any functions in Poser Python please let me know as I have not found any. There is the value channels functions and some from the Animation Sets, however nothing for the Layers Functions. The ones listed are for Material Layers.

When and If Bondware gets to testing the next version of Poser I really hope they get at least one tester who uses the animation functions.

Poser 5, 6, 7, 8, Poser Pro 9 (2012), 10 (2014), 11, 12, 13


an0malaus ( ) posted Thu, 14 November 2019 at 2:05 AM

Thanks @starfish34 & @Richard60 I'll feed that info back into the beta programme.



My ShareCG Stuff

Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.


starfish34 ( ) posted Thu, 14 November 2019 at 1:28 PM

Richard60: The problem youโ€™ve described in the first paragraph is caused by the Sensitivity value in the Parameter Settings. If you change it to zero, keyframes will be added at zero relative to the existing values, as shown on the right. The slight bump goes away when you change to linear. I'm not sure I understand the rest of your comment. The start and end keyframes are at zero, relative to what's below.

Screen Shot 2019-11-14 at 1.32.39 PM.png


Richard60 ( ) posted Thu, 14 November 2019 at 7:01 PM

@Starfish34 The problem is exactly what you said "Relative to what's below" In Poser 9 all 3 of the points would have been on the ZERO line (RED if there was no movements made). Just to make sure we are all the same page and talking about the same thing, The Red Line is the current layer and the Black line is the combined values in all the active layers. So as posted above in your two graphs the BASE layer goes from 0 to 3 or thereabouts. So just using simple numbers for the 3 points you can see in the middle of the graph I will call them A @1 B@1.5 and C@2. Looking at the graph above you will note that Point A is at 1 (which is where the value of the Black line is) This then makes the combined values of Black = 1, Red = 1 and using the KDF of -1 gives you 1+1-1 = 1. If Poser was using Relative for all the points then point C should be at 2 and not where it appears at 0 on the Red Line which would give the values of Black = 2, Red = 2 and KDF =-2, 2+2-2 = 2. If you were to save the scene and look at the values for the channel movement the Layer 1 values should be 0, 0, 0, if you did not make any changes to the Red Line. But Look at the graph, Point A appears to be @ 1, when the true value is 0, point B is @ 1.5 when it too should be at 0 and Point C is the only one showing it is at 0. It is this inconsistent adding and displaying of values that cause layers to be broken. The poser Manual is very clear when it says that values of all active layers are added together to produce the final result. So that if my Base Points A,B,C were at a value of 90, 90 and 90 and I added in a layer with values of 0, 2 and 3 the combined results should be 90, 92 and 93. The Black Line should show 90, 92 and 93 and the Red Line should be 0, 2 and 3.

The bigger problem other then the Graph looking wrong is that if you have two or more layers then one or more of the ways to change a value becomes broken. The ways to change a value are Type a value into the channel (the only one that works all the time), Turning the dial of the channel (sometimes it works and most of the time the value will Skyrocket). Using the graph to move the points (Most of the time the point won't move and the Black Line jiggles back and forth). Grabbing the item in the pose window and dragging it around (This one also is broken). The worst is that the behavior is different depending on where the Layer is in the stacking order and whether it is in Add or Replace mode.

The problem with the Skyrocketing values probably has to do with the fact Poser is trying to add in a change (which should be relative to Zero) but adds in the change does the math and says the Value should be X but because it is not using Zero it sees the change as a greater value so goes and adds that value in also.

This means that the parameter palette needs to have another value display to show the current level and the combined level and possibly a third one to show the effects of master dials.

Poser 5, 6, 7, 8, Poser Pro 9 (2012), 10 (2014), 11, 12, 13


Richard60 ( ) posted Thu, 14 November 2019 at 9:27 PM

I will attach some pictures to demo the issues.

Poser 9 Graph.jpg

This is poser 9 with a linear line going from 0 to.5 over the length of 30 frames. I added in a layer from 10 to 20 and placed a Key at 15. Notice that all 3 Keys are on the Red Line and that is at ZERO.

Poser 9 GraphWith .jpg

Now I moved the center of the Red Line up and notice the Black Line also moves up the same amount. Also notice the Keys at 10 and 20 remain at Zero.

Poser11AllZero.jpg

This is the scene I made in Poser 9 imported into Poser 11.2. Notice the first 2 points are not on the ZERO line any more. Although they have Zero effect on the Black Line.

Poser11Import9.jpg

And here is the same scene with the center point being moved up. Notice instead of being separate as in Poser 9 they are on the same line. The biggest issue is that if Layer 1 is in add mode then you can not grab the center Key and drag it up or down. Below is what happens if you try to move the Red Line with the graph.

Poser11Broken.jpg

The Black jumps to some value and gets stuck. The Red line won't move at all. However you can move it with the dial or in the Poser window. And typing in a value.

Poser 5, 6, 7, 8, Poser Pro 9 (2012), 10 (2014), 11, 12, 13


Richard60 ( ) posted Thu, 14 November 2019 at 9:42 PM

The issue with placing the Red Line Keys on the Black Line is that it only works if you can only have TWO layers. If you have more the TWO layers and they are in an ADD mode then you have to figure out where the line should be. Below is what happens if you just add 2 more keys to the Red Line in poser 11.

Poser11AddMore.jpg

Notice the new Key at 12 drops below the Black Line. The Key at 17 Jumps way above the Black Line, about where it would be at Zero if the Black Line stayed as a straight line.

TO my way of thinking as a programmer if they get rid of all the fancy code trying make the Red Line track the Black Line then it will make the whole thing simpler and probably make it work as it was intended. The only issue I can think of right off hand is Master Parameter dials that change the channel values, things like a make a fist which changes all the finger channels indirectly.

Poser 5, 6, 7, 8, Poser Pro 9 (2012), 10 (2014), 11, 12, 13


starfish34 ( ) posted Fri, 15 November 2019 at 10:42 AM ยท edited Fri, 15 November 2019 at 10:43 AM

Richard60: I see what you mean now. I wasn't aware there were bugs with layers in the graph editor. Working with layers slows down my system so I only use them for things like eye blinks and turns, or adding subtle random motion to a figure animated in the base layer, and I don't edit with graphs because displaying long animations is a challenge for my 2013 MacBook Pro, judging from the screen lag when I move a keyframe. I'd really like to be able to select a keyframe(s) and move it around with the arrow keys. Even changing the magnification requires excessive click and dragging. A few presets for 25, 50 and 75 percent magnification would be nice. Working with the animation palette can be tedious too, having to select a keyframe, pause to avoid a double click that opens a graph (I use a pen tablet and this happens constantly) then click and drag to move it. I'd like to at least have the option to quickly click and drag a keyframe with a modifier key. Scrolling through hundreds of parameters takes up too much time as well. Parameters can be removed, one at a time, but I think what's really needed is a filter like the Hierarchy Editor has, so you can hide figures, lights, cameras and props, and also parameters by category (translation, rotation, scale, morphs). I've had Poser for about six years and only dabbled with it until the past year when I started doing character animation. I'm happy with what it lets me do but constantly annoyed that I can't work more efficiently.


Richard60 ( ) posted Sun, 17 November 2019 at 9:04 PM

Here are the results of my making a 100 frame animation of a box using the Y Translate channel. I placed a Key Frame on every frame to make it like a BVH motion file that you would get from a system like an Optitrak motion capture system. Back in 2012 I helped my son with his movie making class so we made 5 films in 18 weeks using Poser Pro 2012 and some motions from Tru Bones which are BVH files. As I have shown above and will show below you can place a BVH file into Poser and using another layer make a couple of simple adjustments to bring a wide range of keys into new positions to avoid such things as hands passing through a body part. The first image is the 100 frames of motion capture of the Y Translate of the box. The next image shows the additon of a layer with all 3 points being on the Zero line. The next image shows that moving the center point up a small amount causes athe range of Base layer keys to move upwards using a gentle Spline Curve to avoid sudden jerky movements. The 4th image is the Base Layer selected that shows the Key points are the same however the Black line above the dots is the actual movement of the body part in the animation.

100 Frames Poser 9 1 single.jpg

The BVH style file

100 Frames Poser 9 2 second layer.jpg

This is the Layer 1 in Poser 9 all at Zero and using Add Mode.

100 Frames Poser 9 3 second layerAdd correction.jpg

This is the Layer 1 with a small adjustment on the center Key. Moves all the above Keys up some.

100 Frames Poser 9 4 second layerAdd correction Base.jpg

Here is the Base Layer showing all the original Keys in place with the actual movement shown in Black above the points.

Poser 9 All Zeros

k 51 0.0638776 k 0 0 kfd 0.0638776 0

k 59 0.0482041 k 8 0 kfd 0.0482041 0

k 66 0.0695103 k 15 0 kfd 0.0695103 0

Here are the values on the two layers at the Key Frames that are affected. The format is k (stands for Key) The Frame number (51) and the Value for that Key at that frame. The next values are k (for Key Frame) the Frame number as an offset for that layer (as the layer starting frame is defined earlier in the file) the Value. Finally we have kfd (Key Frame Difference?) The value of the sum of all the rest of the layers at that moment and the value of the Layer Key Frame. The kfd appears to be some way to Toggle between Add and Replace functions. If you select the Add option in the Layers tab then Poser 9 uses the second value in the KFD along with the layers k value. If you select Replace then the first value is used which bring the graph up to the level of the Base Layers key value. In order to make it a true Replace then you have to dial the start value down to the Zero line and then add in your own values from there. That might make sense if it wasn't for the other two options on the Layers tab called Blend In and Blend Out. What the book says the Blends do is to transistion the change between the two layers to avoid an abrupt change by doing a Linear slope of the two layers values. So that if Base Layer had a value of 90 and Layer 1 in Replacement mode has a value of 0 then over the course of the number of frames in the Blend option to move the value from 90 to 0. So if you put in 10 frames then the channel will drop by a value of 10 each frame. But what's the point if you are going to make the Replacement Layer start at the same value as the replaced frame?

Poser 11 Imported 9 All Zeros

k 51 0.0638776 k 0 0 kfd 0.0638776 0

k 59 0.0482041 k 8 0 kfd 0.0482041 0

k 66 0.0695103 k 15 0 kfd 0.0695103 0

The above values are what Poser 11 outputed when I opened the Poser 9 scene in Poser 11 and then saved it right away. They are the same as Poser 9. That is a good thing as it does not appear the they changed the code for the reading of Key Frames.

Poser 9 with centered moved

k 51 0.0638776 k 0 0 kfd 0.0638776 0

k 59 0.0482041 k 8 0.00948181 kfd 0.0576859 0

k 66 0.0695103 k 15 0 kfd 0.0695103 0

At this point I added in a movement on layer 1 at frame 59 (8). Notice the k 8 number is no longer 0 but the difference between the kfd and the base layer value. It also does the same thing when it is put into replace mode. One more issue is that in Replace mode even in Poser 9 the End frame point is broken in that the point does not move but the graph does.

100 Frames Poser 11 2 layer at 0.jpg

Poser 11 Imported Base Layer and added Layer 1 Keys in program

k 51 0.0638776 k 0 0 kfd 0.0638776 0

k 58 0.0467348 k 7 0 kfd 0.0467348 0

k 66 0.0695103 k 15 0 kfd 0.0695103 0

The above is what happens after I imported just the Base Layer and then added in the Layer 1 with in the program. As long as I just add the keys without making any change in the Key Value then it appears to work the same as Poser 9.

100 Frames Poser 11 3 2 layer dial adjust.jpg

Poser 11 Center Dialed

k 51 0.0638776 k 0 0 kfd 0.0638776 0

k 58 0.0467348 k 7 0.0622992 kfd 0.109034 0.0622992

k 66 0.0695103 k 15 0 kfd 0.0695103 0

However as soon as I turn the channel dial even a little bit the Layer k value jumps to a very high value. It looks like it adds in both the change in the dial and the Base Layer and then some. However at least it can be dialed back down and controlled. But if this is done on a large numbe of channels it could become very cumbersome.

100 Frames Poser 11 4 2 layer moved center.jpg

Poser 11 Center Graph Moved

k 51 0.0638776 k 0 0 kfd 0.0638776 0

k 58 0.0467348 k 7 0.0472906 kfd 0.0940254 0

k 66 0.0695103 k 15 0 kfd 0.0695103 0

Above is what happens if you try to change the channel value with the graph. There is something broken in the Graph when using Layers. It appears to be an attempt to add in the change in the graph value with the Base Layer twice over. Then the graph gets stuck and no longer shows any movements.

The biggest issue is that the programmers added in the kfd part. Considering that most of the frames have to be calculated without the aid of the kfd it should be gotten rid of and just program the layers to work as the manual implies they should. That is if you make a new layer then the starting values should all begin as Zero and only be changed by the user. That way if you make a dozen layers you don't have to worry about what happens if you make a mistake and place a key on the wrong layer. Also it would allow all the ways of making a movement work instead of the current state where at least half of the ways are broken depending on where the Layer is located and the Mode it is in.

Poser 5, 6, 7, 8, Poser Pro 9 (2012), 10 (2014), 11, 12, 13


starfish34 ( ) posted Mon, 18 November 2019 at 10:26 AM

Richard60: We appear to have hijacked this thread, but you should definitely cc all this information to Bondware.


Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.