MultiMeshInstance3D Fade Mode Culling doesn't respect AABB

[TokisanGames]

Tested versions

4.3-stable, 4.4-beta3

System information

Godot v4.3.stable - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 Laptop GPU (NVIDIA; 32.0.15.6614) - 12th Gen Intel(R) Core(TM) i9-12900H (20 Threads)

Issue description

Normally, both MeshInstance3Ds and MMIs cull based on comparing the AABB of the visible meshes with the visibility_ranges.

This means, even if the MMI instance transforms are far from the location of the MMI node, they are still culled based upon distance to the center of the AABBs encompassing the instances. The MMI location is ignored.

However, if visibility_range_fade_mode = self, this is not true. Shadows correctly cull based on the AABB. The visual mesh is incorrectly culled by something else, so the shadows show but the mesh does not.

This is preventing us from providing fading between instance LODs in Terrain3D.

MMI location in the center of the instances AABB

MMI location far from the instances AABB

Steps to reproduce

Open the MRP. Look at TestArea3. Move the camera towards the center of the grey areas. Read the README node for more info.

Minimal reproduction project (MRP)

test-mmi-margin.zip

[clayjohn]

We probably need to copy the same logic used for LODs into the code for fading. See here for reference: #92290

[ttencate]

The documentation explicitly says origin, so to preserve backwards compatibility, an option should be added to use the AABB instead.

Should this compute the distance to the center of the AABB, as mentioned by @TokisanGames above, or to the closest point on the AABB? I think closest point would make more sense: if the camera is close to a very large AABB, we'd still want the highest detail level, just like with automatic LODs. (If there's going to be an option, it would be straightforward to support both, but there's no need to write/maintain code if nobody will use it.)

[ttencate]

Related, and possibly duplicates: #68243 (though this is not for multimeshes), #79471

[ttencate]

I can't find anything specific to multimeshes in the code; it's all just VisualInstances at this level.

This looks like a discrepancy to me; am I barking up the right tree?

godot/servers/rendering/renderer_scene_cull.cpp

Line 1471 in 5f12ada

vd.position = p_instance->transformed_aabb.get_center();

vs.

godot/servers/rendering/renderer_rd/forward_clustered/render_forward_clustered.cpp

Line 957 in 5f12ada

float fade_dist = inst->transform.origin.distance_to(p_render_data->scene_data->cam_transform.origin);

[TokisanGames]

What happens in the MRP if you change the latter to compare fade distance against the AABB center with the camera origin?

The documentation explicitly says origin, so to preserve backwards compatibility, an option should be added to use the AABB instead.

Backwards compatibility means to maintain how it works, not change how it works to account for incorrect documentation. The doc says origin, but the code says AABB center. The docs are wrong.

Though it's unlikely a MeshInstance3D will have a custom AABB removed from their origin, it has the option to do so, and MMIs are highly likely to have separated AABBs. Culling based on MMI origin would be disastrous.

Should this compute the distance to the center of the AABB, as mentioned by @TokisanGames above, or to the closest point on the AABB? I think closest point would make more sense: if the camera is close to a very large AABB, we'd still want the highest detail level, just like with automatic LODs.

The closest point would be a redesign choice, not a fix, and not backwards compatible. You could discuss that at the rendering meetings. My thought on the matter is the AABB center is simplest. Why compare 8 distances every frame for thousands of objects when one will suffice?

How it works right now is fine. The issue is only the fade mode, which as you noted the code doesn't match non-fade mode. All we need is to fix fade mode and this ticket can be closed, and possibly some of the others found.