View Demo
25 | 26 |27 | I created this model to test how normal, tangent, and bi-tangent vectors behave in various 28 | applications and engines. The tiles on the left are hemisphere-on-plane shaped geometry, 29 | and the tiles to the right of those are individual quads, which will contain normal-mapped 30 | versions of the same geometry (as calculated by Substance Painter 2.4). 31 | I've spun the UV maps around in 5 different directions, 32 | to cause the tangent vectors to go all different ways. 33 |
34 | 35 |
36 | 
37 | 
38 |
41 | I don't expect the normal-mapped versions to work off-axis, as the hemisphere 42 | geometry is quite large: 43 |
44 | 45 |
46 | 
47 |
50 | But, when viewed directly face-on (orthographic or nearly so), I expect the normal map 51 | to closely replicate the geometry, regardless of the orientation of the 52 | normal-mapped quad in UV (texture coordinate) space. 53 |
54 | 55 |
56 | 
57 | Loading the normal map into Blender 2.77's texture image panel appears straightforward, there's even
58 | a mapping called "Norm" that sounds correct. But the default behavior here is to take the luminance
59 | of the incoming image and treat it as a height map, which is not what we want at all. So while this
60 | is a needed step, it is not enough on its own.
61 |
64 | 
65 | I didn't build this model just to test Blender, of course. There are several combinations of engines
66 | and shaders that appear, at least to my eye, to treat normal maps somewhat differently, or produce
67 | different results from them. The "twisting around" of the light source shown here is exactly what
68 | I'm trying to avoid (although there are additional problems in this image due to incorrect import
69 | settings in Blender).
70 |
73 | 
74 | Next let's fix the import settings. Here I've told Blender to treat the incoming image as non-color,
75 | and interpret it as a tangent-space normal map, which it is.
76 |
79 | 
80 | Well, that's improved, but I still see the light source moving around when the UV map orientation
81 | changes, so it's no good. It turns out that Substance Painter 2.4 has texture export options for two different
82 | kinds of normal maps, "OpenGL" and "DirectX" (their terms) in the texture export configuration
83 | panel. The "PBR MetalRough" preset in this version defaults to the "DirectX" version, which has
84 | the effect of flipping the V axis vectors (the green channel intensity) compared to "OpenGL" version.
85 |
86 | This is not what Blender or Three.JS expects, and so produces the bad result shown here.
87 |
90 | 
91 | At last, the correct result was achieved by using Substance Painter's "OpenGL" export option
92 | paired with the Blender settings shown above. The same map also works in Three.js:
93 | View Demo.
94 |
95 | Notice that all of the tiles now appear very consistent when viewed directly face-on, with
96 | the light source coming from the same direction, regardless of the twisting happening in the
97 | texture coordinate space.
98 |
101 | I hope this test object proves useful, particularly to the development of glTF 2.0 and its own 102 | normal map implementations. The next step from here will be to construct a glTF 2.0 model that 103 | uses this map, and test its behavior in a variety of glTF loaders and engines. 104 |
105 |