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... :)