Fix _LightInfos V7→V8 migration and add dumpLightmapInfo diagnostic command

[Copilot]

• Analyze lightmap pipeline code (calc_lm, lightmap_optimizer, instance_lighter, rendering)
• Understand lightmap factor system (LightGroup, AnimatedLight, LMC colors)
• Identify potential issues in lightmap data migration (version 7→8 _LightInfos)
• Fix _LightInfos version 7→8 migration in mesh_base.cpp (data silently dropped)
• Add dumpLightmapInfo diagnostic command to Ryzom client for debugging lightmap issues
• Enhance diagnostic command with effective factor resolution, zero-factor warnings, and animated light index info
• Test changes compile correctly (nel3d, ryzom_client, lightmap_optimizer all build)
• Code review and address feedback
• Security scan (no issues found)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Sunlight missing from stage lightmap in Zora</issue_title>
<issue_description>

</issue_description>

<agent_instructions>These assets are exported through the 3ds Max build process, and processed through the whole pipeline, which includes lightmap processing and such, there are steps which combine lightmaps and adjust the shapes and so on. I'm not sure if this is a gamedata build issue or an issue in rendering, although with the original data the issue does not occur, so I'm more inclined to assume either something is wrong in the gamedata export build or some asset property being misconfigured. If no solution can be found, then an asset diagnostic (debugging tool or command or other that may reveal more information) would be appreciated. The issue recurs on these same assets on every build</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@kaetemi 

Similar sunlight issue in a section in the back of Pyr, but behaves differently on player light.</comment_new>

• Fixes Sunlight missing from stage lightmap in Zora #645

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[kaetemi]

@copilot Interesting find, although the assets I'm using should have the latest format, since they're freshly rebuilt, no? Feel free to look around more. I will test the command in a bit

[Copilot]

@copilot Interesting find, although the assets I'm using should have the latest format, since they're freshly rebuilt, no? Feel free to look around more. I will test the command in a bit

You're right — freshly rebuilt assets would already be in the latest format, so the V7→V8 migration fix wouldn't apply to your case. That fix is only relevant for legacy shapes still in the old format.

I did a deep dive through the pipeline (calc_lm export, lightmap_optimizer, runtime rendering). The most likely runtime cause I found: in CDriverGL::computeLightMapInfos, any lightmap layer whose Factor RGB is zero gets completely skipped from rendering (mat._LightMaps[i].Factor.getPacked() & RGBMaskPacked). The factor is set per-frame in CMeshBaseInstance::traverseAnimDetail() from the scene's animated light system based on the _LightInfos entries' AnimatedLight name and LightGroup value.

So if the AnimatedLight name doesn't match the scene's animation set, or if the LightGroup maps to a color that's currently black (e.g. night cycle during night), that layer becomes invisible.

I enhanced the diagnostic command in b9dcf1c to help pinpoint this. It now shows:

• The resolved animated lightmap index (or -1 if unresolved) for each LightInfo entry
• The current effective factor for each entry (what the renderer actually uses)
• Explicit *** ZERO - layer will be invisible! *** warnings when a factor is black
• Count of active vs total layers per material
• All light groups up to 6 (showing default vs explicitly set)

Run dumpLightmapInfo <shape.shape> on an affected asset to see if any sun layer shows a zero factor or missing animation binding.

[kaetemi]

@copilot Please merge in the latest changes from the core4 branch (normal merge) and resolve any merge conflicts

[Copilot]

@copilot Please merge in the latest changes from the core4 branch (normal merge) and resolve any merge conflicts

I'm unable to perform git merge operations or pull branches from GitHub in my sandboxed environment. Could you merge the core4 branch into this PR branch locally or via the GitHub UI? If there are merge conflicts afterward, I can help resolve them once the merge is done and the conflicts are visible in the files.