I’ve had nothing but problems using Texture2dArray in the past with Normal Maps, and it appears to suffer the same fate with its use in Entities Graphics for Lightmaps.
On URP macOS M2
Some Photos:
Editor with Subscenes open for editing (How it should also look in the player):
In the above case, the inspecter shows all lightmaps in the coverted array as being white.
Interestingly, if I manually enable the read/write option of the lightmap textures, I get this in the converted play mode/closed Subscenes and the inspector shows the correct lightmaps (Better, but still rendered incorrectly):
Note: The objects that render correct in this case are lit by Probe Volumes.
Welp, I can confirm this is an issue with Texture2dArray creation, since there is no way to set the type to “Lightmap” or “Directional Lightmap” like the importer does, and Unity ends up treating them quiet differently than how they should be treated. Not sure exactly what happens under the hood since for us, it is kind of a black box. But just searching briefly shows this has been a frustrating issue with devs for a long time now.
Unity - You can’t ignore this anymore since it is messing with your own code now!
Also how did this go unnoticed by the dev team and pushed out?!?!?!?!?
If the scene is only broken when subscene is closed, something might be wrong on Entities Graphics side. Do you mind sending us a bug report and let us know the bug id?
Yes, I sent a bug report in already. I’ll update this when I have a sec to get the ID.
I have narrowed it down to the Texture2dArray being unable to properly handle Lightmap format types in the same way the texture importer can. Entities Graphics checks if the Lightmap is sRGB and uses the result to set the linear flag during creation, but the RGBM format needs some special handling since setting it linear prevents proper colorspace, but setting it sRGB means it cannot use multiplier. For comparison, the original Directional Lightmaps are imported with both Linear and sRGB flags set to false, but with Entities Graphics it has to be set to one or the other.
I dunno how Unity handles this under the hood, but right now Texture2DArray simply cannot provide what is needed and will likely need to be extended.
The other issue with the Lightmaps converting to pure white seems odd, since it should still be able to copy the texture data without needing to set the read/write flag and create a copy in cpu memory. Maybe this is something with the order of conversion? I dunno. Can’t figure that one out. But I imagine it will be a much easier fix than the Texture2dArray format.
I will say that these types of bugs have actually proven strangely valuable to me, since they forced me to get a much more thorough understanding of the code base, making it easier for me to extend in my project in the future.
That said, most people would probably prefer working Lightmaps. ;):)
Just realized the project I sent you had Subtractive lighting enabled, as I was testing the different modes. This outcome of incorrect entity rendering (after enabling the read/write setting of lightmaps) is known for Subtractive mode. However, the scene is still rendered wrong in shadowmask modes as well.
I still stand by the problem being the creation of Texture2DArray. With Normal Maps and Texture2dArray one must use NormalUnpack to get correct results. It is unclear exactly what needs to happen with lightmaps, but clearly something is wrong.
Also, the lightmaps shouldn’t require read/write enabling in order to not appear blank, since that doubles the amount of memory.
I have tried to reproduce this issue using an M1 Mac, and I was unable to to reproduce the pictured issue (lightmaps completely white). Can you describe the specific combination of lightmapping settings required to trigger this on your end? I attempted many different lightmapping settings (both Subtractive and Shadowmask) and was unable to cause the issue to happen using 2023.2
Yes I will upload some settings screenshots to the shared folder since that saves a lot of typing.
I am using APV if that matters. I just checked, and this issue is still present unless I manually enable read/write on all of the baked lightmaps before closing the subscenes. And after that, I have to manually re-bake each light probe (baked probes) 1 by 1 for them to be correct, otherwise they have areas missing, blacked out, or white like the lightmaps.
EDIT:
I created a new folder and uploaded the screenshots of pretty much every setting, just to be extra cautious.
Okay, I just opened one of the entities samples, converted game objects to lightmap. Make sure one has a texture and normal map. Place baked light probe in scene, make sure more than 1 lightmap is baking to trigger the Texture2dArray conversion. I also copied all my settings over.
This reproduced the issue, but strangely the lightmaps appear the same color as an error shader (pink/fuchsia color) rather than white. I’m unsure why. But the problem goes away again when manually setting each lightmap to read/write enabled.
I suspect you were likely trying to reproduce this with a scene that fit into a single lightmap which wouldn’t be converted to a Texture2dArray, thus avoiding this issue. Ensure you are baking more than 1 lightmap to reproduce.
Unity seems to always require the input textures to be read/write enabled when creating Texture2dArrays that aren’t run-time created. I think Entities Graphics is using run-time conversion compatible methods here, but this is done pre-runtime. The solution is either to:
Change the methods (not sure if that is possible)
Automatically set the read/write enabled on the lightmaps when baking
Create a companion object and do it at runtime.
Since it seems Entities is avoiding all runtime conversions, the last one is probably not a good fit. Ideally one could have new methods for Texture2dArray creation that don’t require these flags to be set, but I am unsure if that would even be possible due to the way Texture2dArays work.
