I've known this for a good while. But people keep saying to use certian Nifskope spells on their meshes. I have mentioned this on occation. But I suspect modellers are still recomending things that will make their meshes look bad. No one listens when I say stuff like this, so I decided to make pictures, So listen to them instead.

This really pertains to tangent space normal maps that are rendered from high poly geometry. The normal maps rendered this way, use the meshes face normals to calculate what the output is like. So changing the geometry, by adding or removing any verts etc, or changing the face normals, or mesh smoothing, WILL invalidate your normal maps. And cause bad lighting. I am going to highlight the most common area that is nif/ nifskope specific, where this normal map "invalidation" happens.
So this is for meshes with baked normals, But TBH, there is no reason this can't apply to all your meshes.

Basically- NEVER run face normals in nifskope. No matter what you do after, you will never be able to get the normals correct again. I have tried several dozen tests this morning. And I know now, I will have to export several of my assets all over again. :banghead:

Ok. So you have a mesh, and a nice normal map. And looks great rendered, the shading is correct and you are semi happy with the results and want to start testing your maps in game.
http://i25.photobucket.com/albums/c85/lego-botz/Fallout3/remotetest1.jpg

Then you export and start tidying up your mesh. You have read in several tutorials about some nifkope spells, you start running a few, and you are like hey, yeah that looks better...
BUT, this is what is happening in game-
http://i25.photobucket.com/albums/c85/lego-botz/other/NormalTestexample.jpg

The first example: the only real safe and essential spell to run in nifskope. Update Tangent space. Fixes the sometimes black faces from the export.

The second example- face normals.... dear oh dear. I have Updated Tspace here as well. But it doesn't help fix the apparent UV split seams, and the fact the normals are borked.

The 3rd example- Face normals, smooth normals, at the same smoothing that my mesh was at when I baked the normals, This heals the UV seams , but the normals are still borked. I also Updated Tspace.

No matter what combination I tried, or how many times I tried all my nifskope jiggery pokery, nothing can revert my normals back.

IMPORTANT!
This probelm is confounded by the fact nifskope does NOT display normal maps correctly. So after you have run your face normals andsmooth normals the mesh actually looks like it has more correct shading in the nifskope viewport. So while in nifskope you think you are fixing your shading, you are in fact totally borking it when it comes to shading in game! here see what I mean:
http://i25.photobucket.com/albums/c85/lego-botz/other/NormalTestexampleNifskp.jpg

By just looking at the pictures you'd think the second one has more correct shading. But In fact the oposite is true.

In conclusion- My advise is set up your face smoothing and normals in your 3d editor. And do not mess with them in nifskope. Just trust that they exported correctly. In this case, less is more. :grad:

useful datas, though it should be on geck wiki somewhere or something since it's not exactly discussion material for a slow forum...

Thanks Ghogiel!

For Maxers, the problem is compounded by the fact that the Binormal and Tangent data sets are still borked along UVW seams, even if you put in an Edit Normals modifier and unify all normals. And since there's no developer for the Max plugin, it isn't going to be fixed any time soon.

Interesting points Ghogiel, but there's some gaps here. I've never seen the Face\Smooth Normals spell in NifSkope do anything it's not supposed to. -This largely depends on the construction of the model.

Baking a normal map from a high poly, then changing the normals on the display model is a sure way to rendering issues. Also, I believe Max's Normals Modifier (or whatever it's actually called) uses a much different method than what NifSkope uses. When I was prepping heads for my F3 Eyelash mod, I needed to make a few edits to the heads in Maya; which calcs normals much differently than what's seen from Bethesda's exports from max. I had to use smooth edges, which is like 99% similar output compared to NifSkope's anologues. Editing the actual normals to preserve the look causes issues with the .obj export; so I have to rely on Face\Smooth normals for that process. (incidentally, ended up going an entirely different approach to the edits because of all this)

As for the UV mirroring, is your UV seam welded or not offset? I think you know that trick, but it bears mentioning. I've also found another solution to sharp seams like that; involves placing the seam on an edge whose neighbors are planar.

I'd like to toy with your example there, since I'm curious now. Mind posting the files for it?

if you are refering to the fact that you can't stack mirrored UVs, and get bad tangents no matter what, this is not max specific issue. no meshes can get away with that. Blender is affected as well.

tk
There are no stacked mirrored UVs in my example. Tangent space export from max is usualy correct. I get an error on a face now and again, its black. UTS in nifskope solves this issue. I'll upload the files tomarrow, I'm at a juggling convention today. I'll come back to this disucussion when I am literally not out the door

Nope, all UVW seams that go through max get screwed up in TanSpace. The normals can be fixed via the Edit Normals modifier, but not the Binormals and Tangents. Haven't tried stacked/mirrored UVWs in Max yet, so I don't know if Max has that problem.

I also found that brand-new geometry is REALLY borked TanSpace-wise on export. I also found that re-importing it fixes it... :confused: :shrug: Exporting and re-importing also fixes weird translation shifts caused by geometry recieving grafted skin modifier drastically different from any it had before (or if it's the first skin data it's had to begin with). NIFs are weird... :wacko:

I think NifSkope needs a Smooth Binormals or Smooth Tangents mesh function.

http://img.photobucket.com/albums/0903/throttlekitty/temp/CylinderSeamExample.jpg is a picture of what I was talking about with offsetting the UV seams. MadCat, this might help you with your binormal and tangent problem for some meshes.

The selected edges (marked in orange) were where my seam would have been; instead, I've inserted a loop just to the left of it. In this example, I've left the edges hard, but a real-world piece would have them soft. Since the new cut bisects the existing faces, the result is totally planar on any side of the cut. Any inconsistencies in binormals and tangents shouldn't be visible.

Sniffed out what's up with NifSkope and normal map rendering at least. It's swapping the binormals and tangents; the UTS spell stores them correctly however. I like using NifSkope for texturing pre-vis, since it's so fast. So I'll just use an Oblivion-version .nif for that until my models are ready to go into Fallout 3 for now; it renders properly for those version files.

nice one.

I noticed that as well. Didn't know what was going on though, but kept forgetting to mention that.
I was exporting ob versions for previewing textures, you can drag the textures directly onto the model in the viewport, which made things quicker. the F3 nifs, you have to keep manually changing them in the texture set. But as I started to transition over to using the Geck model viewer more for previewing......I noticed something was up. And was where this whole bit of researched started.

MadCat221. I'm still not sure about what you mean with max messing Uv seams up. All my models have exported correctly over 90% of the time with correct normals and TS. The only problem I have is the TS isn't always right. I get a black face on a couple meshes.
I almost always updateTS in nifskope. Without the niftools material working properly, and access to shader flags in max, nifskope is still in the pipeline. Which doesn't atter so much, as the time I spend hovering over my lcd just viewing texture updates in nifskope, I might as well hit update TS spell while I'm there.

I have done a few, import/re-export, and the exporter does work exporting TS on the couple examples I tried. I couldn't reproduce any errors. Nifs rendered nicely in max when imported, then also in the geck after export. TS and normals are what you'd expect, basically at the end the mesh is identical. Even the entire material, shaders, and texture set is intact. The file sizes are a touch lighter after exporting with niftools.

The offsetting on the rigged meshes, can and can't be avoided. if you match the pivots of the mesh recieving the skin, to the donor, hoepfully that shouldn't jump about now.
The other instance of this behaviour, is due to niftools always zeroing the translation of a skinned mesh on export. And also converting the mesh offset to pivot point, and zeroing X znd Y at import. so in a import and export, the whole translation of the mesh and the pivot will be zeroed, the translation info is gone. I tried unticking zero tranforms, collaspe, etc, and any combo of. result was that the pivot point, no matter where it was, was nulified at export and the translation would be a big 0.

The way to get the mesh back out correctly, is physically move the mesh to match the translation of it in nifskope- which will have been transfered to be its pivot point if was imported with the niftools plugin. Obviously make all this changes under the skin modifier.

The bethesdas exporter must work like civ4 plugin in this respect.