I tried to use a python script called "unimeshdemo.py" on a Koshini figure in a Poer 5 SR3 scene. It created a prop out of her, but the left thight of the cr2 became deformed with a stray vertex. I deleted the figure and the prop, but when I loaded a new Koshini figure, I saw that the stray vertex was still there ! And it is here with ALL my koshini.obj based figures ! It's not a problem with the mesh (in the image above the mesh is yellow, and the figure is white ). The JPS green spheric zone includes this vertex, UV mapper doesn't find degenerate facets... Has anyone any idea of what's happening ? And, most importantly, of what I should do to fix this mess ? Thanks in advance for your help.

In Bloodsong's book, there is a mention of such vertices flying away, but only in the render phase, and only when you try to weld body parts to illegitimate children. Could this be related ?

why not just delete koshini and the geometry etc and reinstall her?

Did you try re-installing your Koshini? Maybe the object file got corrupted.

Try deleting just the RSR file associated with the OBJ (in the geometries folder). If that doesn't work, I'd delete the OBJ and RSR and reinstall.

Poser 5 doesn't use rsr for Geometries obj. The current obj is fine in Poser (as seen on the picture above), and its normals seem OK since I can see all the polygons in all preview types. I'm really lost on this one ! ...

Compare the joint parameter settings from the good right leg to the faulty left leg, there must be something amiss there, this is a cr2 issue. Try reinstalling the figure.

If this problem affects all Koshini characters, i.e. it's common to lots of CR2s, I'd tend to think it was an OBJ problem. But I can't imagine why it only shows up when loaded as a character, and not as an imported OBJ. Something to do with welded vertices? Maybe if we all shout "reinstall her!" together..? Sorry to resort to sarcasm, it's against the TOS for sure, but it seems the obvious thing to do. Back up your existing Koshinis first, just in case.

Ouch! EnglishBob, my ears are tinting from the roar!... ;-) Anyway, time fixed Koshini : I decided to follow your wise advice and reinstall her, but I had to wait for DAZ to reset my DL list (I could not find the backup). Then I opened Poser, and loaded her : since it was a Python script that had done it, may be it would dissappear on a new start ? And, fortunately, Koshini was there, with her leg normal. Thank you everyone for your help. Now if anyone has any clue as to what happened, I'd be delighted to know...

I'm pretty sure this occurred in the OBJ file. Reading the CL Unimesh script, I see that it does in fact move one vertex outward, so this corresponds with what you're seeing. (I like to do the same thing as a debug test when writing scripts that handle vertices; it's a good way to locate the right index.) I'm guessing that when you spawned a prop, it generated a new OBJ file with the same name as the original?

It did spawn a prop in the scene, but I cannot find any new Koshini.obj in my Poser5 entire folder. Besides, I imported the original Koshini.obj (towards which all my Koshini characters are pointing) and it had no problem. I read the script. I don't understand clearly what it's meant to do, but I can see it chose the left thigh and moved vertex number 13 along it's normal (which was mostly Z oriented, hence the aspect). Now is there some sort of "clipboard" where Poser stored the modified koshini.obj, and to which the next koshini characters I loaded where redirected ? (something like the list of texture maps that stay into poser's memory even if you delete them from all materials) BTW : I decided to delve a little into Python (in the hope that I could make myself a new GUI...). I remember you (Ockham)said that Poser5 SR3 had changed the way that Poser implemented Python. Does this make a change in Poser's classes and methods (as defined in the original documentation), or have any impact on the syntax ? And does PoserPython include all the Tkinter libraries ? Thanks again.

Clipboard.... Okay, that makes sense if the error disappeared on the next Poser session. The 'unimesh' itself is sort of like a clipboard; it's a copy in Poser form of the info contained in the OBJ file. If the pointy vertex was still there after a reboot, then it obviously had to be in a file somewhere. I've never seen a file that might carry such info, but that doesn't mean it isn't there! On Poser 5: SR3 just added some new functions to control the P5 lights and other things. It didn't change the way Python works. In general, the older functions behave the same way. At one point I thought that SR3 changed the way objects are deleted, but I was probably confused. On Tkinter: Poser includes all of the "standard" distribution as of the date when it was made. But "standard" doesn't mean much in this realm! Tkinter is not well formalized or documented, and you'll find that many of the non-Poser scripts you find online will not run properly inside Poser. Partly this is because Poser has its own way of setting up the path structure for Python and Tkinter, so a script that uses the "raw Python" path methods won't find things in the expected location.

Wow. That was fast. Thank you very much.