Expose properties for setting manually created automatic LOD meshes in the Mesh resource inspector

[mrjustaguy]

Describe the project you are working on

Game

Describe the problem or limitation you are having in your project

A mesh with Auto LODs applied should have it's LOD meshes in the inspector, but they aren't exposed. This prevents using and tweaking the Meshes, or just replacing them entirely by Hand-made ones for the LOD system to use.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Mesh Instance should get a LOD Dictionary, in which the Auto LOD system should switch between from 0 to n.
0 is currently exposed as "Mesh" in Mesh Instance, and Auto LOD has it's n LODs hidden from the user along with it's other parameters used to determine when to use it. This should be exposed to the user, and the User should be able to define their own should they need to.
This allows for the best of both worlds between ALOD and HLOD. Easy Setup (automatic if you don't want to make handmade LODs) allowing you to pick which meshes you want for what LOD, without having to have multiple Mesh Instances and tweaking each such that both transit at the same time, and allows to better utilize Automatically generated LODs should they have issues.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Inspector Should Look something along the lines of what the current Mesh Instance looks like, but instead, the Mesh Should have LOD properties similar to how Multiple Surfaces display on a Multi Surface Mesh, but instead of Surfaces, it should be LODs (0,1,2,...n)
How it should Work:

• Mesh (LODs used 0,1,2,3,4)
  Inspector under Mesh LODs should show LODs 0,1,2,3,4,5 with the 5th being empty, and should it be added by the user, it should add a 6th empty and so on.
• Auto Generation - Creates all as normal, just exposes them under the Inspector so that they can be hand tweaked with the new proposed workflow.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, HLOD is the closest to dealing with a part of the issue, but it has issues that ALOD doesn't.

Is there a reason why this should be core and not an add-on in the asset library?

LOD is core.

[fire]

For reference these are the current properties.

https://github.com/godotengine/godot/blob/fe52458154c64fb1b741df4f7bd10106395f7cbd/scene/resources/importer_mesh.cpp#L780-L812

Lods contain only distance and the indices used by the LOD from LOD0.

https://github.com/godotengine/godot/blob/58324f4df822c7416278cda5bf41662e979f9e31/servers/rendering_server.cpp#L1035-L1038

[npip99]

Manual LOD would be very helpful and should be much easier to implement than automatic LOD.

Generating LODs from blender is very easy and very high quality, and game-ready assets often have LODs provided (If they're truly game-ready).

Manual LOD can be a set of empty slots on a GeometryInstance3D, so that you can drag and drop meshes. And Automatic LOD functionality can be a button "Automatically Generate LODs" that fills in the empty slots.

~ I like the opt-in Button, having this feature be hidden and "automatic" feels weird when it changes your geometry without your consent, and without an ability to even inspect the generated meshes, making it weird to debug graphical artifacts.

=========

Note for feature requirements for advanced users: When generating LODs from Blender, you can rebake normal maps onto the geometry to maintain realism, so having different materials per LOD mesh is an important feature (Rather than just allowing LOD meshes without per-LOD materials).

A very productive workflow using Manual LODs for hyperrealism+hyperperformance is as follows: Start with your hyperrealistic 1M+ vert sculpt in ZBrush+Blender, and a very low poly Blender model with subdivision modifier. Bake the sculpt geometry onto the low poly mesh to generate normal maps (albedo/specular too, but normal is most important). Subdivision modifier can be easily adjusted (1, 2, 4, 8, 16), and normal maps rebaked for every LOD. Resultant models are hyperperformant and hyperrealistic (Total number of rendered tris is very very low in all scenarios).

Current testing shows automatic LOD from Godot often has really bad degradation, with very obvious artifacts; it only looks reasonable when triangles stay close to 1 pixel in size (Which gives very poor performance, and turns what would be very fast MSAAx4 into a slower version of SSAAx4; lowering MSAA gives very annoying jaggies). I think fundamentally totally automatic LOD can't compete with baking into a subdivision modifier, especially if the sculpt was done on the subdivided surface as that maps really well.

[Calinou]

Current testing shows automatic LOD from Godot often has really bad degradation, with very obvious artifacts; it only looks reasonable when triangles stay close to 1 pixel in size (Which gives very poor performance, and turns what would be very fast MSAAx4 into a slower version of SSAAx4; lowering MSAA gives very annoying jaggies).

godotengine/godot#84384 should improve automatic LOD significantly with similar performance as before.

Also, rendering lots of triangles isn't that much of a problem in itself on desktop. What's a problem are triangles smaller than a pixel, which go through a slow path on the GPU's rasterizer.