Quote - If that was done purely by animating the marker positions, then it has to be a lot easier to do than animating a chain character, even with the benefit of EasyPose. I'd be prepared to tolerate some inaccuracies in return for that simplicity of use.

It was animated that way, yes.  The animation wasn't difficult.  The problem is that the endpoint isn't constrained.  I'll need to come up with a method which can place the ends of the chain at the first and last marker points while restricting the path length to keep the link count consistent throughout the animation.  Unfortunately that will mean sacrificing the WYSIWYG aspect of the animation following the marker points.  So to constrain the end points, I'll have to make animation using the markers less accurate and accessible.  I'll have to think about how to do that. 

Here, the path can stretch or scrunch to a certain extent, if the spacing between links is what is allowed to adjust for that.  The link size and link count need to remain the same.

Here's the previous animation with different settings for the chain length handling.  The start and end stay in place and the chain follows the markers.  I'm surprised.  :laugh:

Now it needs to prevent the overshoot at the end of the chain.  Due to the rounding of the link count when extending the chain to fit the path, the current process can easily result in a chain which over- or undershoots the last marker point by one link.

Thanks for the chain loop prop script, first of all, and sorry for not giving thanks for it earlier. I got distracted by the wibbly-wobbly chain animations, first of all, then I stopped getting e-bots. It works like a charm, memory leaks notwithstanding. I like the new style interface too. Is there a possibility that might find its way into Mr. Looper at some point? I have to remember to do Ctrl-C when using Mr. Looper so I can recall my previous settings if, as is usual, the first try isn't exactly right. The Tkinter window (in my case) makes all that a whole lot easier.

The animated wibbly-wobbly chain is looking better and better as well. It may not be physically perfect, but as I keep saying if it's as simple to set up as it looks, frankly, who cares? :)

I second the thanks.  These are all great scripts.  You now have your own script menu in my Python library. ;).

Best Wishes,
Rªnce

Oh, thanks, guys.    I haven't posted for a bit because I'm distracted by trying to put together a basic dynamics simulator for the chain script.  I started out with what is evidently a euler integrator, which is a bad thing.  So I'm digging for alternate approaches, but there aren't any readily helpful examples and I'm having to build something slowly through trial and error, with periodic sidetracking into cursing & online research.  :lol:  I'm currently trying to switch to a velocity Verlot integrator.

Hopefully I can work something out.  The euler approach looks neat when it works, but the chain can too easily stretch until the links separate, while the flaws in the euler method prevent the application of adequate restrictions on the stretching.  (If you try, the chain explodes.  Which looks kind of neat, the first time.  :lol:)

So... working on it.

Attached Link: http://www.google.com/search?q=shake+algorithm

Link is for one constraint dynamics method that is probably about right for what you're trying to achieve.

Thanks, nruddock.  I'll look into that.  I'm not sure I'm math-averse, per se.  :lol:  I lack the ability to read complex examples of summation notation, particularly when there are undeclared variables, whose meanings I'm supposed to know automatically.  I don't know physics or calculus.  So I'm limited, but trying.  :unsure:

I've almost gotten a velocity verlot simulator together.  It positions the links nicely and responds to gravity, but won't seem to carry through any momentum the links should have, so it looks weightless.  The euler integrator, on the other hand, has the nice handling of link momentum, but the chain can't be kept from stretching.  If I can figure out how to get the verlot to reflect that momentum, it will do nicely.  Since this won't handle collisions anyway and is just a very basic simulator, mainly intended to ease the process of posing the markers, I'm not sure whether it's worth trying a wholly different approach.

If I can find an example of the results the shake algorithm can offer, I may be swayed in its direction, though.  :lol: 

There's an entire third column of GUI options now, so hopefully the whole thing isn't too confusing.  I don't want to create a mini-Blender.  :lol:

I've set the animation options to the best defaults I could work out, in testing.  A few key points:

• The script won't animate unless the "Animate" box is checked, and it won't simulate unless both "Animate" and "Simulate" are checked.
• The script opens listing the current frame as the start frame.  The script will use the current frame to build the base geometry for the chain, so it will ignore any effort to set the start frame to one which is earlier than the current frame.
• The script indexes the frames from zero, rather than one.
• The script will ignore any marker which isn't parented to UNIVERSE< in the simulation.  This allows end points, and any other marker in the marker chain, to be animated or locked.
• The chain geometry defaults have been altered for faster animated chain creation.  Sections has changed from 28 to 14, slices from 10 to 4.  This is faster and it doesn't look too bad unless you're getting very close for a render.

Most of the animation options are hopefully pretty straightforward.  The rest of the script options haven't changed from the last release.

To quickly see what the script can do, load the .pzz and start the script.  Check the "Animate" and "Simulate" checkboxes.  Let the script run.  Out pops an animated chain which follows the shackle tolerably well.  Neat.  :laugh:

The script will not alter the current frame, in the simulation, so you can just run a new simulation if you want to try different script settings.  The markers will be freshly animated with the new script run.

This version has the verlet integration working, for better dynamics.  There are no collisions and the chain won't respond to one of those wind-generator thingies used for the cloth and hair simulations, but it's working to what is apparently the preferred standard in video games.  :unsure:

To simplify the process, I set it up so you only have to check "Simulate" to run the simulation.  Check "Animate" if you want an animated chain from hand-keyframed marker points.

A couple of the input defaults have changed from the last version, to work better with the new process.  Otherwise nothing has changed on the user level.

And you can burn any copies of the last version.  :lol:

I've added a feature which creates a path preview prop as you position the marker points, to clarify what's happening.  That seems to work nicely so far.  That will be in the posing script and will be added to the chain prop and tube extrusion scripts.  The tube script will also have the animation options added.

And maybe I'll see if I can build in an automatic catenary feature.  :lol:  I know a proper catenary is supposed to be mathematically elusive, but I think I still have code around which derives some sort of approximation....  :unsure:

This is looking far more fabulous than we have any right to expect. Thank you for your continued efforts.

Quote - The tube script will also have the animation options added.

I was going to ask about that. :-)

Quote - I know a proper catenary is supposed to be mathematically elusive, but I think I still have code around which derives some sort of approximation...

As I keep saying in a variety of contexts, an approximation is good enough for the majority of uses. I'd happily do my own catenary approximation by fooling around with the markers if necessary, so even the crudest approximation would be a boon.

Quote - This is looking far more fabulous than we have any right to expect. Thank you for your continued efforts.

Thanks, EB.  :laugh: 

Really, I'm making these for myself, in the end.  So if no one's posting responses, that doesn't bother me, for the most part.  I'll still write the scripts, I'll still post the results, and they can all still use them or not, as they prefer.  (This forum needs a "Poser shruggy guy" smiley.  I'd put that here.  :lol:)

Anyway, the posing script is coming together, after having resolved some worrying difficulties with handling chain figures which aren't oriented on +Y.  It's now posing chain figures built along any of the six cardinal directions.  For anyone who might ever struggle with the problem: you want the same path for all orientations, meaning the same pose with the same angles.  Don't fool around trying to transform the orientation of the posing path.  Get the pose for +Y and then just swap the parameters around when applying it, to fix the axes.  It took too many hours for me to figure that out.  :lol:  :blushing:

Fooling around with the markers should be much easier, with the path preview function activated.  I wish I could create an honest spline object in the display window, like a walk path.  This process uses a string of boxes as a display prop, and it updates the path as you move the markers, without any callbacks.  I've found that helpful, myself.

I know there are at least a couple of people who were very interested in the catenary business, and at least one of them seems to favor accuracy over a decent-looking approximation.  :unsure:  Lacking the availability of accuracy, due to mathematical impossibility and/or the limitations of my own education and training, I'll happily opt for the approximation.  But that's me.  :unsure:

Hi Cage,

I don't personally have any (immediate) use for these scripts, but I just wanted to pop in and tell you how impressed I am at your tenacity in figuring this stuff out - nice work!

Cheers,

Keith

Quote - I don't personally have any (immediate) use for these scripts, but I just wanted to pop in and tell you how impressed I am at your tenacity in figuring this stuff out - nice work!

I'm not sure whether I'm tenacious, so much as merely obsessive.  :lol:  Some things are beginning to make more sense, however, albeit slowly and accompanied by much cursing and shaking of fists.  :unsure:

Quote - I wish I could create an honest spline object in the display window, like a walk path.

The simplest way to do that would be to use line geometry. This is what Poser uses to store hair data and is a part of the OBJ file spec.

Poser will read and display "l" lines from an OBJ file, and these show up in the preview, but not in renders.

I suspect that you can create them on the fly by creating 2 point polygons using the Python methods in the Geometry class.

The only alternative (for P8 and above) is to use the facilities wxPython offers to get access to OpenGL context and draw them on the display, but requires some additional modules to be installed (and isn't perfect due to the need to effectively turn off the normal double buffering).

tenacious / obsessive... whatever works :).

Quote - Poser will read and display "l" lines from an OBJ file, and these show up in the preview, but not in renders.

That hadn't even occurred to me.  Wow.  I think I had the idea that Poser no longer supported lines.  In Poser 5, I could change the "p" lines to "l" lines in an .obj file, with interesting results.  I think that stopped working in Poser 6 or 7.  :unsure:

But Poser does use lines for the hair, so perhaps it just won't import them from a file, or something.  I think I experimented with building line geometries in the hair room script with which I tinkered a couple of years ago.

Good idea!  :thumbupboth:  That's why I keep posting.  People have ideas or suggestions that make the scripts more better for everyone.  :lol:

It does require an import operation every time the line refreshes, but the geometry is so simple that it seems to be fast enough.

I do wonder if some people might encounter problems when using a script which tries to write and import (then delete) files in the background.  Possibly I should leave the boxes method in as a backup.

Poser cannot create a new line geometry using Python.  It automatically closes any polygon left open, foiling the effort to make lines.  Bah.

Quote - For anyone who might ever struggle with the problem: you want the same path for all orientations, meaning the same pose with the same angles.  Don't fool around trying to transform the orientation of the posing path.  Get the pose for +Y and then just swap the parameters around when applying it, to fix the axes.  It took too many hours for me to figure that out.

No, this seems to have been wrong.  You shouldn't transform the path or swap around the signs.  The latter process will work (mostly), if the pose data has had the parent worldspace matrix stripped out.

Apparently the correct process, however, involves the application of the actor's restmatrix and invert restmatrix.  So if you ever have this problem, check that out.

I should be ready to start implementing the animation and dynamics for the posing script soon.  Apologies to anyone who's actually reading this and who might be awaiting the script.  There's been some confusion about pose conversion.  :unsure:  :lol:

Does anyone know where I can find a poseable tube or chain-type figure which is not oriented along X, Y or Z?  I'd like to test some code for that situation and I'm lazy enough that I'd rather not build a figure from scratch, if I can avoid it.  :lol:

This restmatrix business really is the key to converting poses between figures.  It's pretty neat.  I've decided that I quite like matrices.  :laugh:

I'm wondering if the process could be harnessed for a pose conversion script which converts poses between more standard (humanoid) figures.  Back in 2006, I adapted the Blender .bvh import script code for that purpose, and it worked nicely.  The success so far with this script suggests that it might work in Poser.  The main trouble being that Poser rotations are set using euler angles and not quaternions.  I'm told that there is no way to avoid gimbal lock situations in converting to euler.  The compensatory methods used in euler conversion code work well enough for a prop, where two equivalent rotations can be exchanged without any obvious error, but figure joints would be a different matter.  My experience is that you get a lot of badly-rotated elbows and shoulders and knees, anywhere a joint is likely to bend beyond 90 degrees.  Still, it's a thought.  :unsure:

Euler angles are demonic.  :cursing:

I have poses coming out well for most axes in most situations, but in some cases the base link apparently becomes gimbal locked and points the wrong way.  The process in place seems more or less self-correcting, so the following links gradually find their ways back to the correct path, but a bad direction for the base link creates an ugly snarl in the first few links.  This dratted thing is so danged close to working.  If I can conquer this problem, there will be a posing script for chains and tubes which point along any axis.  If it can't be resolved, there can be a script which handles the default +Y well but is not necessarily reliable for other orientations.

I've converted the euler_unique() process from the Blender 2.42 source code and it seems like that  might help in the problem cases, but I need to do more testing.  So far, every time it seems to be fixed, a new path will reveal that the problem is still there.  Sigh.

<-- Didn't understand any of that, but makes vaguely non-specific noises of encouragement anyway.

:lol:

Thanks, EB.  :lol:

We've all encountered gimbal lock in Poser, surely...?  That's the demon in eulers showing.  :lol: 

The first link in a chain isn't rotating relative to a parent, but to UNIVERSE.  This means the angles being handled are likely to be more extreme, making that link more sensitive to the risk of a bad euler conversion which points it the wrong way.  A euler rotation apparently has an infinite number of equivalent rotations which can offer the same orientation.  Any euler conversion code works around this by making certain assumptions about how to get the right one.  Whenever an angle of 90 degrees or greater comes into play, there's a risk of a bad euler conversion.  The assumptions just can't be correct all the time, with so many possible solutions.  (Or such is my understanding.... :unsure:)

There may be no way to resolve this, in Poser.  In other software, you can set rotations using quaternions, which don't have the same problems.  Unfortunately Poser Python allows one to query an actor's quaternion rotation, but you have to set the dial values with euler angles.

Quote - We've all encountered gimbal lock in Poser, surely...?

Well, ok, maybe I was being a bit sweeping when I claimed not to understand any of it... :)

I have a vague notion that gimbal lock can be worked around by changing the rotation order - that's sort of what I do when it occurs in Poser, but I never tried to quantify the process. A Google search for "avoiding gimbal lock" yielded some interesting references, but I'm none the wiser as yet.

Um, carry on along those lines, then... :lol:

Quote - Thanks, EB.  :lol:

We've all encountered gimbal lock in Poser, surely...?  That's the demon in eulers showing.  :lol:

The first link in a chain isn't rotating relative to a parent, but to UNIVERSE.  This means the angles being handled are likely to be more extreme, making that link more sensitive to the risk of a bad euler conversion which points it the wrong way.

The first link of the chain of bones turns relative to the body of the figure, perhaps this is where your error is, or do you mean by "first link" the body?

Quote -   A euler rotation apparently has an infinite number of equivalent rotations which can offer the same orientation.  Any euler conversion code works around this by making certain assumptions about how to get the right one.  Whenever an angle of 90 degrees or greater comes into play, there's a risk of a bad euler conversion.  The assumptions just can't be correct all the time, with so many possible solutions.  (Or such is my understanding.... :unsure:)

This is true, thinking about the chain problem, however, the situation should not be that difficult. For the chain links, i would initially completely ignore the twist component, since for a real chain (made of stainless hardened steel) you cannot turn a single link by any substantial angle without effort. So you could just assume twist is 0. That leaves 2 angles to specify the direction of the link. E.g. on earth, we could use longitude and latitude to specify the current orientation of our home planet. You only have to decide which one should be the one with the larger range; on earth we usually use longitude between -180 and 180 and latitude between -90 and 90, so longitude has the larger range. Within these limits the angles are unambiguous.

So if you only want to pose the chain links, you might want to set the twist to 0, limit one angle to -90/+90 and you will not get any gimbal lock. Then, after the whole chain is posed, with all twists zero, then assign twists, for example by averaging them over the whole chain.

The difficulty (for me at least), was to figure out the different rotation orders; unless i wanted to build a new chain around the pose, i can only use the rotation orders of the links that are stored in the individual actors, resp. links, and these might not be the same for all links. In most cases they are the same for every link, but often it is not the case for the figure-body. Meaning, if the rotation order is XYZ with Z being twist, i have to apply the rotations in the order ZYX, and if i already calculated the angles for XYZ i could not use them (there is no easy way to convert euler angles from one system to another i am aware of).

Quote - There may be no way to resolve this, in Poser.  In other software, you can set rotations using quaternions, which don't have the same problems.  Unfortunately Poser Python allows one to query an actor's quaternion rotation, but you have to set the dial values with euler angles.

I am not sure if quaternions would be of great help here, since they often are not doing what i expect them to do. If you ever tried to apply a curve modifier in blender using a curve that is not aligned against the x-axis, you know what i mean. Very hard to understand what is going on IMO.

Quote - The first link of the chain of bones turns relative to the body of the figure, perhaps this is where your error is, or do you mean by "first link" the body?

I was using a sort of muddled shorthand to communicate.    The BODY rotations are set to zero at start and the first link inherits rotational data which is in worldspace, not localspace.  The angles it processes are relative to UNIVERSE, then, and not relative to the BODY.

I'm using some matrix math involving the rest matrix (basically just the axis orientation, here, since we're in a straight line) of the actors to remove the rotation order problem.  That trick isn't working, however, for that base link.  I'm trying to work toward a process which avoids explicating the rotation orders or treats the axes differently.  Perhaps that is unavoidable at this point, however.  Hmm.

I'll have to think about how these ideas might help with the setup I have.  It's working, aside from that periodic problem with the base link.  I don't think I need a change of process, overall.  Just a procedure for the first link in the chain.

It sounds like you've dealt with something similar, in the past? 

If anyone wants to test the current state of the posing script, I've uploaded the script and the test pz3 I'm using to my site.

http://www.the.cage.page.phantom3d.net/looper/chain_pose_test.zip

Unzip the folder and load the pz3 directly, then run the script.

Erm... note that the Wx GUI will only work in P8 or PPro. 

A dot product test of the world matrix of the posed base link against the matrix from which the euler angles are derived (using the twist axes of both) reveals that the problem is bad euler conversions.  Using that test, I've been able to identify the bad cases when they occur and try to compensate.  The best (and most trivial) solution turns out to be just flipping all of the euler signs and re-setting the rotations for the link.  Or the best one I can come up with right now, at least.  :unsure:  This doesn't seem to correct all of the problems 100%, but it reduces them to the point where a worst case now seems to be a slightly misaligned base link, rather than a horribly aligned one followed by an ugly snarl.

I've moved on to testing animation.  The process works, but posing turns out to be much slower than creating an animated prop (depending on the mesh resolution specified for the prop, anyway).  A 30 frame animation takes 32 seconds for a prop with the default script settings, verses 1 minute, 37 seconds for the posing.  I think the animated prop generally looks better, too, and the start and end links can be more effectively constrained.  So if one wants an animated chain from a path, the prop script may be the better option.  The posing script, ironically, may be better for static chains.

I'll try to speed up the posing script a bit and optimize it, but I don't hold out much hope of improving the euler conversion problems where they still exist.  So the posing script may be nearing completion.

I'm pleased to note that 'Rosity seems to be running more smoothly again.  :thumbupboth:

A dynamic hair styling tool would be amazing.

Yeah, we could really use one.  I keep mangling Douglas Adams by stating that the current hair design tools steer like two drunken cows.  :unsure:  :lol:

They've opened up most of the settings for the Hair Room to Python, so one could pretty much recreate the Hair Room as a script.  All aside from those styling tools, but those are the problem right now, anyway.

The shaping is baked into the mesh, so all of the Hair Room tools can be used after the path curves are used to position hairs.  The vertex count per hair can be changed.  Dynamics work nicely.  The only thing you can't do is use the Growth Tools after shaping the hair, or the shaping is dropped.  This seems to be true of any shaping applied using the styling tools too, however, and it can be undone.  So things look promising, so far.  I'll keep tinkering.

Meanwhile I'm halfway through updating the extrusion and chain prop scripts for new features, and I have a couple of thoughts about how to approach the base link problem, and possibly the speed issues, with the posing script.  When you're stuck, sometimes it helps to step away from something for a bit, perhaps.  :unsure:

A Hair room tool, that would be awesome.

Just because people don't comment on your posts please don't get discouraged, I bet there are many are reading them, learning from them and using the great tools you developed so far. You go on great streaks of information and I'd hate to post and break the flow, because I may return to reread them. 

Thanks, GeneralNutt.  :laugh:  I don't know that I get discouraged, but I am sometimes puzzled that there's no apparent interest in something.  But, then, I'm immersed in the material, so it may seem more compelling to me than it actually is.  :lol:

Given that the Hair Room styling tools can still be used (particularly for things like tapering a lock) after any script-imposed shaping, I think the script would just need to cover a few different ways of styling a hair group along a defined path.  Seen above is each guide hair individually shaped to the path.  I'd also like one or more options which handle clusters of hairs as a group.  I'm thinking of applying a sort of path grouping to hairs which line up on Y, but X and Z might be useful, too, for some kind of layered styling.

I mainly find the rotation tools in the Hair Room unmanageable.  The translation and scaling tools aren't as bad.  I think paths could help with rotation.

I may be thinking fairly small.  If anyone has any thoughts about tools which could be useful, please let us know.  :laugh:

The only thing I ever made in the hair room I was satified with was grass. If you could make a tool that allowed the user to make a path and edit the path while moving the camera around, that would be somewhat helpful I think.

Well, the path is three dimensional and you can rotate around it as you work.  If I scale down the path markers, compared to their size in the other scripts, you should be able to place them around the target actor to see precisely where the shaped hair will be.  Not quite as simple as being able to draw around the actor or create an actual spline object, perhaps, but not too complex.

Two chain objects with each 4 links, that i can use for testing. One is nice, each link aligned on xyz, the other one is not nice, each link unaligned, different rotation order etc. The latter has a white top, to check where z is. The rotation centers are visible through the colored arrows (red=x, green=y, blue=z). Perhaps you (or anybody else) have some use for them. I sometimes get the idea of converting a character's skeleton to eg blender or so and that is usually the time when i stumble over those euler angles (every time again:-)

(tried to use an image hoster for this post, if there seems to be no image, try  http://postimage.org/image/3r9p6eis/ )

Thanks, millighost.  I can say right off that the nastier of the two chains will not work with the posing script, which assumes that the joints for the figure are handled rather more, ah,  conventionally.  :lol:  I'm specifcally interested in supporting chains constructed using the Chain Maker script at the Loop scripts link in my sigline.  So far, it works well enough with the other tube or chain-like figures that I've tested.  But the script assumes that the figure's joints are all oriented in the same direction.  It also assumes that the BODY actor is centered at zero.

But there's that problem with the base link being all verkakte.  :lol:

(Do I need a "language" advisory for Yiddish cursing with humorous intent?  I guess I'll play it safe....)

I´ve been lurking in this thread for a long time now and I must say that I'm very impressed with your scripts Cage!  The Chain Prop script is my favorite so far but that hair script looks REALLY interesting!  I don't go into the hair room for fear of the dreaded hair tools.  Hopefully you'll come up with a nice tool to help the styling process.  Keep up the good work!!

Quote - Yeah, we could really use one. I keep mangling Douglas Adams by stating that the current hair design tools steer like two drunken cows. :unsure: :lol:

They've opened up most of the settings for the Hair Room to Python, so one could pretty much recreate the Hair Room as a script. All aside from those styling tools, but those are the problem right now, anyway.

If you make it I will come....Don't take that the wrong way...or do. Just make it! :lol: I will be first in line for that script!

Quote - I´ve been lurking in this thread for a long time now and I must say that I'm very impressed with your scripts Cage!  The Chain Prop script is my favorite so far but that hair script looks REALLY interesting!  I don't go into the hair room for fear of the dreaded hair tools.  Hopefully you'll come up with a nice tool to help the styling process.  Keep up the good work!!

Thanks, Vestman.  :laugh:  If you're using the chain prop script, then I assume you're comfortable with the process for specifying the path from marker points.  The hair script will make use of that basic approach, possibly with a couple of slight changes to adapt to the new context.

That is, assuming I can work out a couple of things.  Right now I'm stuck, while trying to sort hairs into vertical strips so their handling can be varied in certain ways.  Ooh, why am I always so mixed up when there's a need for a recursive algorithm?  :lol: 

Quote - If you make it I will come....Don't take that the wrong way...or do. Just make it! I will be first in line for that script!

How do I know if I've taken it the wrong way?    Anyway, this stuff is keeping me from working on Zoe, so just be aware.  :lol:

I'm trying to work out the best approach for a hair script.  Having seen in my early tests what dynamic hair can be, minus the frustration of those dratted drag-in-the-interface tools, I really rather want a hair room tool myself, now.  So I'm motivated, anyways.  :laugh:

The hair script is coming along nicely, but with some predictable complications.  I'm trying to set it up so the user can select a normal geometry group and the script will automatically turn that into a hair group and grow the guide hairs.  This sometimes works, but other times Poser fights me and Python throws an exception.  In addition to automatically renaming the group to prevent a duplicate actor name (because the hair prop and hair group must have the same name), Poser sometimes creates a blank hair prop with no guide hair geometry.  When this happens, all hope is lost.  :lol:  :cursing:  Then there's no way to query whether the prop is valid without throwing another exception.

So possibly the script will have to require that the user set up the hair groups and grow the guide hairs before running the script.  I'll keep trying to work it out, but so far I can't discern a pattern in Poser's behavior.

I've managed to define "locks" of hairs as rows on Y or X (relative to the hair normal at its base vert, which is treated as pointing outward on Z) along the geometry surface.  That's important to be able to work out some of the hair handling I hope to set up.  So things are looking positive, overall.

I'm also trying to add one level of undo, in case a shaping proves undesirable and the user wants to backtrack.  That's working, but I always seem to have to modify the result by the inverse of the parent prop's world matrix, which seems to create a slighly messy restored geometry.  I'm wondering if this is the "matrix drift", which is sometimes mentioned, cropping up.  :unsure:

It's looking good, though, and I hope to be able to have an initial version out in 2-3 days.

The problems with creating new hair groups and hair props seems to have been resolved.  My code had gotten jumbled up at some point and I'd ended up fighting myself.  Poser creates no problems if you tell it to grow guide hairs when they already exist, which simplifies matters.

The undo process was slightly messy because Poser was automatically applying the Kink Strength setting for the hair prop, when I set the undo vertex positions.  With Kink Strength turned off, that problem is solved.  However there now seem to be problems when there's a rotated parent hair prop.  In that case, I can't seem to remove the parent rotation from the vertex positions.  I'm stripping them out with the inverse parent matrix, but they go right back in somewhere in the process.  If I un-rotate the parent, set the positions, then rotate back, Poser intially shows the baked-in rotations I was trying to remove.  Then, upon refresh, it doubles those, moving the hair vertices inexplicably.  So something I don't quite understand is happening, and undo only works properly if the hair prop parent is not rotated.

Otherwise, things are moving along swimmingly.  The attached image shows the results of the handling by "locks" which I'd been planning.  Compare the image to the earlier example I posted and you can see how the hair positioning differs.

I have a few more things to add, including handling by hair group and the option to position hairs along a defined direction rather than radially around the parent prop.  So it's getting there, but I have to push back my first release date a bit.  Didn't get much done yesterday, due to being 'under the weather'.  :unsure: