Symmetry issue involving normal maps
polycounter lvl 9
[semi-resolved]
Long time no post. Anyway-
I'm having a very annoying issue in UDK. Wherever I have symmetry, my normals get EFF'd up.
My UV's are separated and overlayed exactly.
It looks like its actually reading the green/z (?) channel as it's inverse on one side.
If someone could explain how to fix this, I'd be very appreciative.
example:
Long time no post. Anyway-
I'm having a very annoying issue in UDK. Wherever I have symmetry, my normals get EFF'd up.
My UV's are separated and overlayed exactly.
It looks like its actually reading the green/z (?) channel as it's inverse on one side.
If someone could explain how to fix this, I'd be very appreciative.
example:
Replies
I tried that, but as expected, it didn't have any effect.
I'm pretty sure this doesn't have anything to do with the compression, It has to do with the symmetry and possibly a channel of the normal that is getting flipped due to symmetry.
Thanks for tryin though
please excuse my shitty mouse outlines:
here's an image of the uvs and where that particular image (above) is symmed
Keep in mind though, that this happens wherever I symmetry anything with normals....so either its a global issue, or there's something I don't know about how to symmetry for udk.
Are you baking with both halves in the 0-1 space? If so offset one of the pieces one tile to the right, left, top or bottom so it falls outside the 0-1 rendering space but still lands on the exact spot it should one tile over.
It could be that you need to weld or unweld your UV seams before baking.
Vig, long time.
No, the Symmed area is outside of the 0-1 space, Placed on the same uv coordinates as the piece that IS in the 0-1, but outside, -1 on U. However the seam lines up (in tilespace).
If you look at the first image posted, you can see that the problem isn't with the alignment, The problem is that for some reason the flipped UVs recieve lighting inverted lighting information on one channel.
This is bugging the hell out of me.
As you can see, it looks fine when rendered in MAX
http://www.polycount.com/forum/showthread.php?t=51088
Unfortunately, I believe I have a different issue. As you can see in the first post, its not a matter of a seam as much as a channel/lighting issue on one side of the symmetry.
I keep reading vague whispers of an inverse-lighting-across-mirrored-geometry problem....maybe that's it??? Any ideas???
I had the same problem in UDK, and like I said, I fixed it by changing the normal map compression. Have you tried each setting of compression? Double check thats not the problem.
The model is being exported as a whole. No geometric mirroring is being handled in UDK.
I spoke with Carlos at HighMoon, and he theorizes that UDK have an issue with horizontal symmetry, suggesting that I try rotating my uvs 90 degrees so that the symmetry is vertical (symmed across x instead of y). I'll try this when I get out of work and post the results.
I'm surprised that this hasn't been addressed anywhere (that i've seen). This has happened every time i try cross-planar symmetry. (same thing happened with my art-deco scene, jake.)
Have you tried cloning a side and mirroring it instead?
I have quite a few models in UDK right now that I've cloned, mirrored, and welded down the center and I can't say that I've had that issue with the normals
If you can't find a better solution, a cheap workaround would be to go back into Max, select the polygons on the side that is getting distorted, flip their normal direction, and re-export the mesh. It's not an explanation as to what is causing the problem but it should fix it.
I'll test this asap.
In the meantime, can you explain why this is? You're the second person to suggest that. I'd love to understand the route of the problem.
To be honest I didn't have a clue why but I did have a forum post bookmarked from the epic forums where someone said, "this is due the way the shadow maps (not the lightmaps) are encoded with the normal maps. Because the shadow maps are used for static lighting, these artifacts will be merely visible or won't be visible at all when using the realtime lighting. You won't see it in maya or other 3d application either becuase they don't use shadow maps - at least not in the same way like UE does."
http://forums.epicgames.com/showthread.php?t=665046
Not sure if this is the correct reason or not.
http://udn.epicgames.com/Three/LightMapUnwrapping.html
A recent thread about it.
http://www.polycount.com/forum/showthread.php?t=75993
Basically make sure to mirror your UVs so the seam is vertical up/down not horizontal left/right. But keep in mind that at best it will only reduce the problem and not completely eliminate it.
Lightmap UVs and baking lights will also play a huge role in how bad the seams are.
When looking at the mesh in the mesh editor window, a combination of the 128 color blend fix and the tc_uncompressednormalmap helped. In fact, it solved the problem *in the mesh editor*.
Unfortunately, the second i ran a build, the problem was as bad an apparent as ever.
I also tried several different things with my lightmap. Including increasing its resolution all the way to 512.
I also tried turning the UV's so that the mirroring was horizontal instead of vertical to no avail.
I'm *SO* depressed that I can't figure this out. This seems like a really apparent issue. I'm surprised it hasn't been addressed in any of the many recent UDK builds.
I've spent too long and gotten too stressed about this. I think I'm going to give up and just move on for now. If no one (including me) can figure out a way around this within the next few days, I'll probably just give in and spend the texture space to not use symmetry on anything planar. ....seems sooo wasteful
1. Rotate those sections 90° in the primary UV set, don't forget to re-bake the normal map or use these Normal Map Actions for Photoshop by Will "sinistergfx" Fuller for quick normal map 90° rotating.
2. Redo your lightmap UVs (see this tutorial written for UT3, everything is still valid except you don't need padding around the outer edge of 0-1 UV space anymore)
Currently they are packed way too close together, you need at least 4 lightmap pixels in between each UV shell otherwise light from the different shells will bleed onto each other.
Merge those two shells together so there isn't a seam. Any seams in the lightmap UVs will result in a visual seam after building lighting.
3. Then change the Indirect Normal Influence Boost setting from 0.3 to 0.
View -> World Properties -> Lightmass -> Lightmass Settings -> Indirect Normal Influence Boost
4. Finally rebuild your lighting.
Following those steps should result in a less visible seam.
I hope that helps.
I was about to give up, and yet,
here you are....
...rocking like a hurricane....
I'll give this a shot once i've mopped up the tears and pulled hair from my keyboard.
Thanks in advance.
But remember before you invest more blood sweat and tears, this won't eliminate the seam 100%, it'll only make it less visible.
If you really need it 100% seamless then you'd best not mirror that section. At least for this model it's not that huge a piece so you won't lose that much texture res by making it unique.
On the other hand sometimes it's possible to get away with a seam. Once an object is fully textured and lit it becomes less visible. As long as you aren't planning to texture it in a pristine shiny state.
Definitely at least rotate those UVs though, even if you decide to live with the seam. Mirroring in the other direction should yield a better result.
Well best of luck with this thing. I personally think this is one of the most frustrating aspects of making art assets for Unreal.
Currently redoing my lightmaps. Looks like that link you left is broken. Could you relink me?
Also, what resolution lightmap do you recommend for an asset that is around 128x128x32 Unreal Units?
much improved. Looks like the lightmap is getting pretty cruddy looking, but I'm sure some diffuse and spec will help that a lot.
lighting should help too, I'm sure.
That link works for me strange... well here it is in long form:
[noparse]http://stephenjameson.com/tutorials/lightmap-uvs-tutorial/[/noparse]
http://stephenjameson.com/tutorials/lightmap-uvs-tutorial/
Hopefully that works for you.
About your lightmap UVs. Depending on the resolution you are setting for you lightmap, they're still too close together in some parts. I think for that size of an object not more than 64x64 pixels, but it kind of depends also on how big your scene will be. The more objects the more lightmaps get made which means more memory needed to store the lightmaps.
Also you don't need that padding around the outer edge of 0-1 UV space for lighmap UVs. You only need the padding between the different shells.
For a portfolio piece I think it's totally acceptable to crank up the quality so it just "looks good", just don't go too far overboard giving everything a 2048 or 4096! lightmap even a 1024 is kind of nuts unless it's for a huge object. I've found UDK/Lightmass to be pretty good at preserving shadow details even at lower resolutions than you might think.
It's perfectly fine to stretch and twist lightmap UV shells into nice rectangles and squares so that they can get packed closer together without wasting precious texture space. When you're using a 32x32 or 64x64 every pixel counts...
Try to merge as many lightmap shells as you can so you don't need as much space devoted to padding. Though you need to watch out, taking this too far can result in an undefined blobby mess. But for organic objects this is the ideal approach.
Sometimes you can just planar unwrap a side of an object and it'll work out great as long as nothing protrudes too far in or out. If that happens just break the offending UVs off and make them a separate shell.
I wish UDK supported non-square lightmap resolutions, but oh well...
Strange thing is... mine was working just fine for about 3 months, when all of a sudden, these shading errors start showing up and I can't figure out how to get back to how it was before... Here's my screenie.
no light maps at all yet... and the lighting is unbaked...
howeveR!! i found a solution - I found what went wrong... in my normal map texture, the "unpack min" settings had gotten set to 0 0 0 instead of -1 -1 -1 somehow...
totally screwed me over for like 3 hours tonight - and now i feel dumb for posting this. Anyway, if this happens to anyone else, after you've exhausted all the other threads on this issue, check your unpack min and unpack max numbers in the texture viewer inside the content browser.
cheers - adm