We've all downloaded a prop, only to find the normals are whack and it looks like crap in Poser.

I've got another one of those. Sure if you only do Diffuse, it's OK. But I was trying to upgrade the materials and those bad normals create serious problems for reflection.

(Look on inside of lid - strange polygons that are reversed are causing blackness with white edges.)

I know I could take this into a modeling tool and spend a few hours correcting it but I'm not interested. I did use the grouping tool and I manually reversed a dozen or so and confirmed that the lid started to show up better. But I'm really not into that kind of labor.

My attempt to re-import this prop in Poser with the option to make polygon normals consistent resulted in a worse mess, so that's out.

Is there a tool or script that can make sense of these and produce a consistent outcome without me thinking about individual polygons?

     Maybe try normals forward on the lid material?

you could try letting STOMP rebuild the normals---i use it often when normals gets screwy.    STOMP

     Maybe try normals forward on the lid material?

Sorry I forgot to mention that normals forward doesn't solve it because when the polygons are welded, the normal isn't just backward, it's insanely wrong. The surface of the wood here is all welded - having a random subset of them going the other way - normals forward just doesn't deal with that. Only the old-school diffuse and specular work that way. Reflections (raytracing) have to have correct normals - this is why Poser switched to paying attention to the normals quite a while ago. Refractions even more so, because the angle of light bending differs going into a material, vs. coming out of the material. Of course I'm not dealing with refractions here, but when I am, the crazy incorrect normals cause me to discard freebies almost 100%.

It wasn't this way in Poser 4. The Normals_Forward checkmarks were added as a somewhat compatible mode, but when the phong interpolation of normals goes to work across polygons, it just can't deal.

you could try letting STOMP rebuild the normals---i use it often when normals gets screwy.    STOMP

Thanks - I'll let you know how it goes with this.

Poser establishes normal information upon import, even if such information is not present in the wavefront object. You can delete all of the vn lines from an obj file in a text editor, import into Poser, and Poser will create a new set of vertex normals. If you have UVMapper pro or classic (free), import the model into UVMapper and export again with the normals box unchecked. Import this updated .obj into Poser and see what happens... worth a shot and the whole process will only take a few minutes.

Silo's Unify Normals could do it too...I'm sure other apps have a similar function. I know you want to avoid modeling apps but the right tool for the right job.

You can carefully craft a perfect vertex normal map for your 3D object with perfect smoothing and hard edges where it is needed in a modeling program. Poser will just rip it off and add it's own terrible normal map and destroy your model. That's just how Poser works - or so I'm told by Smith Micro support.

You're misunderstanding my problem. I'm not talking about vn values in the obj. I know poser doesn't use those.

Poser is using the winding order of the vertices. Counter clockwise, you're looking at the front. Clockwise you're looking at the back. This is the "right hand rule" where the curl of your fingers indicates winding order and the out-stretched thumb indicates the normal.

I'm looking for a tool which reverses the winding order on polygons that face the wrong way with respect to their immediate neighbors.

hmmm,  UVMapper also has reverse winding and swap y,z coordinates (among other more common functions) but not on a per poly basis (AFAIK). The only solution l would suggest is as Teyon said. Or throw together a surrogate plane of polys positioned to cover the problem area, judging by your image it has it's own material, etc.

...if you're using a masking technique to create the material on the inside of the lid I don't see why my last suggestion still wouldn't be a quick, viable fix. Make the area transparent and put a one sided square in its place, very slightly intersecting the sides? It would be an incredibly easy thing to do in a modeler, and only slightly more tedious within Poser. Would probably only be noticeable in very extreme close ups, and maybe not even then.

again I saw you don't want to use a modeller but its a 10 sec job in blender [prob take blender longer to load then to do the job]

more info if you want/need it

I wouldn't be at all surprised if YOU couldn't write a script to open blender~import obj~fix it and export it again without ever having to R/click anything ;-) 

I'm looking for a tool which reverses the winding order on polygons that face the wrong way with respect to their immediate neighbors.

(emphasis added)      That is exactly what Silo's modify - unify normals does - in one shot.

.

     My first Poser version was 6, and the initial reason I got Silo was to fix normals of P4 models.  Models made in the P4 era often had randomly oriented normals, but with the release of P5, those flaws suddenly became visible.

Maybe simply fit a one sided square into the lid, attach it to the prop, and then texture that, instead of messing with the UV's of each poly.

dph

You guys are suggesting workarounds for this prop. I'm not interested in this prop, per se, and workarounds specific to this lid. I'm asking about the hundreds of props I've wasted time with because they have inconsistent normals as defined by the winding order of the polygons. 

Note that the particular suggestion of just covering this lid with a new polygon will lose the modeling that is in the lid. It's engraved, and the corners are nicely rounded so they catch the light like a real object, not some CG idealist box with hard corners. The point of using this box was the modeling - it's superb. Replacing it with some crappy rectangle polygon would defeat the whole purpose.

Similarly, when I find a nice, but unusable car, I'm not going to start slapping flat rectangles on it as a workaround.

I tried Stomp and Blender - both changed the normals but did not produce a consistent surface after all.

In Blender, rendering with the Blender rendering engine, I see the same artifacts as Poser and OpenGL produce.

However, when I use Cycles renderer it looks fine. Obviously the interpretation of consistent normals was either not performed after all, or was not producing the explicit normals that Cycles was using. Maybe there are internal flaws, like three polygons sharing a single edge. Obviously the prop needs to be a proper manifold in order to have a sensible interpretation as a single surface.

Sorry to hear it bagginsbill.

The only solution I could see would be to rebuild the entire lid in a Modeler as a manifold/closed object with control loops to facilitate the hard edges and sufficient poly count to allow the modeled engraving (how I interprate your description). I'm familiar with manifold or closed volume modeling simply because that's how Wings3D does things, my preferred Modeler.

Obviously the above isn't remotely a realistic option, nor is purchasing a modeler for a single function that may or may not work in this instance (although downloading the trial of Silo and checking out Unify Normals is a thought).

I wonder what application the model was built in/intended for?

It's in Freestuff here by Papus3D.  His profile on ShareCG says he also works in MAX....

http://www.renderosity.com/mod/freestuff/?item_id=75223

He has another pistol in a box; perhaps the lid of that one is better, although it seems to lack the engraving...

www.renderosity.com/mod/freestuff/?item_id=75223

I must say, BB's shader's are a vast improvement... :D

Judging by the render It looks like it's the engraved part that's showing the artifacts, perhaps due to the way that part was modeled. I've noticed that various 3d font automation processes (e.g. from Carrara or Strata3d) produce results that require quite a bit of tidying up before they can be used in Poser.

If you have Max, there is a script to correct mesh crazyness.

http://www.scriptspot.com/3ds-max/scripts/mesh-fixing-tools

http://sourceforge.net/p/meshlab/discussion/499533/thread/b35f1da5/

meshlab might help? 

You're misunderstanding my problem. I'm not talking about vn values in the obj. I know poser doesn't use those.

Poser is using the winding order of the vertices. Counter clockwise, you're looking at the front. Clockwise you're looking at the back. This is the "right hand rule" where the curl of your fingers indicates winding order and the out-stretched thumb indicates the normal.

I'm looking for a tool which reverses the winding order on polygons that face the wrong way with respect to their immediate neighbors.

Good luck. :) If you find a solution, please post it. Unifying a winding order would be awesome, especially if it operates across groups. I'm sure you've loaded up a freebie many times and seen it hashed to death in the OpenGL preview window because some export borked up the winding orders and now it looks like it's been chewed on. If there's a script for meshlab for quads, that might work, but if your model is tris, try Meshlab and see what you can get out it. (And, if you find anything that will manipulate winding orders across an object with multiple groups, please, please, post it or, if you'd rather, shoot me a PM. I would be very interested!

Also on sourceforge, do a search for "python script 3D wavefront object" (or similar) and you should eventually get a link to a nice project that has a bunch of free python scripts for handing wavefront objects. There could be a solution in there. It's also possible that loading the object in a 3D program and then exporting it might magically "fix" the winding order problem. Different 3D programs handle winding orders in their exports... differently. Some don't touch 'em, some seem to try to fix them if borked, some just say the heck with it and roll a die... The latter can be especially true across groups for some 3D programs. The old fixhexmt.py script would convert winding orders based on references from an original object, but that won't help you unless you had a pristine original of the object in question. It also doesn't work across groups. However, it demonstrates that Hexagon had this idiosyncracy of screwing up winding orders across groups. (AND IT STILL DOES! :) )

Are the problem areas confined to particular groups or are they scattered? It may sound nuts, but if you could regroup the object to one group in a 3D app, export, then load the object up in good ol' UVMapper and reapply only the old groups from the original object (For speed sake), nothing else (no materials or only one new material), to the object, you may get something you can work with. After that, it's likely going to be manual material assignment or taking the object back into a 3D program and reassigning materials.

PS, to my above post... (Gee, thanks Rendo..)

BB,

I am on the road, at the moment. But I will look around for solutions to your problem. I can't guarantee anything because a bad model is just a bad model and we're all out of pixie-dust. BUT, the issue is so commonplace in the "download uber awesome freebie here" markets that there's bound to be a solution, somewhere. My bet is that there would be either scripts or plugins available for popular, industry, 3D programs or stand-alones freebies/scripts that might be able to provide a workable solution for this model and others in the future. It's just a bet, though. :)

I've seen this prop before, just never downloaded it. Do you have a link so I can take a look at it?

thanks to Wanda for link ;-) I've just had a look in blender ~ the normals look ok but theres LOTS of tris and some really long thin ones on lid, I think there the main problem when rendering. To fix it properly would be quite a job, quick fix might be to remove the "fancy" bit and repair lid then bake out a displacement map for fancy or just use the fancy as an overlay but maybe get z fighting that way ~don't think you'll get a click click solution to this model

dunno why it posted pic twice ;-(

PS, to my above post... (Gee, thanks Rendo..)...

I've seen this prop before, just never downloaded it. Do you have a link so I can take a look at it?

At least I know I'm not the only one it happens to.  ;) It's here...

http://www.renderosity.com/mod/freestuff/?item_id=75223

Can't help with the normals, but love some of the finshes in that render, really nice!

I haven't bothered to look at the model, so thanks to hedheld for doing so.

I had a nagging feeling that maybe the normals weren't the issue when bb mentioned the fancy engraving (by the render this seems to be the problem area).

I'll wager that the engraving was created via a 3d font automation process within the relative software of creation. My experience with lettering created this way has invariably produced results that have a couple of serious problems when used in poser; Usually the lettering is composed of attenuated triangular polys (as hedheld confirms) which often results in black artifacts in render. Additionally, the mesh produced is not properly set up to deal with Poser's smoothing algorithm which requires either edge loop derived bevels or the splitting of vertices, unwelding, to create hard edges.

Using control edge loop derived bevels produces bevels that smooth properly and capture specular highlights that are aesthetically pleasing. The degree of the bevel in relation to smoothing is modulated by proximity of the loop to the turning edge, i.e the closer the loop, the harder the edge produced. I'm not concerned with smoothing groups in my comments simply because there isn't any definitive information that I'm aware of regarding the use of this in Poser (apparently they can be set up in UVMapper to work in poser. Haven't tried this). Establishing hard edges in Wings3D does not translate upon export of the object regardless of what some people have claimed, the vertex weighting is not stated within the object file (this behavior may be different depending on version of which I'm not aware).

So, even if the normals were to be successfully repaired you will be dealing with the problems mentioned above.

b

not sure he used any font proggy  (know what you mean about them) theres some beautiful details in the "fancy" bit , tried baking a displacement map but it wasn't anyway as nice as the modelling (thumbs up) , didn't try any nice mats just enough to show details, cant think of any way to make it all quads without a lot of work

I figured it was more than normals. Although I was able, manually, to get it 90% usable by flipping some individual polygons. I have no idea why that should help, but it did. I made the (incorrect) assumption that it would be mo-bettah if more were flipped. Didn't turn out that way.

Thanks for the compliments on the mats. Note: Aside from the velvet, all the rest are bbglossy - i.e. I have shown how to do this like 50 times in numerous threads.

Perhaps OT but since you mention BBGlossy, which I have in my BagginsBill material subfolder, does this material require a surrounding environment for reflection purposes? Haven't used the .mt5 yet but will be using for a render shortly...

Figured I'd just ask before experimenting.

I always use an environment, but you could add to the shader a SphereMap and Image to stand in for reflections. However, the blurry reflections (as seen in the metal) will not show up that way.

I'd be happy to play along and provide specifics for messing with this prop.

Note that I'm sorry to say I can't attach actual shaders anymore - the management here doesn't think that's important.

I used this map for my environment.

http://www.mrbluesummers.com/4698/downloads/free-hdri-map-bright-roof-multi

Thanks for the info and link once again bagginsbill.

There was a discussion about trying to script this sort of normals correction, a few years back in the Python forum.  PhilC was trying to solve some problems with his WIP metaball script, IIRC.  I don't recall whether anyone posted any Python scripts to try to make object normals consistent, but there might be one.

Solving the problem with Python involves choosing a "seed" polygon which represents the desirable direction for normals to face, then walking the mesh and reversing the winding order of any polys which don't face the same way as their neighbors.  Complications include the fact that the seed poly could be backwards facing (with PPy offering no way for the user to manually specify the starting point for the process) and the processing of complex meshes made up of multiple separate geometries with no polygons shared between them.  I don't think any final, satisfactory solution for the matter was found in the thread at the time....

Anyway, to stop babbling, there may be a semi-functional normals correction script attached to one of the Python forum threads.

I took a look at the mesh with what I had. (Thanks for the link, WandW!)

I didn't see any obvious normal issues or winding order problems. I can't check the winding order outside of Poser with what I have with me atm. Winding order problems should be immediately evident in Poser's Preview window, since it uses OpenGL to render and OpenGL ONLY uses winding order to render normals. (I guess they do something tricky with the camera to switch backfacing poly material to "visible" in the Preview pane from the Materials Room.) I didn't see Poser's OpenGL Preview window balking at anything significant in the model and it should have if winding orders were reversed/mangled in spots. ("Should" have.)

However, the faces that should be coplaner are not coplaner. That means that the big flat area made up of large, long, tris contains tris that are not "flat", relative to each other and they do not share the same planar space on the Z axis. Meaning... "bent" faces on the group of tris. Simply put - The tris next to each other do not create a "flat" surface, even if they are not nonplanar, themselves, and are intended to create a flat surface as a group.

Why is this? It's likely that the logo was produced by converting a graphic to something like an Illustrator file, then either using that in a Boolean or just using it directly, then simply connecting the bounding edges of that construct to the sides of the box, making an interior surface with an embossed logo. But, the original 3D logo, itself, had the outer set of edges nonplanar relative to themselves on the z axis, so a consistent, coplanar, flat, extruded surface could not be created. (A guess only.) It's not bad at all, considering how finicky that sort of thing can be, depending upon the quality of the original image used, but the faces that are supposed to represent a flat (coplanar) surface end up not producing a flat surface. (If this was in quads, I'd love the model. But, it's not. :(  Still, it ain't bad at all for a freebie. I like the choice for the model. Very cool.) When extruding multiple edges, if those edges are not coplanar (Sharing the same location on the plane that you are extruding to) this is what happens.

So, the result is that the flat surface is bumpy (irregular) in spots. These inconsistencies are magnified between two faces the further one travels away from an edge, since these are tris and there's only one other point to play with. I could not really get a good look at the artifacts that the materials created in the original image. However, I would guess that this is a factor of two things: Faces that are not coplanar with their neighbors, when they should be, and the model being made up of tris, which plays heck with Poser.

How to fix: Make the tris that make up the flat surface of the interior actually "flat" by making them coplanar to one another where they should be. (The lid is not modeled at 90 deg, so rotation of the lid or resetting a tool's axis values relative to the lid will be necessary to easily adjust non-coplaner facets.) Do the same for the tris making up the deepest inset parts of the lid. Flatten (reduce the z-axis differences between faces in those groups to zero) and then move each one of those groups until you get a nice depth without mangling the bordering faces too horribly. Tidy up the bordering faces as necessary. Remap the object so that you can use a separate material for the deepest part of the "floor" of the inset logo, the "walls" of the inset logo and the flat portion of the inside of the lid "border" ing the logo. (Gives you something more to work with to really get a good contrast and "might" help Poser/Materials find some edges, there.)

PS - Disclaimer: This is a just a handwavy opinion from a few minutes of SWAG'ing the model. I could easily be wrong about the primary causes.