Unity 5: Different handling of exr files in lightmapped scenes?

Hey everyone,

I noticed some differences in how .exrs are displayed in Unity 5s lightmapped and non-lightmapped scenes.
The issue happens in the inspector as well as in the scene. The issue happened even after I copy-pasted and renamed the lightmap.
Looks like an issue affecting all exrs in the project and it didn't happen in Unity 4. My workaround for this was to convert it into a psd which solved the issue for now but I'd love to find a better solution for this since it's a lot of work if I have to do it manually for many lightmaps.

Please, is there a proper solution to get a consistent behaviour or can this considered a bug?

 

Is there a setting you can recommend? I tried many different settings from "texture" to "lightmap" to "advanced" but it still happened no matter what I did. Even compression didn't change anything. The texture still gets lighter in non-lightmapped scenes and stays normal in lightmapped scenes.

Just to make sure everyone understands the problem: All I do is switch the scene and the copy of my lightmap (currently set to "texture" under "texture type" in the inspector) seems to change its gamma settings or something like that. It didn't happen in Unity 4, the file itself doesn't seem to change since it stays normal when opening it in photoshop, and it doesn't happen to any other file types, only exr. It also happens no matter if the project is set to gamma or linear color space.



The scenes that I switch between only differ from each other in one term: one of the scenes is lightmapped, the other one isn't (which means one of them has its Baked Data Cleared inside the lighting window).

 

Oh I see, that great, thx! I'm currently using Unity 5.0.0f4 but will try with 5.0.0p4 when it's released.

 

I'm currently using Unity 5.0.0f4 and also had some gamma-like issues with my lightmaps. The thing was in new option in texture import settings "Encode to RGBM" by default set to "Auto". As I understand now unity handles .exr files like HDR textures and by default encodes its color info according to rgbm algorithm and result textures looks like gamma-corrected. So the fix was to simple turn "Encode to RGBM" to "Off".

 

I'm experiencing different kind of issues with exr files. But seems like they're related to the same "exr import" problem described here.

I've just upgraded from unity 4.6 to unity 5 and suddenly all my exr textures (which I use a lot for FX) become really weird.

E.g., this is simple polar coordinates texture (captured in Nuke):

it has clockwise ramp in it's R channel and radial ramps in it's G and B channels.
It also has the "hide U-seam" mask in it's alpha. I.e., channels are:

This is how it looked in Unity 4.6 when imported:


Obviously, there's some Linear -> sRGB visual difference. But besides that the texture is exactly the same as in Nuke.

And now here's how this exactly same texture is imported to Unity 5:

First of all, you can see for some reason Unity lost alpha channel. And secondly, it imported this texture really weird way.

 

Here's what RGB channels became in U5 (visualised with custom shader):

R:
G:
B:

Why does it happen? Is there a way I can overcome it?
I need some textures in true 32-bits per channel float-point mode ("real" truecolor, so PNG is not enough).
I tried to overcome this issue by converting the texture itself to 32-bit TIFF file format but Unity 5 doesn't want to import them at all. Here's how TIFF file is displayed in Unity:

With the following error in console:

Obviously, truecolor mode is enabled for the texture (both in U4.6 and U5).
Windows 7 64 bit, Unity 5.0.0p2

 

yes, that's something I noticed, too. I assumed that the lightmaps just don't generate alpha anymore but it seems all exrs lose it upon import.

 

I think I might have a solution for you though. Please try something like this in your custom shader in the fragment part and see if that'll fix the lightness:

Code (CSharp):

1. float3 exrTexture = DecodeLightmap(tex2D(_MainTex, i.uv));
2. return float4(exrTexture, 0);

I recently did something similar when I wanted to use an exr as a diffuse.
Please let me know if it works for you, I'd love to understand this better

 

Nope, unfortunately it didn't help at all.
Both with DecodeLightmap and without - colors are exactly the same.

Maybe there's some other image format which can store 32-bit float values?

 

@KEngelstoft
already did it at the same time as posting my previous comment: http://fogbugz.unity3d.com/default.asp?684391_2046t585gvf21o5q
Bugreport has an attached file with that texture (for testing) and a link to this thread (to avoid screenshots duplication).

 

@KEngelstoft
Is there any update on the issue? Or maybe you can suggest any other way to pass a 32-bit texture to Unity?
Right now my project is stuck because I can do nothing to make my effects look better. With 8-bit texture they look just horrible (8 bits are far from enough for polar coordinates) and I don't know about any other way to pass some 32 bit data to shader.
There's even no reply on the bugreport itself. Not even a confirmation that UT was able to reproduce this bug (it takes just a couple of seconds to do so: just open the same texture in Unity and in PhotoShop) and is going to fix it some day.

 

Hey guys, it seems like there's this script to import point-clouds as 32bit EXRs, there's a Github link in the code too.

Code (CSharp):

1. // Pcx - Point cloud importer & renderer for Unity
2. // https://github.com/keijiro/Pcx
3.  
4. using UnityEngine;
5. using System.Collections.Generic;
6.  
7. namespace Pcx
8. {
9.     /// A container class for texture-baked point clouds.
10.     public sealed class BakedPointCloud : ScriptableObject
11.     {
12.         #region Public properties
13.  
14.         /// Number of points
15.         public int pointCount { get { return _pointCount; } }
16.  
17.         /// Position map texture
18.         public Texture2D positionMap { get { return _positionMap; } }
19.  
20.         /// Color map texture
21.         public Texture2D colorMap { get { return _colorMap; } }
22.  
23.         #endregion
24.  
25.         #region Serialized data members
26.  
27.         [SerializeField] int _pointCount;
28.         [SerializeField] Texture2D _positionMap;
29.         [SerializeField] Texture2D _colorMap;
30.  
31.         #endregion
32.  
33.         #region Editor functions
34.  
35.         #if UNITY_EDITOR
36.  
37.         public void Initialize(List<Vector3> positions, List<Color32> colors)
38.         {
39.             _pointCount = positions.Count;
40.  
41.             var width = Mathf.CeilToInt(Mathf.Sqrt(_pointCount));
42.  
43.             _positionMap = new Texture2D(width, width, TextureFormat.RGBAHalf, false);
44.             _positionMap.name = "Position Map";
45.             _positionMap.filterMode = FilterMode.Point;
46.  
47.             _colorMap = new Texture2D(width, width, TextureFormat.RGBA32, false);
48.             _colorMap.name = "Color Map";
49.             _colorMap.filterMode = FilterMode.Point;
50.  
51.             var i1 = 0;
52.             var i2 = 0U;
53.  
54.             for (var y = 0; y < width; y++)
55.             {
56.                 for (var x = 0; x < width; x++)
57.                 {
58.                     var i = i1 < _pointCount ? i1 : (int)(i2 % _pointCount);
59.                     var p = positions[i];
60.  
61.                     _positionMap.SetPixel(x, y, new Color(p.x, p.y, p.z));
62.                     _colorMap.SetPixel(x, y, colors[i]);
63.  
64.                     i1 ++;
65.                     i2 += 132049U; // prime
66.                 }
67.             }
68.  
69.             _positionMap.Apply(false, true);
70.             _colorMap.Apply(false, true);
71.         }
72.  
73.         #endif
74.  
75.         #endregion
76.     }
77. }
78.  

 

Very late in the game....... but never know, it did the trick for me and took 2 years before I understood what was in front of my eyes....