Vulkan: VoxelGI does not take custom shaders into account for emission if the mesh's GI mode is Static

[Calinou]

Godot version

4.0.alpha13

System information

Fedora 36, GeForce GTX 1080 (NVIDIA 515.57)

Issue description

VoxelGI does not take custom shaders into account for emission if the mesh's GI mode is Static. This may be a limitation, in which case this should be documented.

For reference, it works with LightmapGI (dynamic objects are not included in the bake as expected):

Steps to reproduce

• Add MeshInstance3D to act as a floor, with Static global illumination mode.
• Add a second MeshInstance3D with an emissive BaseMaterial3D (StandardMaterial3D). Keep its GI mode to the default Static.
• Add a third MeshInstance3D (with static GI mode). Assign it a ShaderMaterial whose contents are:

shader_type spatial;

void fragment() {
    EMISSION = vec3(0.0, 1.0, 0.6);
}

• Add a VoxelGI node covering all 3 meshes, then click Bake at the top of the 3D editor viewport.

Minimal reproduction project

test_voxelgi_custom_shader_emission.zip

[RandomCatDude]

https://github.com/godotengine/godot/blob/9b7e16a6b8b80fe61881e8f4df28550e18050dd2/scene/3d/voxelizer.cpp#L325-L329

This is the code seemingly used by VoxelGI to bake static meshes.

The problem is pretty clear -- it's hardcoded to use the mesh's StandardMaterial3D if it has one, and then crudely sample its albedo and emission textures. This is why it has issues such as being unaffected by UV scaling options. And of course, this is why it completely fails on meshes using ORMMaterial3D or ShaderMaterial.

I believe the only effective solution would be to move voxelization to be done on GPU, which would enable using the actual material shader to bake the albedo and emission.

[Calinou]

And of course, this is why it completely fails on meshes using ORMMaterial3D

To support both StandardMaterial3D and ORMMaterial3D, it should be easy to use BaseMaterial3D instead of StandardMaterial3D in that code. Feel free to open a pull request for this :slightly_smiling_face:

Edit: Done in https://github.com/godotengine/godot/pull/64219.

[RandomCatDude]

And of course, this is why it completely fails on meshes using ORMMaterial3D

To support both StandardMaterial3D and ORMMaterial3D, it should be easy to use BaseMaterial3D instead of StandardMaterial3D in that code. Feel free to open a pull request for this slightly_smiling_face

Apologies, opening pull requests/contributing is out of the scope of what I'm confident in doing. I just know enough to have been able to pin down where this issue comes from, as I haven't seen anyone else bring it up. But yes, that sounds like a good idea to make it slightly more tolerable, until the aforementioned proper, but far more complex GPU-based solution is made.