Forum: Poser - OFFICIAL


Subject: Please help! Wayward vertices

bergerac opened this issue on Dec 31, 1999 ยท 5 posts


bergerac posted Fri, 31 December 1999 at 9:38 AM

When I originally made this dress I only had UV direction going one way. Because I wanted to be able to view the inside of the dress while posing the model, I duplicated the surfaces, reversed the UV direction on one, joined the surfaces and converted to poligon mesh. (Working in Rhino) It seems that I solved one problem and created another. For some strange reason some of the vertices on the seam reflect the light differently. Any ideas what I could do to correct it? Would it help to weld the surfaces before creating the mesh? Any suggestions will be welcome. Thanx Berge

Traveler posted Fri, 31 December 1999 at 12:17 PM

Looks like you are suffering from the dreaded black verts (thats what I have been calling them, among other things) I bring a mesh into any program but poser and the mesh looks fine, no holes , etc. I bring it in to poser and sometimes some of the polys are black when rendered..... I have tried: -Stripping the normals from the .obj -Selecting the bad verts, making a new group, and reversing them -Retexturing with every mapper -Converting to .dfx and reconverting to .obj (which drops all the smoothing) -Correcting the normals in every program I have.... I am thinking this may be a poser bug? -Trav


WarriorDL posted Fri, 31 December 1999 at 12:42 PM

I've discovered those in Lightwave as well. I don't know if you can check in Rhino or not, but see how many edges they have. My solution in Lightwave was- 1 or 2 edges- Delete. 3 or more- Triple. For me in LW, it works everytime.


Anthony Appleyard posted Fri, 31 December 1999 at 6:23 PM

Black is "red=green=blue=0". Also, with curved tails of parts more complicated than plain cylinders like an animal's tail (corrugated breathing tubes, flat backpack straps), they sometimes neck off when posed, and come back to correct when moved a bit. I suspect that here and there in Poser there are arithmetic errors (INF = infinity = divide by zero), NaN = not-a-number = indefinite = 0/0 ), arcsin(x) if x*x>1, sqrt(-ve) etc, which caused crashes until some programmer whip-driven by some silly deadline quickly kludged them away by trapping the exception and setting the offending value to zero, regardless of what it should have been. RELEASE THE SOURCE FORMS OF POSER AND BRYCE, so we all can help to look for causes of bugs as is with JPG and the Gnu software. They say that some devils take the forms of goats; likewise here: the INF-amous NaN-nygoat may be the cause of these bugs :-) .


bergerac posted Mon, 03 January 2000 at 2:12 PM

Wow! And I thought maybe I had just done something stupid. I was kinda hoping for a simple solution. Perhaps I should acknowledge that I'm out of my depth now and go back to the reliable old pencil crayons :) Seriously, guys, thanks for the help. At least now I know that I will have to try some work-arounds. I'll try some of your suggestions. Berge