Check RenderingDevice availability to display LightmapGI configuration warnings
- Follow-up to https://github.com/godotengine/godot/pull/87386 and https://github.com/godotengine/godot/pull/91172.
We can now check whether RenderingDevice can be created (which is not guaranteed when using the Compatibility rendering method), so the warning can be displayed only when relevant.
This also disables the Bake Lightmaps button with a tooltip if baking is not available.
Preview
Ignore the GPU model name (it obviously supports Vulkan), I just changed the condition to get the dialog to show up.
Edit: Now displays dedicated warnings if lightmapper_rd was disabled at compile-time, including a specific message for mobile platforms.
This look’s great though i think maybe an additional comment should be added for the android editor when trying to bake since it would confuse people why they can’t bake lightmap gi if they can use the vulkan mobile backend.
This look’s great though i think maybe an additional comment should be added for the android editor when trying to bake since it would confuse people why they can’t bake lightmap gi if they can use the vulkan mobile backend.
Done, see OP for new screenshots.
How often is
get_configuration_warningscalled? Its after every property change right? If so, we need to cache the result ofcan_create_rendering_device()somewhere or else this is going to make things very slow
I've just checked by benchmarking how time it takes to call DisplayServer::get_singleton()->can_create_rendering_device() 1000 times, and it takes 1 microsecond or less on a debug editor build. The method is already cached in its base implementation, as the result of this method can't change during a session.
Node::get_configuration_warnings() is called once per LightmapGI node present in the current scene tree when the tree changes or when the scene is reloaded, so it's not called that often anyway.
I've just checked by benchmarking how time it takes to call
DisplayServer::get_singleton()->can_create_rendering_device()1000 times, and it takes 1 microsecond or less on a debug editor build. The method is already cached in its base implementation, as the result of this method can't change during a session.
Did you test this with the Compatibility renderer? That's where it might be expensive. If there's already a RenderingDevice then it's basically just checking the singleton's existence so that would indeed be fast.
Did you test this with the Compatibility renderer? That's where it might be expensive.
Indeed, I just tried and it takes much longer to run there (easily over 5 minutes for 1,000 calls). Caching this result avoids the issue entirely: https://github.com/godotengine/godot/pull/97698
Thanks!