Sharen, first let me say how grateful I am of you and your husband's continuous generosity within the community and the wonderful models you give away every week. They are top notch. I wanted to ask if those models are supported in Poser 5. I had rendered a couple of them, very early models though: the piano and the phonograph, and they show some errors in both Firefly and Poser 4 renderer. They render fine in Poser 4 and ProPak. Here are two examples with the Piano and the phonograph. I think this might be a problem only with very early models but just wanted to ask cause i know some of Kozaburo's hair had problems with Firefly and there was a workaround were you give it a displacement value and it fixes it. Maybe there is some trick to make your models render correctly in Poser 5 that you might know?

I do know that the displacement maps work in most of the older free models and regular ones as well. I have to go get my notes out but I do no that Mazak has figured it out perfectly...let me look and I will get back to you if someone else doesn't do it before me. Sorry for the inconvience...I know that this has been an issue with some of the older models. Sharen

Try setting the difuse node value to 0, and use the alternate difuse node instead. ~DM

I've seen this happen in several models, and even occasionally in my own work, so I spent a lot of time trying to track it down. What I discovered is that this is not really a Poser or Firefly problem, but can happen in many types of render engines. In fact, it happens in UVMapper, so I have learned to use that program as I model to check my work (just be sure that the "Render Backfaces" option is turned OFF). See the attached screen-cap from UVMapper which is two simple boxes which intersect and overlap each other - it shows the blackened surfaces effect and the hashed shading where surfaces overlap. The actual cause of this is two overlapping surfaces in EXACTLY the same plane when one of the surfaces has normals (more accurately winding order) reversed with respect to the other surface. Fixing this in Poser is not always easy or even consistent because it depends on how the surfaces are grouped and materialized. If the surfaces BOTH are in the same group AND have the same material applied, there is NO way to have it render properly in Poser5. If the two surfaces have DIFFERENT materials, then using very slight displacement on ONE of the materials will provide enough separation between them to have them render. Using the Alternate Diffuse method might help render the black surfaces which are NOT overlapping, but will do nothing for the hashmarks on the ocerlapping areas. The best solution is to avoid overlapping surfaces as a model is being made.

Ron, Does this happen when models are saved out of uv mapper WITHOUT normals? And does anyone actually save poser models with normals? I always dump them to cut down the file size, and poser has no use for them anyway. mac PS If the normals are causing the problem, a possible solution would be to remove them altogether.

Mac,
This is one of those 3D modeling concepts that is difficult to explain clearly, but simple to understand once you know how programs create 3D meshes. Anyway, I'll try ;-)

All surfaces start with a single polygon, and the most simple polygon that defines a surface is a triangle. So if you imagine that you have a sheet of paper, and you draw 3 dots (points) randomly anywhere on that paper and you will have the beginning of a polygon with 3 Vertices.

But to actually draw the polygon surface, you must connect the dots with lines and fill in (shade) the enclosed area.

Now imagine that you are connecting those dots on the paper. No mater which of the three points you use to start, there are only two ways you can connect to the remaining dots without lifting your pencil from the paper. You can connect them in a clockwise direction or a counter-clockwise direction. In fact when you originally placed the dots (if you numbered them dot1, dot2, dot3) you would see that there was a rotation order which was actually defined when the dots were originally placed.

Now, to a computer, 3D meshes are just a collection of points in 3D space that are defined within the mesh as a collection of one point after another in a long string (the last point in polygon#1 becomes the first point in Polygon#2 etc.) and here too there are only two rotation paths possible to wind you way through the entire mesh: in a clockwise or counter-clockwise spiraling manner (this is known as Winding Order and it is defined at the time each polygon is created in a modeling program).

The actual SURFACES do not exist in the mesh itself, but are filled-in (shaded) only at render time. Now any given polygon can have 2 faces that might be shaded (the front face - sometimes called normal face and generally meant to be the one facing the OUTSIDE of an object - and back face or the one facing the INSIDE of the object).

So, it is important for the computer to know which of the two faces to render because it would be a huge waste of resources and time to make the computer do calculations for BOTH surfaces of each polygon when 99% of those back faces can not be seen anyway because they are on the INSIDE of a closed object. So, by convention (and for some technical reasons too) only ONE of the two possible polygon surfaces are rendered --- but which one?

Early on in the history of 3DCG modeling, a single convention for determining which of the two faces to render was adopted by MOST but not all modeling programs. That convention is called the Counter-clockwise rule. In other words, if you place 3 points on a piece of paper (or 3D space) and draw the points in a counter-clockwise pattern, then the face that is facing YOU is called the normal face and is the one to be shaded. If you draw the points in a clockwise pattern, then you will be looking at the BACK face of the polygon which is not always shaded by the renderer.

A simple way of visualizing winding order and face normals is the Right Hand Rule - Hold your right hand in front of you, with fingers curled and thumb sticking up. If the fingers point in the direction of the winding order (point-drawing order) then the thumb points in the direction the normal face will be facing. This is called the normal (note the small "n") for the face.

Now all of this is fairly easy to visualize and control when dealing with triangles and simple primitives, but for more complex shapes, winding order is a real PITA to have to manage manually because there are many deformations that can cause the winding order to be changed in a mesh even if it starts out in the right direction.

So, modeling programs found alternate methods to describe which surface should be rendered - not to replace the winding order method, but to make it easier to visualize, control and correct in the event of a conflict. This is ADDED information in the mesh in the form of extra points for each polygon which describe the DIRECTION of the normal face (irregardless of winding order) - this is called The Normal of the polygon, or generally speaking, "Normals".

The only problem with Normals (capital "N" meaning information ADDED to the mesh) is that there are several ways to create them, and not all programs agree on which is the standard way. You can make them based on the Vertices, or based on the Polygon, and there might be other ways. This is not a problem as long as you model and render in the same program, it doesn't matter - your "Normals" are managed for you and generally look proper when rendered in THAT program. The problem arises when trying to render that mesh in a program that uses a different method of describing Normals.

Poser is designed to import a wide variety of mesh types, but because of differences in Normals, rather than trying to figure them out, Poser just ignores them and creates its own normals based on the good-old-fashioned winding order. Note carefully here that Poser DOES use normals (re-calculated based on the winding order of the mesh) but DOES NOT use Normals (the extra embedded data in the mesh).

A good modeling program (IMHO) is one which insures that Normals and Winding-Order always agree with the widely accepted standards. If you flip the Normals, the program should adjust the winding order correspondingly. Unfortunately not all modeling programs do this. They are sloppy about winding order because they think that the "Normals" data will still insure proper rendering, and as long as you keep your mesh in that program they are right. But they arrogantly insist that if you want to render THEIR mesh in a different program, then THAT program must recognize THEIR methodology even though it is sloppy.

And THIS is the reason Poser (rightfully) ignores embedded Normals because they are sometimes unreliable, and can slow render times significantly. Sticking with Winding Order normals makes for faster and more reliable rendering, but it does place extra demands on the modeler.

So, to answer your question...
Poser will NEVER use the Normals data embedded in the mesh file, so you might as well NOT export it from UVMapper because it just bloats the file. So THESE are not the cause of the problem illustrated here. The Winding Order, which Poser DOES use for normals information is determined at the time the mesh is created, and THAT is what is being reversed when people refer "reversed normals" in terms of Poser.

Oddly enough, when you export from Poser, polygon-based Normals are restored to the mesh. But these may be DIFFERENT from the normals present in the original mesh which was imported into Poser, because when Poser exports it creates Normals based on the Winding Order - so they are in agreement even if the ones in the original mesh were contradictory. This is a good way to "fix" normals that are contradictory to winding order, but there is no way to alter the winding order itself in Poser.

Sorry for the long-winded explaination - some day I might get around to making nice graphics to illustrate it, but till then, I hope this makes sense. ;-)

P.S. I forgot... You CAN alter winding order in Poser with the Grouping Tool.

Thanks for the explanation, ron. I was actually familiar with most of the concepts, but not in their application to poser. And there were a couple of intersting rules there I hadn't heard before. So, could this be avoided depending on what app you're modelling in? Or are overlapping surfaces always going to give this effect? I use 3d max and haven't ever come across this problem. You didn't find anything weird with room creator in poser 5, did you? Certainly, no other beta-tester with P5 had any trouble. I'm interested in anything like this which may affect my own stuff. I don't like nasty surprises. mac

Mac, your Room Creator was just fine (great, in fact), had I seen anything amis you would definitely have heard from me ;-) Overlapping surfaces by themselves are not the problem. This phenomenon only happens when all THREE of these conditions are true: 1) 2 or more surfaces overlap in the same plane. 2) Winding Order (normals) are reversed on ONE of the surfaces realtive to the other. 3) Render backface option is ON. Changing any one of those circumstances will avoid the black surfaces (but not necessarily render as intended). Unfortunately in Poser5 SR3 the render option "Remove backfacing polygons" was disabled, so P5 currently ALWAYS renders backfaces. And P5 still has a bug with shading backfaces because it shades them inversly (what should be shaded lighter is shaded darker and vice-versa) so they don't look quite right. As far as modeling programs go 3D MAX is about as good as the others, but they all will sooner or later reverse the normals (and/or winding order) or create duplicate surfaces while performing some operations. That is why all programs provide the user with tools to manually correct these when they occur. It is really up to the user to monitor their work to insure that these problems dont make it into the final mesh. Here are a few things to watch carefully when you are modeling: 1) NEVER use "double-faced" polygons - these are usually 2 polygons back-to-back with the normals reversed on one of them - precisely the situation we want to avoid. 2) Watch out for Boolean operations which create concave surfaces (such as arched vaults or the holes in swiss cheese) - this often results in some reversed normals - not a problem if you catch it and correct it. If you need to do such Booleans just be aware that this might happen... just fix it when it does. 3) When you need to have both an "inside" and an "outside" material on the opposite sides of the same surface, don't just duplicate the surface and reverse normals to get the inside to render - create a SEPERATE surface for the inside and ROTATE it 180 degrees so that the winding order remains the same, but the face is pointing in the proper direction. It can still be in the same plane as the original surface without a problem. If you MUST use the reverse normals process for getting an inside surface, be sure to move the new surface very slightly OUT of the plane of the original. Even a small amount like 1/1000 inch is enough, and the gap will never show in a render. 4) Use UVMapper to periodically examine your work (both with backfaces ON and OFF) - it will make any potential problems much more apparent that your modeling program which may be masking them.