Hi all, I noticed PML complains when exporting figures that use poser unimesh skinning (Poser 2014). I am a bit worried about it. I think the unimesh skinning has an effect on the python functions used to ask for vertex coordinates. My current thesis is that the figure is not unimesh-ed api-wise. Due to my personal situation I will not be able to research this issue in the next two weeks. Maybe the warnings can be ignored, maybe not. Those of you with PML, please keep an eye on this. In case you find an example were the process breaks or shows significant quality loss, please drop me a message, I'll investigate then.

Hi colorcurvature, sorry OT perhaps, but... where can I purchase PML? what are the version compatibilities and is it a python implementation? I'm using a PPC based Mac (pre intel) with ZBrush 2 (unfortunately I can't seem to find my copy of PoserScaler in my archives and it's no longer available in legacy at ZBrush central) which runs with my set-up. The problem is the scaling issues that earlier versions of ZBrush had with poser morph creation that has been requiring some rather tedious post morph counter measures. Very interested in the functionality of PML.

_edit, oh yeah... Poser 8.

Sorry, but I remember there have been issues with the mac.

I think, the UI code that I used to make the dialogs, is just not there on the mac. I have no idea why this is, but the python libraries on windows and mac are different, and I didnt know this when building the tool. I used the TK framework. Technically spoken, it could be ported to the mac by using WxWidgets, but this is difficult, takes long time for retest, and few people would need it, especially as there is now goz.

You can switch back to traditional Poser Skinning on the fly. So if PML is having difficulty with Poser's Unimesh skinnig method, a user can just switch the character back to Poser Traditional skinning while working with PML.

 

As for warnings - some models are not designed for the Unimesh skinning. They may have stray vertices or bad welds that weren't noticeable in Poser's traditional skinning but would become apparent the minute you subdivide them. The program will warn you of this.  Not sure if that's the warning you were mentioning.

The warning is issued by PML itself. The program re-reads the object after export again and compares it to the figure vertex data. This is a smoke test which shall assert that the object got properly welded and exported (my exporter works a little bit different than posers built-in export, to avoid the damn orphan vertices). And with new skinning it notices something isnt right. My assumption is that the WorldVertex() functions, when used on weld-slave vertices, now return the slave-coordinate, not the welded coordinate. This is different with classical skinning, I suspect. The other option is that something always has been wrong in PML, which I do not hope, and now its right with new skinning.

My weld test figure gives interesting results in the preview too. Left is classic skinning right is unimesh skinning. We see that finally unimesh skinning computes the normals near the weld properly. On the other hand, the red preview border now outlines the unwelded actor geometry.

>>> print 'Skinning set to classical' Skinning set to classical >>> ww = poser.Scene().CurrentActor().Geometry().WorldVertex(5) >>> ww2 = poser.Scene().CurrentFigure().Actor("bone_2").Geometry().WorldVertex(5) >>> print ww.X(), ww.Y(), ww.Z() 0.0 0.468679130077 0.0 >>> print ww2.X(), ww2.Y(), ww2.Z() 0.0 0.468679130077 0.0 >>> print 'Skinning set to unimesh' Skinning set to unimesh >>> ww = poser.Scene().CurrentActor().Geometry().WorldVertex(5) Traceback (most recent call last):   File "", line 1, in AttributeError: 'NoneType' object has no attribute 'WorldVertex' >>> ww = poser.Scene().CurrentActor().Geometry().WorldVertex(5) >>> ww2 = poser.Scene().CurrentFigure().Actor("bone_2").Geometry().WorldVertex(5) >>> print ww.X(), ww.Y(), ww.Z() 0.0 0.468679130077 -0.253733992577 >>> print ww2.X(), ww2.Y(), ww2.Z() 0.0 0.468679130077 0.0 >>>

This seems to strengthen my thesis. WorldVertex(5) of the slave actor in my figure returns different coordinates, depending on classic vs unimesh skinning.

 

wg = poser.Scene().CurrentActor().WeldGoals()
print wg
[[-1, -1, -1, 3, 4, 5, -1, -1, -1, -1, -1, 11, 12, -1, -1, -1, -1, -1, -1, -1, 20, 21, -1, -1, -1, -1, -1, 27, 28, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1]]

Vertex 5 is chosen because it has a weldgoal.

Based on this output and the unwelded preview frame in the picture I suspect WorldVertex() is not returning the truth when unimesh skinning is active (assuming, the welded position should be the world vertex coordinate).

So I indeed guess, PML should be used with classic skinning.

P.S. Subdivision is still fine.

Hrm. I have the feeling that also Poser cannot export properly with unimesh. It might be using the same function as I do :-). When unimesh skinning is active, the export will get exported unwelded, even if "weld" option is enabled.

Left: PML export (looking good)

Right: The figure

Top figure: Figure exported by poser with classic skinning

Middle figure: Figure export by poser with unimesh skinning

I've noticed this with exporting figures from Poser to model on. When I import them into Wings, they are unwelded. I have to reweld the mesh or I end up trying to work with 70+ parts.

I've noticed some strange deformations when importing old scenes with PML morphs. Will look into this some more.

Ugh.  I'm not sure what issues you are seeing. But if others also notice PML-based stuff is breaking, please say so and I'll try to help or beg dev team for help if I can't.

I hadnt noticed any issues with PML during the beta time, but I was working only with some dummy test figures. If there is really something weird happening with things PML made (please double check), I think that should also be crossposted to rdna, so we can hopefully get a fix.

Just tested it and no problems with PML in PP-2014.

That is, as long as you use the old skinning method.

The new unimesh skinning and subdivision also works fine with my old 3rd Gen figures. Much, much, really much better than the Genesis subdivision !

(Poser complains about a few stray vertices, though.)

What you shouldn't do:

Try PML with a figure while it is set to Unimesh skinning. Use Unimesh skinning once you finished creating morphs with PML.

Do not set a figure to use Unimesh skinning, safe it in a scene in PP-2014, and then open the scene with an older version of Poser. This will cause some serious deformation. (Some props will be missing, too)

(Pretty much like you can't use a weightmapped figure in Poser 8 or earlier)

So far the only nuisance was that PP-2014 can't find my custom EZSkin definitions.

But it is fast. I mean, really fast compared to PP-2012.

 

 

http://forum.runtimedna.com/showthread.php?78956-Big-issue-with-V4-in-PP2014

Appearently there is some general issue on bending, this has nothing to do with PML, I think.

This might affect any fix morph package around.

But the problem seems  PML-independent.

I bet it's the joint bending magnets. Maybe the addition of weightmapped magnet functionality has something to do with it ?

Rex' arms are also broken in PP-2012, and I think he uses magnets, too.

No problems with my weightmapped figures as far as I can tell. The JCM's I made with PML work just as well as they did in PP-2012.

Nope, no difference at all for DavidWM.

Here's the PP-2012 render.

Here is PP-2014.

And here is Rex' broken arm in PP-2012. (I used the legacy skinning for both)

Yep, at least for Rex, the shoulder-bulge magnet is the culprit.

Yes, it wasn't PML as I thought. Sorry Col, my mistake. Or should I say SmithMicro :(