0
$\begingroup$

I have a multires object and will bake the normal map to a low poly object with cycles normal bake function. So I unwrap the low poly .set both to smooth shading. Then I generate a UV texture with aplha 32 float 2048*2048.

I try first the Uv image non color color space option then I bake without saving. The baked texture look proper blue all okay. I apple a normal map node setup with image texture node.. On that image node I choose the generated texture. Cycles renderpreview show the normal map efect and it look good. But I dont choose non color. So I try non color on the image texture node but now the normal map looks ugly wrong now in the 3D render preview ???? ,?

So I creat a new texture same settings..2048 alpha 32 float..Name it .. Choose the default SRGB Setting and bake without saving... The first Problem or difference I notice is that in the Uv image editor show the baked normal map in a lighter color ,not so proper blue look more flatt near pink not türkisJ.. I hook up the Image texture node back to the normal map node (detaced before bake) and choose the new generate baked normal map texture . no the 3D render preview I see the seams with that texture and non color option will not work..

So I try the baking again but with saving..both texture setups again . So the problem with saving is, after a reload the baked Maps both baked with different uv texture color space option looks outwashed not proper blue türkis..looks Totals flatt and pinky... (Im novice but it looks not normal not good ) I set up the nodes I choose the normal map Image and non color Data option but I see the seams in the 3D render preview and the normal efects looks ugly..

So I try different Uv texture color space option before baking for the uv Image texture but the propper Uv map comes only out when I save not the image before baking and the texture must use non color for colorspace.. Otherwise baking to SRGB saved texture bring's out a flat pinky normal map..

How I twisted and turned (sagt man das so?) baking will not work on win 7 64 bit system ... Any idea would be great to find the Problem.. Sry can't upload file...or screencast,bad Internet conection at the Moment..

$\endgroup$

2 Answers 2

3
$\begingroup$

The problem appears often and it is a result of bad implementation of linear/sRGB conversion. It works even in case, when it is unwanted. After several trials, lots of nerves, and 5 hours of my lifetime irrevocably lost i found a simple solution.

Although 5 is a magical number - five senses, five elements, five corners of a pentacle, five ingredients of chineese five-spice powder and five member of Iron Maiden on their first studio album. So i found five steps that should solve all your problems.

  1. Leave your Display Device in the Color Management unchanged (default sRGB) and set the output image color space to Non Color Data

  2. Bake your normals. You will see it's pale, and if your highpoly or bump map had some flat areas the RGB value on them will be R188 G188 B255 instead of R127 G127 B255. But don't worry.

  3. Save your image as OpenEXR RGB FloatHalf. Remember to have the "Save as Render" box checked.

  4. Then switch your Display Device to None. You should notice that your texture in the UV/image editor has dimmed and now the average RGB or flat area color is the proper 127 127 255. If you open the .exr in Photoshop you'll notice that it's still "pale" but checking the flat area color value with color picker gives you the value of 127 127 255. There might be a problem with converting such image to 8bit png - it still can be "distorted" to paleish RGB color space. But don't worry.

  5. Remember that your normal texture has dimmed in Blenders image editor?

That's right! Once again save the image, but use "Save As Image" instead of "Save Image". Remember to check the "Save as Render" box again. Now you can change the format to .png.

After saving your PNG you'll notice that now it is even more dimmed... but don't worry :D Open your normal map png in any other program or switch blender display device back to sRGB and you'll see that the colors are right.

$\endgroup$
2
$\begingroup$

There might be a language barrier here. Without further information, it is a challenge to fully diagnose your issue.

However, it is noted that you have attempted your workflow with both saved and unsaved files. This is a potential source of issues.

When saving a file, file formats do not save identically, and most are mangling up the data representation.

All file formats with the exception of EXRs will perform some form of color transform on the data. Only EXRs will preserve the integrity of float data, and also keep the data in linearized format. If saving a data format, such as linearized values, one should take care to only save to EXRs to preserve the integrity of the values.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .