ugly normals
polycounter lvl 18
having problems with low-quality normals:
on the left, result after normalmapping. on the right,
the object to be mapped. preceding pics shows various
pictures of the low-poly mesh.
any normalmap-savvy people got some tips on how to improve the quality of these normals?
i'm using 3ds max 8 normalmapper.
on the left, result after normalmapping. on the right,
the object to be mapped. preceding pics shows various
pictures of the low-poly mesh.
any normalmap-savvy people got some tips on how to improve the quality of these normals?
i'm using 3ds max 8 normalmapper.
Replies
That should fix a big portion of it for ya.
i fixed up the wires like per 128 showed, removing the red wires, and adding the green.
one with no smoothing, where the normals seems fairly accurate, despite the hideous edges around each poly
and one where i made everything into smoothing group1, which ive done before, but didn't do any good.
edges looks decent, although they got a "jaggy" pattern.
and the overledges are still messy.
hmmh. i'll experiment some more. if you guys got any tutorial links on advanced normal mapping in max, i'd be interested. i'll try and read that section in the manual about the various features in the normalmapper, to see if any of them will make my normals magically more beautiful.
very annoying having to fix up the edges, after a normalmap.
Try increasing the cage distance from the base mesh so there's no clipping at all. Also, try NOT using the cage on a burn. Then last but not least, try using another app, such as Xnormal, to generate the normal map.
You can turn the use of the cage off in RTT's projection menu:
you can see theres a big ugly blotch there on the lower part, in the middle of some UV's.
i've even turned around the UV normals red and green space a few times, just to see if theres some errors there.
i'll try the external UV program option, see if i get some better results.
The second image looks like a bad cage, the rays aren't catching the highpoly so it's baking black onto the lowpoly.
I'd do what Per recommended and just make sure your UVs are layed out in one chunk, and if they're mirrored, move the mirrored side off the 0-1 UV range.
bout halfway down:
http://www.poopinmymouth.com/tutorial/normal_workflow_2.htm
I've never had a mesh get "corrupt" in max.
And from the looks of it per, the cage was still wrong, on yours :P
certainly if a crane you're working with on a construction site suddenly tips over, you'll have some serious insurance quarrels going on. hows things for working 2 months on a model, only to have it lost in a fatal crash by 3ds max,
or worse, corrupted beyond salvage?
they'll probably start ranting about backups, and such, but seriously, there should be laws against this kind of design malfunctionality,
so that the end users can get a reliable tool, instead of one that breaks when you try to use it.
I do that all the time, and have never seen "mesh corruption" issues such as you speak of.
dejawolf: What, do you turn off Autoback too? You don't save incrementally? Those are really, really bad workflow practices, regardless if you're working with the most stable program in the world or not. It's just common sense. What if your hard drive has a hardware failure? Do you have any external backups?
Problems will be solved when you stop making smart-ass comments like:
[ QUOTE ]
your meshes will begin to corrupt as you start getting into the more hardcore tools.
[/ QUOTE ]
And just stay objective, please. I want to fix people's application problems just as much as you do, but I don't want to do it by implying that whoever isn't getting application issues aren't "pushing the limits" or being "hardcore". That's just unnecessary.
Is it an issue with not trangulating before rendering the nmap?
Glad your issue was resolved, dejawolf.
As far as mesh corruption issues go, do you use any custom scripts (written by people other than yourself) while modelling? If so, what are they called?
Same question to you, Per - I wanna give them a try and see if they either improve my own workflow, or give me similar mesh problems, or both
Max is a tool, it should always work regardless how we use it, it shouldnt corrupt data, regardless of input. It is one of its strength that it allows workflow enhancers via maxscript or plugin coding (the latter of course are perfect to fuck up everything, but maxscript shouldnt)
A screwdriver should work for left- and right-handed people, but not start to melt the screw. Given the price tag, the long history of the software, one could expect and demand a more solid core. Likely we will (with luck) wait a few service packs, and things will smoothen a bit, but if we have bad luck, things will stay until version 10 comes, which we pay for again and again... that is what frustrates me, I dont need new mental-ray or other features, I need a solid core functionality.
well we shouldnt accuse each other of breaking it because we dont use it "the right way", as there is none.
Anyway let's storm autodesk's headquaters
We shouldn't accuse each other of breaking it because we don't use it "the right way", as there is none.
[/ QUOTE ]
Absolutely
http://www.dejawolf.com/corrupto/footsoldier_per.rar
links to downloads of corrupted models.
if you want, you can also try mirroring the whole arms.
thats probably going to show some of the corruption.
btw, the should elements isn't the only ones with normals that aint no good looking. i've had the problem all the way down the mesh.
i don't use any specific modeling plugins on my side.
just standard max modeling tools.
although i use quite a few small self-made maxscripts for UVing.
The only thing I'm not sure about was the highpoly segment of the shoulder bit, it seemed to be an XRef from a different file not included in footsoldier.zip , so I made a new one quickly by cloning the lowpoly section and adding some bevels.
Here's a screenshot of the result, it just uses the original UVs, I didn't touch those:
Here's a run-down of what I noticed and what I did, maybe try these steps on your machine and see if it works.
First of all, I noticed the low poly section was a mess when it came to XForms - it thought it's own scale was -107.24 or something on every axis, which is usually a very bad sign.
So, I converted the object to Editable Poly (why was it EMesh anyway?
This action resulted in flipping all the normals (again, a sign that the object was fairly screwed in terms of scaling etc.), so I just selected all faces and flipped them back to face the original direction.
Then I changed the renderer to Scanline, mental ray doesn't do a great job of rendering normals...
I also un-checked "use advanced lighting" since this can sometimes screw with normal baking.
I also applied one of your basic materials to all the objects, just in case (i used "ap-cuer", since it seemed fairly basic).
Then I fired up Render To Texture, picked the highpoly source objects, hit "Reset" on the cage and used manual value to push it out until it was covering everything, quick and dirty.
Turned on Global Supersampling in the Options -> Render Setup cos that always makes for a better normal render.
Added a Normals Map output, just left everything else pretty much default.
Baked that and got the above result - no dodgy pixellated lines, no black spots.
The only visible normal problems are due to split UV seams, you could probably come up with a better UV layout to minimise the visibility of those.
I'd probably put a split down the central symmetry, and uv-map each side as a whole chunk, and stack those UVs on top of each other (but move one set to the side by 1 UV unit to avoid errors).
So yeah, if you wanna try those steps and see if it works, give it a shot and let me know what happens.
I reckon the problems were mainly in the XForms, but the renderer and odd materials probably weren't helping.
My solution was done without exporting/importing any meshes, or loading new scenes. The only unknown element in this whole solution is the XRef object that I couldn't load.
but heres a question. how did the Xform become -107.4 in the first place?
if i can't avoid doing whatever i do wrong in the future, and only fix the symptoms, i'm not very far.
all i've done is modeled normally.
i convert frequently from editable poly, to editable mesh.
i find adding edges and turning edges is a lot simpler, and less buggy than in editable poly.
another thing, i always work in perspective view, and when cutting with the cut tool, i find the cutting accuracy decrease, to a point where the cut radius is all-encompassing.
cutting works fine in the orthos.
so is there a chance, 3ds max modify the Xforms when i cut in perspective view?
and why is such a useful utility hidden away?
the manual reference doesnt really tell you that its capable of fixing normal mapping problems either.
is there any other uses for Xforms?
I think there are no warnings about it when rendering to texture, because sometimes people actually want their objects to have odd scale sizes (like when you instance mirror an object, it'll have negative scale on the axes you mirrored it across), so the program wouldn't be able to tell when the XForms were meant to be weird, or if they were just screwed up during the modelling process.
If your scale transforms are at -107 on every axis, that means at some point along the way, you've scaled the object up, then mirrored it, or done some sort of transform operation on it. I'm pretty sure modifiers don't affect the XForm, only actual move/rotate/scale/mirror operations.
Actually, if you look in the Heirarchy panel, you'll see a "Scale" button in the Reset area, if you hit this, it should reset the scale to 100% on all axes, quicker and easier than doing a Reset XForm and collapsing the stack, although not quite as comprehensive. It might fix certain issues, though, and is definitely worth doing if you don't mind losing your scale values (as they can sometimes be useful).
One question - why do you keep switching between EMesh and EPoly? EPoly's Turn Edge tool is identical to EMesh's, and I don't understand how edge creation can be easier in EMesh than EPoly - what exactly do you mean by this?
for the Emesh, and Epoly:
i couldn't find the turn edge tool in Epoly, so i just went with the turn edge tool in Emesh. theres also no way AFAIK, to select all edges, set auto edge to 5. which is quite handy when doing vehicle UVs, you want to select as few UV's as possible.
Emesh is also good when you do a cut operation from a vertex to an edge, and it turns out Epoly created you an extra vertex in exactly the same position of the old one.
turn to Emesh, select all, weld all, turn to Epoly.
Emesh got a bit more freedom with welding vertices to vertices. and collapsing vertices is pretty good for LOD creation, when its better to have a lowpoly mesh, than a pretty mesh. its mostly a hangover from my all-Emesh days,
when you couldn't shift-drag new polygons in Emesh.
i sometimes like to select triangles too.
anyways, i'll take all these things into consideration, and create a small checklist, for future reference for anyone who's unfortunate enough to have to deal with the confusing world of 3ds max normal mapping.
hope this thread is useful for anyone else who is having trouble with normals.
i've acheieved about 12 million corupted meshes since starting work in the industry, and i know a lotta coworkers here have had a lot of corrupted mesh issues,, a lot of times it comes from custom tools, other times it comes from being in max over 8 hours a day forever
Its like, when a mesh no long has any sence of decency, and starts selling rock just to pay for it's gambling addictions. Eventually selling its children on the black market just because it can't afford to pay the rental payments on its patio furnature.
[/ QUOTE ]
oh.. the story of my life!
the only way to fix these errors, was to.. export the object, and then import it.
for those who are willing, unhide the layer nicknack,
reset Xform of the leg parts, and try rendering normals.
i kept getting these faint wire patterns on the leg,
after several Xform resettings, and various setting changes, i just exported and imported. worked fine then.
oh and mop, the edit mesh has a much better turn edge, you can turn any edge..i think you can only turn invisible edges in editable poly, but i have scripts for turning any edge with edible poly, like edit mesh. polyboost also has a tool for this.
I should probably look into getting polyboost, it looks insanely useful.
sometimes reseting x forms dosent work for me.. the end all fix i have found is to create a cube at 0 0 0 with the keyboard option.. dosent matter the size.. then turn that into editable poly and attach my object.. then in element mode delete the cube.. this resets any crap that might be in the in the channels.. its not always transform information that fucks it up..
[/ QUOTE ]
Yuppers. I've done this before, with objects that crash max. Works like a charm.
http://www.codeproject.com/cs/media/NormalMapCompressor.asp
It claims to compress Normalmaps without visual artifacts, let me know if it works well...
Here's a screenshot, for the textually imparied: