Normalmap Baking- Faces with the same normals produce different RGB values #38062

New Issue

Lino Thomas · 2014-01-04T13:45:44+01:00

Lino Thomas commented

2014-01-04 13:45:44 +01:00

System Information
Win7 64bit
i7 720
6gb ram
GF GTX470

Blender Version
Broken: 2.69.0 r60995

Normalmap Baking- Faces with the same normals produce different RGB values

Simple reprocase:
Use the standart cube, select the top face. Inset it. Extrude the top face and scale it down a bit. This should produce a elevation of the middle face. The surrounding first layer of 4 faces have the same normal as the now higher elevated middle face. (we never rotated anything)

Set up the baking environment:
Add a plane, move it above the cube above the elevated extruded face.
create a new material+texture for the plane.
select the cube and then the plane.
go to the baking panel, select "normalmap" and tick the "selected to active" box.
bake the normalmap image.
in the image viewer, click on the middle face to get the RGB values.
It should read RGB(0.498/0.498/1)
The lower ring of faces will show a value of (0.501/0.501/1)

Picture of the setup and values:
http://imgur.com/lfU9GTQ

**System Information** Win7 64bit i7 720 6gb ram GF GTX470 **Blender Version** Broken: 2.69.0 r60995 Normalmap Baking- Faces with the same normals produce different RGB values ___ Simple reprocase: Use the standart cube, select the top face. Inset it. Extrude the top face and scale it down a bit. This should produce a elevation of the middle face. The surrounding first layer of 4 faces have the same normal as the now higher elevated middle face. (we never rotated anything) Set up the baking environment: Add a plane, move it above the cube above the elevated extruded face. create a new material+texture for the plane. select the cube and then the plane. go to the baking panel, select "normalmap" and tick the "selected to active" box. bake the normalmap image. in the image viewer, click on the middle face to get the RGB values. It should read RGB(0.498/0.498/1) The lower ring of faces will show a value of (0.501/0.501/1) Picture of the setup and values: http://imgur.com/lfU9GTQ

Lino Thomas commented

2014-01-04 13:45:44 +01:00

Changed status to: 'Open'

Lino Thomas commented

2014-01-04 13:45:44 +01:00

Added subscriber: @LinoThomas

Lino Thomas commented

2014-01-04 13:53:55 +01:00

Blendfile:
nmbug2.blend

Blendfile: [nmbug2.blend](https://archive.blender.org/developer/F61648/nmbug2.blend)

Andy Davies commented

2014-01-04 15:19:50 +01:00

Added subscriber: @AndyDavies-3

Andy Davies commented

2014-01-04 15:19:50 +01:00

I can confirm that the values are indeed off by a little, though I get different values for different areas.
If you split the areas in the bake into quadrants the top and bottom give a value of 128, 128, 255/#8080ff where as the sides give a value of 128, 127, 255/#807fff. The centre of the bake gives a value of 127, 127, 255/#7f7fff.

Obviously this is not good news as all those values should read 128, 128, 255/#8080ff or .5, .5, 1.0, which of course is the correct value for zero surface change on normal maps (A normal pointing directly up).

This will certainly cause issues when using bakes from Blender in external engines, especially when mirroring.

I can confirm that the values are indeed off by a little, though I get different values for different areas. If you split the areas in the bake into quadrants the top and bottom give a value of 128, 128, 255/#8080ff where as the sides give a value of 128, 127, 255/#807fff. The centre of the bake gives a value of 127, 127, 255/#7f7fff. Obviously this is not good news as all those values should read 128, 128, 255/#8080ff or .5, .5, 1.0, which of course is the correct value for zero surface change on normal maps (A normal pointing directly up). This will certainly cause issues when using bakes from Blender in external engines, especially when mirroring. ![Normals_value_bug.png](https://archive.blender.org/developer/F61673/Normals_value_bug.png) ![Normals_value_bug_overlay.png](https://archive.blender.org/developer/F61674/Normals_value_bug_overlay.png)

Brecht Van Lommel commented

2014-01-04 15:31:55 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2014-01-04 15:31:55 +01:00

It's not clear to me why 128 would be better than 127, neither value corresponds to 0.5, that would be 127.5 which we can't fit in 8 bit.

The code could be tweaked to consistently round up or down here, not sure which of the two is better, I doubt you would be able to see the difference.

It's not clear to me why 128 would be better than 127, neither value corresponds to 0.5, that would be 127.5 which we can't fit in 8 bit. The code could be tweaked to consistently round up or down here, not sure which of the two is better, I doubt you would be able to see the difference.

Andy Davies commented

2014-01-04 19:50:59 +01:00

Brecht, of course you are correct that 127.5 is the ideal value but 128 is expected as the flat colour in UDK and other engines and can actually cause errors in 8bit within those engines when mirroring. Most artists expect 128 as the flat colour too. If you could round it up to 128 that would be great as it might stop some headaches down the line.
http://wiki.polycount.com/NormalMap#Flat_Color

Having said that the flat value in Blender seems to just around quite a bit with the above mesh baking as 128 in 2.65, 126 in 2.58 and the values stated above for 2.69, so this isnt a new issue for sure.

Regarding that the colour isn't uniform across the bake, you can see this when the normals are applied to a mesh with high spec/gloss. Again, I'm not sure if this is worth opening a can of worms...

Brecht, of course you are correct that 127.5 is the ideal value but 128 is expected as the flat colour in UDK and other engines and can actually cause errors in 8bit within those engines when mirroring. Most artists expect 128 as the flat colour too. If you could round it up to 128 that would be great as it might stop some headaches down the line. http://wiki.polycount.com/NormalMap#Flat_Color Having said that the flat value in Blender seems to just around quite a bit with the above mesh baking as 128 in 2.65, 126 in 2.58 and the values stated above for 2.69, so this isnt a new issue for sure. Regarding that the colour isn't uniform across the bake, you can see this when the normals are applied to a mesh with high spec/gloss. Again, I'm not sure if this is worth opening a can of worms... ![tb2_blender_normal_value.jpg](https://archive.blender.org/developer/F61764/tb2_blender_normal_value.jpg)

blender-admin commented

2014-01-08 23:36:11 +01:00

This issue was referenced by blender/blender-addons-contrib@0d57724c64

This issue was referenced by blender/blender-addons-contrib@0d57724c644c6a45cf14778c79b5138438d01cd6

blender-admin commented

2014-01-08 23:36:11 +01:00

This issue was referenced by 0d57724c64

This issue was referenced by 0d57724c644c6a45cf14778c79b5138438d01cd6

Brecht Van Lommel commented

2014-01-08 23:39:35 +01:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2014-01-08 23:39:35 +01:00

Brecht Van Lommel commented

2014-01-08 23:39:35 +01:00

Closed by commit 0d57724c64.

Closed by commit 0d57724c64.

Brecht Van Lommel commented

2014-01-08 23:41:44 +01:00

Thanks for the explanation, that makes sense. I didn't think of sharp glossy case and it's good to know there is a convention, makes it easier to decide. I've biased it towards 128 now.

Andy Davies commented

2014-01-09 00:16:57 +01:00

@brecht, Awesome, thanks! I will give it a test over the next few days with a build from buildbot. Cheers :)

Lino Thomas commented

2014-01-09 18:57:29 +01:00

Thank you very much Brecht, you are awesome :) Keep it up!
And thanks for the showcase Metalliandy ;)

Thank you very much Brecht, you are awesome :) Keep it up! And thanks for the showcase Metalliandy ;)

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Normalmap Baking- Faces with the same normals produce different RGB values #38062