#Normal From Texture working better than actual Normal Map

1 messages · Page 1 of 1 (latest)

wind elbow
#

I am working on a 2.5D dungeon crawler and decided to build the first person environment using sprite renderers rotated in 3D space in front of the camera. This obviously breaks 2D lighting, so after proving out the unlit scene for low-end mobile, I jumped over to the 3D renderer and Point Lights for higher end devices.

For the most part this has worked well. I briefly tried using quads instead of sprite renderers, but I found no perceptible benefits, more issues with Z-sorting, and there'd be a big conversion process to undertake for that anyways.

I am using my own Lit shadergraph (first image) that fades objects out in the distance. That works well lit or unlit. But normal maps generated from Sprite Illuminator just don't work correctly. After much effort I discovered the "Normal from Texture Node" works as expected, but I cannot tell why. I've captured both paths for the Normal in the second image (using the fixed one here).

Basically, point lights are illuminating one face of the quad more than the other. They are not illuminating as a circle. This results in some really odd effects at a distance and up close. The second image is an exaggerated representation of this.

  1. The base textures are 320x320 as Sprite 2D into the editor. No atlases.
  2. The normal maps are 320x320 as Normal Map, 2D into the editor. No mip maps are used. No convert from greyscale (though that did change the distortion somewhat).
  3. No compression is used anywhere. No filtering.
  4. The shadergraph has its _NormalMap node configured as a Normal Map.

So the "fix" (image 3) was to use the Normal from Texture Node. Though this doesn't look as good due to the lack of smoothing... it doesn't distort, cutoff or otherwise smear the lighting. One thing that does jump out at me, is the normal is a darker blue in the generated preview. Works fine for 2D though? Anyone have ideas for what is going wrong here? Or what the performance hit of Normal from Texture is? Thanks!

image.png image.png image.png
gaunt sable
#

Hi, it looks like the issue is caused by the Type not being set to Normal, which results in incorrect unpacking normal. You can try switching it to Normal and see if that resolves the problem.

image.png
wind elbow
#

Oh interesting. There's soooo many places where it needs to be set...

#

I'll give that a try and let you know. Thanks for pointing it out.

oblique grove
#

You're getting the bad result because, without using the "Normal" texture type, Unity is just giving you the raw color data without any transformation

#

Normal vectors can have values in the range of -1 .. 1

#

So if you just use the colors (which are 0 .. 1), you wind up with all of the normals pointing diagonally

#

which explains the funny behavior

#

The space is also important. I can't really tell if those are tangent-space or object-space normals

#

I guess it doesn't matter for sprites, since they're just a flat quad anyway

#

"tangent space" stores the normals relative to the original direction the surface faces

#

"object space" is absolute

oblique grove
#

(and so, for a flat surface, there's no real difference)

turbid jacinth
oblique grove
turbid jacinth
#

I was thinking in the mesh data; for instance, if you bake object space stuff in blender, most exporters rotate the mesh to fit unity's axis. So you'll need some swizzling to make it work. Tangent space doesn't really care about that.

#

But yes, good point

oblique grove
#

ooh, yeah, that'd be a consideration