-
-
Notifications
You must be signed in to change notification settings - Fork 20k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LightmapGI causes crash when using --headless #89119
Comments
I confirm the crash, tested on Linux. Stacktrace:
|
I confirm the crash, tested on Linux (
Edit: Also reproducible today (April 5) with 7e4c150. |
This works around the crash, but it's not a full fix of course. diff --git a/servers/rendering/renderer_scene_cull.cpp b/servers/rendering/renderer_scene_cull.cpp
index 59d70958f1..0b7e5c2dbe 100644
--- a/servers/rendering/renderer_scene_cull.cpp
+++ b/servers/rendering/renderer_scene_cull.cpp
@@ -1471,6 +1471,7 @@ void RendererSceneCull::instance_geometry_set_lightmap(RID p_instance, RID p_lig
if (lightmap_instance) {
InstanceLightmapData *lightmap_data = static_cast<InstanceLightmapData *>(lightmap_instance->base_data);
+ ERR_FAIL_NULL(lightmap_data);
lightmap_data->users.insert(instance);
lightmap_instance_rid = lightmap_data->instance;
} |
When calling LightmapGI::set_light_data() -> set_base() the rid is 0 when headless.. I think it'd be safe to just ignore lightmaps in headless mode as if there was no lightmap_instance?
Edit: discussion on the PR requests an approach that stubs the lightmap_instance->base_data in the dummy/headless renderer instead of hacking in null checks for every type of data that may be missing there. |
similar: #92412 |
Just a note for interested contributors. The way to fix this will be to store a dummy RID for lightmap instances in the DummyRenderer |
Still mystified by the RID shadow resource system. Is there a walkthrough on how it works and why it exists? :D That or examples of dummy RID for other resource types. |
@jamie-pate We don't have a walkthrough or anything. Basically, the Dummy Server is an implementation of the RenderingServer that doesn't draw anything. It is used for All the functions that RenderingServer exposes are also in the DummyServer, but in most cases they are empty, so they are just no-ops. However, in some cases, they need to return a value, so they return some default value. In some other cases, a real value is needed so the DummyServer needs to save a real value and then return it. This is the case for anything with an RID. The DummyServer should be generating an RID, holding on to it, and then returning it when requested. Particularly, the problem is here:
All lightmap instances get a default RID set to We need to implement godot/servers/rendering/renderer_rd/storage_rd/light_storage.cpp Lines 1968 to 1976 in 4e5ed0b
You also may need to do it for a few other functions that return RIDs. I'm not sure exactly which ones are necessary. Here is an example of how the above looks in a PR ed2b3d3 |
I get that the RID system is an abstraction layer, but it kind of seems like throwing around a bunch of (void*) pointers everywhere from the outside. having to implement stuff like this feel bad :D virtual RS::InstanceType get_base_type(RID p_rid) const override {
if (RendererDummy::MeshStorage::get_singleton()->owns_mesh(p_rid)) {
return RS::INSTANCE_MESH;
} else if (RendererDummy::MeshStorage::get_singleton()->owns_multimesh(p_rid)) {
return RS::INSTANCE_MULTIMESH;
} else if (RendererDummy::LightStorage::get_singleton()->owns_lightmap(p_rid)) {
return RS::INSTANCE_LIGHTMAP;
}
return RS::INSTANCE_NONE;
} Feels like abstract classes or some other kind of typed opaque data structure would be nicer than completely opaque RID handles (effectively a (void *) within special memory blocks that identify the pointer type.. i guess.) (I think i'm progressing towards to a solution at least) |
Fixes godotengine#89119 Add dummy LightmapInstance and Lightmap resources for headless rendering Prevents the RenderingServer from crashing when it accesses lightmap_instance->base_data
Fixes godotengine#89119 Add dummy LightmapInstance and Lightmap resources for headless rendering Prevents the RenderingServer from crashing when it accesses lightmap_instance->base_data
Fixes godotengine#89119 Add dummy LightmapInstance and Lightmap resources for headless rendering Prevents the RenderingServer from crashing when it accesses lightmap_instance->base_data
Fixes godotengine#89119 Add dummy LightmapInstance and Lightmap resources for headless rendering Prevents the RenderingServer from crashing when it accesses lightmap_instance->base_data
Tested versions
System information
Godot v4.2.1.stable.mono - Windows 10.0.22621 - Vulkan (Forward+)
Issue description
Attempting to run a basic project with a baked LightmapGI node causes this crash when using --headless.
Steps to reproduce
Create a scene with a LighmapGI node, bake the lightmap. Run the project with the --headless param.
Minimal reproduction project (MRP)
MRP.zip
The text was updated successfully, but these errors were encountered: