Implement visibility range and dependencies

[JFonS]

This commit adds the following properties to GeometryInstance3D: visibility_range_begin,
visibility_range_begin_margin, visibility_range_end, visibility_range_end_margin.

Together they define a range in which the GeometryInstance3D will be visible from the camera,
taking hysteresis into account for state changes. A begin or end value of 0 will be ignored,
so the visibility range can be open-ended in both directions.

This commit also adds the visibility_parent property to 'Node3D'.
Which defines the visibility parents of the node and its subtree (until
another parent is defined).

Visual instances with a visibility parent will only be visible when the parent, and all of its
ancestors recursively, are hidden because they are closer to the camera than their respective
visibility_range_begin thresholds.

Combining visibility ranges and visibility parents users can set-up a quick HLOD system
that shows high detail meshes when close (i.e buildings, trees) and merged low detail meshes
for far away groups (i.e. cities, woods).

This is a simple example "city":

visdep.mp4

And this is a stress test with 50k of such "cities" (900k meshes in total):

visdep_fly.mp4

Bugsquad edit: This closes godotengine/godot-proposals#692.

[clayjohn]

Looks really good on a quick review. You'll need to do a search and replace to replace all instances of "hysteriesis" with "hysteresis"

[fire]

Are you using the LOD metric that is used by mesh optimizer?

[JFonS]

Looks really good on a quick review. You'll need to do a search and replace to replace all instances of "hysteriesis" with "hysteresis"

Oops, will do :P

Are you using the LOD metric that is used by mesh optimizer?

No, AFAIK the mesh LOD metric uses the edge lengths and this system has to work on all GeometryInstance3D types. Also, a simple distance check with hysteresis should work just fine for this kind of HLOD.

[Calinou]

Does this visibility range system take the camera FOV into account? I wonder how we can keep using distance ranges while supporting wider/narrower camera FOVs. (Switching to screen coverage metrics would solve this problem automatically, but computing screen coverage has a cost.)

If we want to keep ranges, we could assume that the "default" camera FOV is 75 and use a greater distance multiplier when the FOV is lower (and lower multiplier when the FOV is higher).

Edit: Visibility dependencies aren't FOV-aware, but it can be done by the user if needed. See https://chat.godotengine.org/channel/rendering?msg=ZZE5g87XzQPxpyi5u.

[clayjohn]

Looks good to me!

[reduz]

I am thinking that as much as it pains me, we should probably change it to a system where the parent has a visibility override over the children and not backwards, else usability will be poor.
This also means storing a list of children in the node, which will make editing more difficult and it may require a special editor. I can work on it I suppose, though I am just unhappy.

[JFonS]

I updated the PR with the following changes:

• visibility_range_begin and visibility_range_end are disabled if their value is 0. This means I was able to remove the previous visibility_range_enabled property, and visibility checks are internally enabled only when any of the range values is not 0.
• I changed the visibility_parent behavior so that it only shows it's "children" instances when the camera is too close, while before it would show children whenever the instance was outside of the visibility range (both too far and too close). This means most LOD levels don't have to check for a "range_end" threshold anymore, making the system more user-friendly and faster.

[JFonS]

Pushed the latest version with a new way to define visibility dependencies and fixes for all the mentioned issues.

[reduz]

Looks fantastic, really great job with this!

[JFonS]

I would wait for #48207 to be merged before merging this one. I will take care of the merge conflicts then

[JFonS]

@akien-mga Rebased!

[akien-mga]

Thanks!