This is somehtign some people know and something some people don't, so I'm posting it both to let those who don't know and thet get feedback from those who know more than I. Blackouts do not occur because of very thing triangles. They occur because of very thin quads that look like triangles. Degenerate facets are facets in a mesh that contain more than one vertex in the same place or so close as to confuse Poser. From what I can tell, this generally happens when you do something like import a mesh designed for another program (or just designed in another program without being scaled down to teeny Poser size) and then scaled within Poser. Thus something that may have been a very thin trapezoidal quad gets the vertices that were fine at the big size so close together that they run out of space (at least within Poser's/your computer's float limit). I also have a suspicion that this is one of the few areas that Poser will behave differently dependong on the processor you have -- here's why I suspect this: -- Technical stuff on floating point imprecision -- skip to END GEEKSPEAKif you don't want the background on why this happens and only want to know how to fix it -- Computers have a certain set number of bytes used to store a floating-point digit, and sometimes they have a few different ones. The capability of the processor to handle higher precision floats combined with the memory's ability to store them combined with what the coders who wrote the OS's kernel decided was a reasonable upper limit to expect determine that upper limit. Usually the OS is coded to handle higher floats than the processor can, which results in variable imprecision. Sometimes the OS is coded to handle something lower than the average, which results in uniform imprecision. As computers get faster and more powerful and exceed the expectations of the people who coded the kernel, the precision becomes more uniform. Anyway, the result is floating-point imprecision. It's all well and good to say, in a text file, that a number is 3.14157945623840345568932495328455392485493953722045835938, but it's another thin altogether to get the processor to read any more than, say, 3.14157945623840 -- though since the processor is TOLD more than that, it may turn into 3.141579456238406613349137843902738290 or something. That's what happens when the memory has more capacity than the processor, which it usually does. Often times coders will compensate for this in the case of math, by memoising how a given large or irrational float was reached and using the more reliable lower precision numbers to reach this. You can demonstrate this in Windows' Calculator program easily -- just divide 1/3 then multiply the result by 3 and you will get one. However, if you divide 1/3 and then copy the result, then hit C and paste it back in and multiply it by 3, you will get 0.99999999999999999999999999999999 -- floating point imprecision. This is even used to generate random numbers sometimes, like in encryption where the randomness needs to be really random. Large floating point numbers are fed into the processor and sit back out, and the difference between a low-down set of the digits in and out is used to determine the random seed or the random number itself. -- END GEEKSPEAK -- As a result, two vertices that may have been far enough away from one another up at 3DSMax size, when shrunk to the size of a Poser model becomes, for all intents and purposes, 'in the same place' and thus a quad becomes a tri, but with two vertices in the location of one vertex and a quad face defined for what looks more like a tri. Poser really doesn't like this, and it protests by indicating that it has no clue how to render the four-vertex but three-edge nonsensical facet and leaves the whole thing black. There are a few ways to fix this problem, and they aren't always consistent in success, but here's what I've found: Method 1) Export the object from Poser to a new OBJ file, then re-import this file again with 'weld identical vertices' on. (Actually I think it says 'vertexes' not 'vertices' but 'vertices' is the correct word. We could pick on them, but a super-expensive database program used by big companis worldwide -- Oracle -- says 'indexes' instead of 'indices' in it's SQL syntax variant, and even the HTTP standard you're using right now sends a message to the webserver each time you follow a link called 'HTTP_REFERER' (it should be 'HTTP_REFERRER') so there is precedent for spelling thigns wrong in good programs). Method 1 works sometimes. Sometimes it doesn't. Sometimes it introduces new facet degeneracy. Method 2) In UVMapper, go to tools and select 'Split vertices'. This method has a drawback in that it kills your smoothing groups. It chamfers EVERY edge in the mesh. Poser will no longer smooth over it. If you are making a gem or cube, this is great, because you don't want it smoothed. If you're doing a face, it rather sucks. Method 3) In UVMapper, press 'Insert' and it will tell you how many degenerate facets it finds. Keep in mind that this is not always the number that Poser finds. Then follow the prompt to remove them. The drawback to this is that it straight out removes the degenerate facets. Sometimes this works okay, and sometimes it leaves a gaping hols in your mesh. But it;s always worth a try. Method 4) a combination of the two above. Export your mesh from Poser, re-import it with weld identical vertices on, re-export it again, and then open it in UVMapper and repair the degenerate facets. THis method USUALLY works, from what I have seen, and doesn't usually leave holes in your mesh. However, your milage may vary. Method 5 AKA the pig pain the arse method) open your mesh in your modelling program and find the degenerate facets and weld them by hand, or run a target weld for all vertices within a given threshold. The drawbacks to this are a) it can be a b*tch to find them all and b) if you do a target weld on al vertices it can cause other problems in your mesh if you set the threshold too high, and if your modelling program handles numbers with higher float precision than Poser (most do) you can also have problems where not all get caught when you set them too low. One way to find them a little easier by hand is this: Open the objectin UVMapper and make the most visible, easily-readable UVmap for the whole thing you can find, and seperate outthe different groups and/or materials. Export the texture map. Then hit 'Insert' to find the degenerate facets and remove them. Export the texture map again (to a different file). Close the object without saving. Open both texture maps in Photoshop, switch them to RGB mode, and copy-paste one over the other so you have two layers with the two versions. Set the top layer's merge mode to 'Difference' and most of the image will turn black, but the places that the two don't match will be highlit in sparkling colour. Copy the layer without the stripped degenerates again and place it on top, invert it, and switch it to screen mode, than reduce the opacity of the layer to about 10-20% so it's only barely there. You can use this as a map to find your vertices. I don't recommend doing this on a high-poly object, though, because you will go mad trying to find them. If you want examples of degenerate facets, download my Asian Pole Arms pack and/or my Halter-hauberk Vicki top. These both, at the time of this writing, have extensive or noticable degenerate facets and blackouts. Or look down at my 'WTF' thread below where I was faccing this problem with simple and large triangles (or I thought they were triangles anyway) in a flame prop for a torch, if I've gotten to fixing the aforementioned Free Stuff props by the time you do. Just as a note, my non-free RMP stuff does not, to my knowledge, have any degenerate facets. Before I knew ways to fix this I would go through and rebuild things from scratch if I needed to to avoid it on anything for sale.

Attached Link: Dodger's Frivolities AKA Dodger's Free Stuff AKA Dodger's Poser Stuff

Actually, I decided to go ahead and quickly make up an exmaple picture. In this I used method 4 above. I exported the mesh, re-imported it welding identical vertices, re-exported it, and then removed the degenerate facets in UVMapper Free. The Energy Mace on the left is the new, corrected mesh, as you can see since it has no textures set. The item on the right is the version I have in Free Stuff right now, which has degenerate facets on the tips of the spikes. I plan to update this in DFS soon, by the way, and also to apply the UVmap I added to it so it can be easily bumpmapped and texture mapped. It won't be immediately, though, because I'm considering also adding one of my nifty glow-effects to the whole thing to make the rerelease a little more imprssive of a difference.

My understanding has always been that degenerate facets are those with less than three verticies (a point or a line, instead of a triangle or a quad). Collinear facets are those where the first three points are in a line. This seems to be how UV Mapper Pro looks at things. I can certainly see how one might lump them all into the degenerate category :-) In any case, the reason they are bad is that most renderers use the first three points to determine the normal vector for the facet. If the first three points don't make a good triangle, it has no way of knowing which way the surface faces, so you get a bad normal and it looks black.

Hmm, but the facets in the above example and in the WTF torch flames in my older thread are definitely > 2 vertices. This can be seen in the wireframe, in the UVMapper template, and in the OBJect file itself if I examine the facets in question in vim (there are no two-point facets defined in the file)