"Open Anyway" does not work when .lmbake file is missing.

[johnlorentzson]

Godot version

v4.2.rc1.mono.official [ad72de508]

System information

Godot v4.2.rc1.mono - Fedora Linux 39 (Workstation Edition) - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 980 Ti (nvidia; 535.129.03) - AMD Ryzen 7 2700X Eight-Core Processor (16 Threads)

Issue description

I have a scene that uses a LightmapGI node. I do not wish to store the .lmbake file in version control since it's a somewhat large binary file that can be regenerated by the engine, so I've added it to my ignores. When I try to open the scene without the .lmbake file being present, it fails and asks me to resolve the missing dependency. Clicking "Open Anyway" gives me a generic error. It would be preferable if it simply required rebaking the lighting instead of completely failing.

If I was using Perforce for my version control I could just make it only store the newest version of .lmbake files, but we can't all be using Perforce.

Steps to reproduce

• Create a scene using a LightmapGI node.
• Bake the lighting.
• Quit Godot.
• Delete the .lmbake file.
• Reopen Godot (and the scene, if it does not automatically open).

Minimal reproduction project

lmbake-error-repro.zip

[Calinou]

This workflow isn't currently supported by the engine (even though I think it should). The same issue applies with VoxelGIData and GPUParticlesCollisionSDF3D's texture data. Note that VoxelGIData does store some properties that affect visuals, such as an energy multiplier.

One way to fix this would be to always allow loading scenes with specific resource types missing, but replace them with placeholder types so that methods/properties set on them are preserved (and print a warning when this happens). However, we can't have a shared type in the inheritance tree without breaking compatibility. For the record, this is how placeholder types for dedicated server export are implemented. For instance, PlaceholderCubemap is at the same level as Cubemap, and both are subclasses of TextureLayered.

I do not wish to store the .lmbake file in version control since it's a somewhat large binary file that can be regenerated by the engine, so I've added it to my ignores.

On the bright side, storing this binary file makes it possible to revert to old commits without having to bake anything again. It also makes it possible to quickly export the project using CI. In a large game project, a full bake of all data can take several hours on a high-end PC.

In the era of fast Internet connections and large mass-storage devices, this approach may actually be preferable for some projects, especially since CPU power (or even GPU power) has comparatively grown slower.

[johnlorentzson]

You make some good points in favor of storing the baked data in the repository, I'll consider it. I'm mostly worried about the repository ballooning in size once level designers start making frequent changes requiring rebaking, but the repo is still smaller than the builds and the environments we have aren't all that big, there's just gonna be a lot of them. Worst case scenario I can just buy a new hard drive for our server, but even that probably won't happen, I'm probably just being paranoid.