I'm looking for a way to implement a smoothing algorithm for Poser weight maps and morph deltas. In line with a request that Poser implement a new option for delta smoothing and flattening in the Morph Tool, rather than just mesh vertex smoothing and flattening, I'd like the option to retain details that are modelled in the original mesh. The easiest way I see to do this is to smooth the deltas, rather than the vertices.

Since deltas are just another form of 3D vector, they should be equally amenable to smoothing or flattening, in the way that vertices are. Having commenced my research, I realise that there are a great many algorithms available for smoothing meshes. Is anyone aware of, and permitted to reveal the algorithm that Poser uses for smoothing, assuming that it is a recognisable standard, like Smart Laplacian, Centroidal Voronoi Tesselation, Optimal Delaunay Triangulation, Weighted Centroid of Circumcentres, Angle Based Smoothing, or Well Centred Triangulation. [Noting that these all apply to triangulated meshes, rather than quad or arbitrary meshes]

While I expect that there will certainly be a substantial delay before any new features are implemented in Poser, I would like, if possible, to use the same algorithm for delta smoothing as Poser already uses. I'm not envisaging a complete GUI solution like the Morph Tool for this Python script, but being able to apply an overall smoothing to a mesh, and vary the number of iterations should provide a useful way to restore mesh details that are distorted by existing or newly created morphs.

It should also prove applicable to smoothing weight maps which may not always transfer accurately to conforming clothing from a base figure.

I don't know what Poser gives you access to. For instance, as per usual, there are lots of command possibilities for the wavefront object file format. And, just about everyone that implements it has decided to supersede or subsume many of those functions. Probably for the better, to be honest. :) http://paulbourke.net/dataformats/obj/

Poser's Smoothing Tool relies on user-input and placement of selection, first. That random component interacts, as far as I can tell, by doing a simple weighted average of vertice positions weighted for their neighbors and their distance from the object center. ("Object" also being treated as the targeted Group for "object center" purposes.) Sorry, I don't know if there is a specifically named algorithm for what Poser uses, but I really don't know that matters right now. It's probably a variant/simplification of Laplachian smoothing. (No idea, honestly, 'cause it's not easily predictable and can not be user-selected, so I never bothered trying to figure out what it was.) (http://www.faculty.jacobs-university.de/llinsen/teaching/320491/Lecture13.pdf ) Laplachian is also mentioned, below.

I came across this and it may give you some ideas on how to isolate "details" in topologicial features: https://link.springer.com/content/pdf/10.1007/11428831_2.pdf

So, the basic takeaway here is that they have figured out that determining the "angle" being represented is key to preserving detail. And, it makes a heck of a lot of sense for your particular operation. What are topological "details?" We know intuitively what they are, but from the topo point of view, they're larger deviations in relative angle from the surrounding topology. That's a sort of no-brainer. (I think the paper is more about sub-d than "smoothing" and that's why I can's stand the two terms being used interchangeably. :) )

So, forget about pushing verts or, rather, relative delta values, which not only rely completely on the original vert reference, but also the winding order for the object/group. :) Focus on "angles" and stuffs, first, i think. A delta is fairly meaningless without knowing what vert it references. And, to take the entire population of them and just figure out what a "detail" is by examining them individually isn't possible. One has to compare relative verts, from the original reference and the surrounding verts. And, the best way to produce something useful may just be analyzing relative angles, instead, against the surrounding topology. Bigger angles inherently mean larger deviations from the surrounding mesh, which inherently means "surface detail."

<-- Is not a maths dude, sorry. :)

PS - I also don't know what Poser's CR2 format brings to the table in terms of features nor what is a geometrical eccentricity of Poser you could take advantage of. In terms of just pushing-verts-tech, I think the "angle approach" is.. the best angle to approach this? :)

Thanks for your reply in the absence of any other responses. The primary purpose (apart from its applicability to weight mapping) of this smoothing is really intended to eliminate distortion of original, unmorphed mesh details by Morph Tool created morphs. Unless the constant (no falloff) morph tool is chosen and applied to the entire mesh, the deltas created while morphing will always tend to increase or decrease the distance between adjacent vertices in the mesh, thus distorting any details designed into the mesh. For flesh or clothing, that's mostly irrelevant, as they represent flexible media. Unlike the cloth room, which can designate rigid decorated groups and move them in fixed relation to the surrounding dynamic mesh, the Morph Tool can only exclude groups from delta adjustment, not move them without distortion.

I have other script tools which, like some of PhilC's toolbox scripts, can perform boolean logic on one morph, based on which deltas of another morph are non-zero. I can also apply those algorithms to ensure that vertices defined as part of a specific group indicating a rigid decoration will all have the exact same delta applied. That's a meaningful thing to do for small rigid decorations like buttons, but is not appropriate for distributed, modelled mesh, soft decorations like stitching or lace/turned hems. If those areas need to be morphed in a piecemeal fashion, then delta smoothing seems the only applicable method of repairing distortions in their intended shape.

an0malaus posted at 9:33PM Thu, 18 July 2019 - #4357298

Thanks for your reply in the absence of any other responses.

:)

Yes, I stared at your post and thought someone should try... ;)

Unless the constant (no falloff) morph tool is chosen and applied to the entire mesh, the deltas created while morphing will always tend to increase or decrease the distance between adjacent vertices in the mesh, thus distorting any details designed into the mesh.

This is a "Bloat" or "Inflate Geometry" sort of effect. IMO, it's a result of it including an object-center cardinal direction. AFAIK, even checking/uncecking normals will have the same effect. It's worth noting, however, that because the tool will differentiate the degree of inflation, it tends to put more weight on dense areas of vertices and less weight paid attention to for the object center because of that. It's still going to bloat the mesh - We don't have a manipulator to play with. Even the "based on screen" morphing doesn't pay attention to a camera position that deviates significantly in angle of a path drawn from the target location to the vertice being pushed. Somewhere in there, it still has to pay attention to the group's center (The morph tool is really wonderful, but one hits a hard-stop without a real manipulator, eventually. :( )

I have other script tools which, like some of PhilC's toolbox scripts, can perform boolean logic on one morph, based on which deltas of another morph are non-zero. I can also apply those algorithms to ensure that vertices defined as part of a specific group indicating a rigid decoration will all have the exact same delta applied. That's a meaningful thing to do for small rigid decorations like buttons, but is not appropriate for distributed, modelled mesh, soft decorations like stitching or lace/turned hems. If those areas need to be morphed in a piecemeal fashion, then delta smoothing seems the only applicable method of repairing distortions in their intended shape.

I don't see how that will do a lot to actually "preserve" details. Yes, you can selectively sub-d areas and the like, but a detail is a significant deviation from the surface of the mesh... basically. So, for instance, density doesn't mean detail. Small groups don't mean "detail." The easiest differentiation from the surrounding surface to yield a discovery of detail is like "relative angle from averaged normals" or some other acceptable deviation from a nearby planar average of one group of morph deltas. (And, it keeps you from having to have an original object, too.)

I hope you get it figured out! If so, be sure to update. Interesting stuffs is interesting. :)

Morkonan posted at 3:38PM Fri, 19 July 2019 - #4357411

I don't see how that will do a lot to actually "preserve" details. Yes, you can selectively sub-d areas and the like, but a detail is a significant deviation from the surface of the mesh... basically. So, for instance, density doesn't mean detail. Small groups don't mean "detail." The easiest differentiation from the surrounding surface to yield a discovery of detail is like "relative angle from averaged normals" or some other acceptable deviation from a nearby planar average of one group of morph deltas. (And, it keeps you from having to have an original object, too.)

I'm not referring to subdivision at all, here. My instinct is that unlike smoothing of the base mesh, which will iron out 3D detailing, smoothing morph deltas will generally preserve/restore flattened details, much as the restore tool does, but without reducing the deltas to zero, averaging them all to an overall constant value.

I've written scripts to do that for buttons, once the buttons are separately grouped, I identify the non-button vertex nearest to the button's centre and apply its deltas equally to all vertices of the button. I know that this does not deliver interpolatable rotations, since deltas are translation only.

This is all interim attempts to solve something which I would hope Poser could eventually incorporate as standard: vertex following decorations that preserve the relationship of normals between prop decorations and underlying vertices, as Poser's dynamic hair does automatically. E.g opening a collar lapel rotates the cloth, so a button on the lapel should follow the closest vertex and acquire the same rotations as the cloth normal at that vertex. Extracting Euler angles from normal vectors is somewhat straightforward (except for identifying discontinuities in angles during interpolation, and determining the correct quadrant for each angle).

I get around the interpolation of translation encoded rotation (i.e. the rotation encoded in morph deltas is only without distortion at morph values of 0 and 1, not between) by having a magnet deformer for each button which derives rotations from valueOp dependency on the morph value.

an0malaus posted at 5:12PM Sat, 20 July 2019 - #4357427

I'm not referring to subdivision at all, here.
This is all interim attempts to solve something which I would hope Poser could eventually incorporate as standard: vertex following decorations that preserve the relationship of normals between prop decorations and underlying vertices, as Poser's dynamic hair does automatically. E.g opening a collar lapel rotates the cloth, so a button on the lapel should follow the closest vertex and acquire the same rotations as the cloth normal at that vertex. Extracting Euler angles from normal vectors is somewhat straightforward (except for identifying discontinuities in angles during interpolation, and determining the correct quadrant for each angle).

I get around the interpolation of translation encoded rotation (i.e. the rotation encoded in morph deltas is only without distortion at morph values of 0 and 1, not between) by having a magnet deformer for each button which derives rotations from valueOp dependency on the morph value.

Ahh... I see. Yes, I knew that you weren't talking about sub-d, I just mentioned that was what the paper was focused on, but the principle it stresses is sound, overall, in regards to topological "details."

But, you weren't talking about contiguous geometry. You meant "details" like buttons/etc! Gotcha. (Could be contiguous, one assumes, in certain circumstances. But, the objective is to isolate these "detail/decoration" groups of verts to preserve their "details." OK, now I see what you're focusing on.)

As you noted, to preserve some relative relationship for a separate group of geometry, or at least one that needs to be kept unmorphed/rigid, during a deformation of the base mesh the solution is to rig it... ie: A magnet is a sort of "rigging" object. But, we can't easily rig just anything we want with a real bone and stuff. The "vanilla" way to prevent such groups of verts from being deformed is to assign them a material of their own. Except... We can't "exclude groups/materials" from the Morph tool. We can only include them. (That's a dumb thing, IMO. :) ) We can, however, render groups "hidden", which helps a bit. Not much, though.

There have been conversations about something similar to this in Renderosity's forums. All of these kind of things end up with people trying to "do what they want to do with what they have." Some work, some don't. Most have involved isolating the geometry with separate material zones or ghost rigging.

To clarify - Is the operation primarily focused on certain desired results for clothing items or is the intent to make it equally applicable/useful for many different sorts of geometry operations? (ie: Both preserving geometry for button deforms/morphs during clothing movement/morphs and keeping figure fingernail material groups in their proper place? :) ) The reason I'm asking for a distinction is because I wonder if you can make use of the clothing engine to take advantage of its hooks for "decorations." I don't know how deep one can access it, though.

Have you thought about just taking this all outside of Poser and strictly Python, then bringing it back in? ie: If the box sucks, get out of it and only come back when you have to. :)

Yes, I would like the solution to be generally applicable. Unfortunately, the Poser Python API does not support the creation of new groups. Full stop! [Pause for breathing, heart rate and blood pressure to return to normal...] Reloading a figure you're trying to fix morphs on is not acceptable as part of an automated solution, which is the only possible way to have python add groups. It also runs headlong into Tony Vilters favorite problem: vertex duplication at actor group boundaries, which borks the ability to simply save a new version of the figure mesh with added groups without extra vertices breaking all the morphs.

That said, I have implemented an algorithm which can identify the edges of an actor's facets which are not shared (seams) and can map actor delta indices to original mesh vertex indices, so I could save a modified figure OBJ without vertex duplication.

Rigid decorations are one thing. I envisage a solution which will apply to soft decorations (like lace hems, etc) as well. Rigid decorations like buttons are well suited to one set of solutions (constant falloff deformer control), while soft decorations either require default deformer falloff, or are completely unsuitable for such control. Think of shirt collars, which are semi-rigid.

The original concept is to repair morphed clothing which was badly morphed when my skills and available tools were crude. If the Morphing Tool could smooth deltas, I could just select problematic morphs and just restore flattened details by painting along hems, etc. Maybe it's worth asking whether the Morphing Tool could have an open API, so new, add-on tools could be implemented. [Not holding my breath. I'm sure Bagginsbill will get his Custom Material Node API before I get hooks into the Morphing Tool]

I would certainly like to see programmatic support applicable to modifying weight maps (for deformers, as well as joints) within Python. Many's the time I've wished I could apply a linear falloff that doesn't require my non-existent painting skills to acquire uber-ninja-super-saiyan status to get the job done. ;-)

an0malaus posted at 12:33AM Sat, 27 July 2019 - #4357895

Yes, I would like the solution to be generally applicable. Unfortunately, the Poser Python API does not support the creation of new groups. Full stop! [Pause for breathing, heart rate and blood pressure to return to normal...]

LOL!

I seem to recall python scripts that created objects and groups (ie: Ropemaker, some chain creating scripts, etc) so I assume you mean that you can not override/rename or add groups with an internally run python script using Poser's hooks.

That said, I have implemented an algorithm which can identify the edges of an actor's facets which are not shared (seams) and can map actor delta indices to original mesh vertex indices, so I could save a modified figure OBJ without vertex duplication.

On vertex dupes - Please, correct me if I am wrong. But, vertex duplication in Poser is "virtual." IOW, it's only on the Preview Stage where border verts are duped so they'll conform to Poser's... whatevertheheckitis that requires duped verts for multigrouped objects that, for some reason, Poser loves to break. For instance, on a simple Export, these verts disappear from the object, even if it was multigrouped.

Now, if you're talking about creating a "new group" in an existing group and having verts duped, thus completely borking any vertice order that could have ever existed for that multigrouped object, I follow you. I don't mess with Poser's Grouping Tool AT ALL. Why? Because it's "Poser's Grouping Tool," that's why. :) I would like to shoot it in its face with a bazooka... It's about as intuitive as a football bat and less useful...

Rigid decorations are one thing. I envisage a solution which will apply to soft decorations (like lace hems, etc) as well. Rigid decorations like buttons are well suited to one set of solutions (constant falloff deformer control), while soft decorations either require default deformer falloff, or are completely unsuitable for such control. Think of shirt collars, which are semi-rigid.

Ahh... I seeee what you're doing, there.. (Looking at the above earlier quote.)

OK, gotcha. So, basically, you could regroup all the fluffy-floppy bits that weren't already given special groups, do with them as you will with dynamics, and then not have to worry about "Oh well, none of the friggin' morphs work, now" problems. :)

But, the workaround for that was always, at least I thought, creating a new prop from the existing figure/prop for that specific animation. Yeah, sure, it was a DUMB solution, but it was one... :)

EditAdd: The "solution" is for Poser to stop mucking around with original object geometry and use virtual dynamic "groups" that simply assign verts to dynamic cloth groups instead of assigning actual object vertice groups to some wacky sort of scheme... For enabled objects, the settings/groups would be added in the CR2/Pose object file format, preferably without completely borking those up with incompatible entries because various versions of Poser apparently didn't ever include protections against error checks... "WTF is this? I dunno, better crash completely and corrupt every single critical process we can!"

The original concept is to repair morphed clothing which was badly morphed when my skills and available tools were crude. If the Morphing Tool could smooth deltas, I could just select problematic morphs and just restore flattened details by painting along hems, etc. Maybe it's worth asking whether the Morphing Tool could have an open API, so new, add-on tools could be implemented. [Not holding my breath. I'm sure Bagginsbill will get his Custom Material Node API before I get hooks into the Morphing Tool]

Do you have any doubt BB will beat someone over the head from across a table if they dare deny him that?

"We're glad you're all here! OK, first, let's talk about-"

"Firefly can never properly render IDL, especially AO elements in room corners, and Poser's default Lighting was never correctly implemented and the Materials system needs a true compound node system and the forums never appropriately notify me of message updates and-"

"-what you guys want for lunch."

(Much love for BB and other Node-Culters. :) )

I would certainly like to see programmatic support applicable to modifying weight maps (for deformers, as well as joints) within Python. Many's the time I've wished I could apply a linear falloff that doesn't require my non-existent painting skills to acquire uber-ninja-super-saiyan status to get the job done. ;-)

I want a honest-to-goodness manipulator.... If someone dared to add edge-loop or true vertice selection to that, I'd probably faint. And, of course, if Poser's "Smooth" and "Tighten-to" (ie: Lay On) didn't bork itself up every time it literally breaks certain mesh densities and or got its normal conflicts conflicted. In these cases, I'm not quite sure if there are any OpenGL related issues, there, for some sort of "out of range" problem. Not all breaks or wildly displaced verts show up in OpenGl display until the object is saved/reloaded, so it could be a memory issue or... wtf.

Anyway, I know I'm droning on,,, :)

The point is well-taken, though - There are some technical additions that could be a very real help. The trick is, though, demonstrating where the lack of these changes show up and reduce quality or capability of the product. So... "What if" examples that directly address these issues in the most common form (here's a pic "visual" form) would probably give the best evidence to help incentivize their inclusion, "bad painting" skills or no. :)

If Poser developers could do something to help keep scripts from getting orphaned in every release then I'd be kinda happy about that. I literally DREAD every iteration and patch of Poser for that ever-present problem. What happens when EZSkin versions no longer work after Poser has depended on them for all this time? SceneFixer is... critical for me. The Lighting Manager is pretty cool, too, for cleaning up older stuff and for figuring out WTFISWRONG when a scene doesn't render quite right in Firefly. "etc" And, of course, I hate Poser's native render settings window because it's dumb and reminds me of plastic hair and surprised hobos like Dork, preferring the scripted optional addition...

So, making some additions to Poser's Python capabilities would be very cool. But, I swear, if your insistence for hooks/script additions oprhans EZSkin and SceneFixer, Imma gonna be miffed... :)