Enlighten lightmap EXR output contains Alpha channel!

Hi, I’d like a solution to how to fix this. When lightmaps have compression turned on the quality is really, really bad. I suspect that’s because they contain an needlessly included alpha channel - that completely ruins the quality on PC and mobile devices.

If that Alpha channel is manually removed (in lets say, Photoshop) the quality issues disappear for the most part. However the resulting lightmaps are darkened considerably by doing so. Is there a way to force enlighten to not output this ridiculous alpha channel? Or am I going to be stuck post processing these lightmaps to work properly in Photoshop?
As it stands, default compressed lightmap output is unusable.

Thanks!

Why would a lightmap not need the alpha channel?

Because lightmaps, as I have always seen them used, are essentially multiplicative. Sure, EXRs use HDR to provide greater than 1 lighting to that multiplicative process, but there’s nothing in that process that requires an alpha channel.
It’s entirely superfluous in every case I can imagine, especially for simple Non-Directional Baked lightmaps.

Moreover, in Beast, the generated light map files did not contain an alpha channel. This, from what I can see, is directly responsible for the drastic drop in quality from Beast to Enlighten compressed light maps.

Also, as I noted, I can remove the alpha channel from the EXR in photoshop, and the end result works exactly the same in Unity as a lightmap - with a massive increase in quality when compressed.
As far as I’m concerned, this has to be a bug…

No ideas or thoughts on how to disable this?

There’s got to be a way to disable this. The savings of 1/3rd the size of uncompressed lightmaps alone would make it worth it. Even if you ignore the increase in compressed lightmap quality, the size difference is important.

Hi Howard, it would be great to know which platforms you are targeting, since lightmaps are compressed in different ways depending on platforms.
On mobiles, we usually encode as double-LDR which is the rgb values multiplied by 2 to get more range. On more capable platforms we use RGBM encoding which is storing an exponent in the alpha channel. If you are targeting a platform that is using RGBM encoding you need the alpha channel.
The texture compression is applied on top of these encoding schemes and it would also be great to know which encoding you are using? DXT or ETC or something else?

Hi! So I’m targeting both webplayer and Android. I consistently see both platforms compressing lightmap textures as alpha. DXT5 and ETC2. When I say that it’s compressing with alpha, I mean that there’s an alpha channel in the source EXR, that simply describes where the lightmap covers. Has your lightmap compression system changed since Beast? I only ask because the compressed ETC lightmap textures on Android devices have had a serious hit to quality since the changeover to Enlighten.

Perhaps you are using directional lightmaps in Unity 5? The directional lightmaps use the alpha component of the directionality texture.
If you are using non-directional, only the RGB values are used when doing dLDR encoding and ETC should not use alpha. Does you lightmap have the same properties as this (RGB compressed ETC 4 bits)?
2067702--134880--2015-04-14_11-23-29.png

No, I’m using Non-Directional. Here are my settings and the result. If I switch it to “ETC Compressed 4 bits” it will not accept the change and forces it to go to RGBA 16 bit.
I can get a better result if I force it to compress to ETC2, but again, that’s still using the alpha channel.
I cannot get it to compress without alpha.

2068253--134933--lightmap_settings.PNG


What version of Unity 5 are you using? I had problems like that in the release 5.0, but some patch release fixed it and the lightmaps were compressed properly. Presumably that is the case with 5.0.1, too.

mh114: You are absolutely correct. I updated to 5.0.1f, and it’s perfect now. I was on 5.0.0f4 or whatever the last release was, and obviously missed the update. I want to apologize to the Unity guys - You’d already fixed the problem I had, and I was just too dumb to get the fix. :stuck_out_tongue:
KEngelstoft: Thanks so much for your patience and time. I’m sorry I wasted either. :slight_smile:

I am happy to hear it works for you now :slight_smile:

Well, now of course the lightmapping is completely broken. It displays only Black. No lightmapping. Android and Webplayer are the same, and it looks great in the editor. I have custom lightmaps, which appear fine. the enlighten stuff seems to be the only thing broken - as light probes are also affected.
here’s a link to the android and web builds, along with a picture from the editor.
Device Detection < Web
Device Detection < Android

Are you running this on Android with GLES 2.0 or 3.0? Baked lightmaps should work fine everywhere ofc.

Are you using Precomputed Realtime GI or Baked?

I’m running this on Android, Yes. As far as I know Open GL 2.0 and 3.0 are the only options, so yes, I’m running them - it makes no difference if I run 2.0 or 3.0, the lightmaps remain black. Also, it’s not only on Device. The Webplayer link I posted above also shows black lightmaps.
I’m using Non-Directional Prebaked lightmaps. My settings are posted above.

That should of course work - would you mind filing a bug report?

Yep, I posted the bug report - with source. http://fogbugz.unity3d.com/default.asp?690250_h0pl2aqj9cd0thka

Major major major update to this Black-Lightmaps bug! It only occurs when using the Cloud Building System! The links I posted are to versions made with the cloud building system, and then, and only then, display black.
Regular builds from the editor work properly.

Thanks for the extra info, we’ll investigate.