Maybe you should try to reset your lightmass settings, put a plain material (white, no reflection, no normals…) on your mesh(es)! /right now you’ve changed unnecessary settings under lightmass + who knows what that can cause strange results!
Do you have lightmassimportancevolme covering your area? Lightmass compression should be turned off!
64 res lightmap… It’s in pixels!! So it’s going to be low resolution and inaccurate!!
Are you using static/stationaty lights (Sky + directional light)?
…also if you could show us the lightmap uv of this mesh…
Appreciate the response, but there is a lot wrong with your advice.
you’ve changed unnecessary settings under lightmass
I disagree. There are many reasons why you would want to adjust your lightmass settings and making these changes is normal in a production environment. Regardless, the screenshot above is with default lightmap settings.
Lightmass compression should be turned off!
This is not advisable. Uncompressing lightmaps can add significant memory costs. For platforms like the Switch where memory is very limited, you absolutely need to have compress lightmaps turned on.
64 res lightmap… It’s in pixels!! So it’s going to be low resolution and inaccurate!!
This is an inaccurate statement. Just because your resolution on an asset is set to 64 doesn’t mean it’s going to be inaccurate. There are a lot more factors that go into determining accurate lightmap resolutions and setting this value too high can add unnecessary bloat to your overall lightmap count and memory footprint.
Again, appreciate your response, but the advice is inaccurate and misleading.
Update to this issues. It appears we have a trifecta of problems occurring.
Problem #1
When using HISMs or HLODs, after creation of the HISM/HLOD the original assets can be (and are) hidden in game and editor. While this is great for iterations, the engine is still generating lightmaps and calculating shadows as if the object were unhidden and visible.
Problem #2
HLODs/HISMs do not support unique static lighting for Mesh LODs. More specifically, lighting on LODs 1+may be incorrect unless lightmap UVs are the same for all LODs. We’re observing that when assets are combined into ISMs, the ISM’s LOD inherent the base meshes lightmap, often causing major shadowing of the entire ISM. AKA, visually it looks terrible (reference screenshot above).
Problem #3
It appears that when we import custom LODs for assets (often necessary to fix shading artifacts associated with normals or tangents), by default the “Generate Lightmap UVs” in the build settings is toggled ON. After importing the custom LOD, it regenerates entirely new Lightmap UVs for the custom imported LOD.It appears there’s a direct correlation between the new Lightmap UVs and LOD switching; in particular, moving the location of the LOD Lightmap UVs and their position on the associated Lightmap.
In summary: we can solve the issues with Problems #1 & #3, however, we have yet to find a workable solution for Problem #2 that allows us to still use ISMs and have baked lighting.
For #2 it is hard to solve. Either you need to make sure the LODs of the same mesh share the same UV layour so that lightmap of LOD0 can be applied to other LODs, or you need some heavy engine modifications into ISM so that it uploads multiple per instance lightmap uv vertex buffers and uses them in the vertex factory.
