Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vulkan: Automatic mesh LOD always picks lowest level of detail in orthogonal camera #57404

Closed
Tracked by #57416
TokageItLab opened this issue Jan 29, 2022 · 6 comments · Fixed by #57419
Closed
Tracked by #57416

Comments

@TokageItLab
Copy link
Member

Godot version

4.0.dev (2f57a11)

System information

MacOS 11.6

Issue description

Meshes are broken in Orhtogonal view. Is it because of Auto LOD?

スクリーンショット 2022-01-30 0 41 46

Steps to reproduce

Put on glb model in 3D scene, use orthogonal view.

Minimal reproduction project

broken_mesh.zip

@Calinou
Copy link
Member

Calinou commented Jan 29, 2022

I can confirm this on master fc09d78.

This is caused by automatic LOD, as disabling it in the advanced debug draw mode options using a viewport's Orthogonal menu will work around the issue:

image

This option only applies in the editor. To disable LOD in the running project, set the rendering/mesh_lod/lod_change/threshold_pixels project setting to 0.0.

@Calinou Calinou added this to the 4.0 milestone Jan 29, 2022
@Calinou Calinou changed the title Broken mesh in Orthogonal view Automatic mesh LOD always picks lowest level of detail in orthogonal camera Jan 29, 2022
@Calinou Calinou changed the title Automatic mesh LOD always picks lowest level of detail in orthogonal camera Vulkan: Automatic mesh LOD always picks lowest level of detail in orthogonal camera Jan 29, 2022
@orosmatthew
Copy link
Contributor

orosmatthew commented Jan 29, 2022

I did a little investigation and found this is because the preview orthogonal camera is placed ~2000m away from the origin thus resulting in a low auto LOD. Instancing a Camera3D set to orthographic works as expected and lowers LOD when moved farther away.

2022-01-29.13-10-15.mp4

I'm not completely sure what the solution would be. Either bring the preview orthographic camera closer to the origin (which is not a great solution) or disable auto LOD only when the preview camera is used and not instanced by a node. Thoughts?

Edit:
I'm actually not even sure that auto LOD even makes sense for an orthographic camera. Might be worth just having it not be taken into account during rendering when an orthographic camera is used.

@TokageItLab
Copy link
Member Author

TokageItLab commented Jan 29, 2022

We may need to consider the effect not only on Automatioc LOD, but also on the MSFT_LOD that glTF has.

@Calinou
Copy link
Member

Calinou commented Jan 29, 2022

I'm actually not even sure that auto LOD even makes sense for an orthographic camera. Might be worth just having it not be taken into account during rendering when an orthographic camera is used.

Automatic LOD calculations could be made to work with an orthogonal camera, but it would have to be based on the effective screen size occupied by the object rather than distance. This is in fact how it works in perspective mode already, but I suppose the calculation is broken in orthogonal mode.

In general, orthographic cameras require different distance formulas for shaders and other effects to still look correct.

@orosmatthew
Copy link
Contributor

orosmatthew commented Jan 29, 2022

Right now, there isn't any differentiation in the code with perspective and orthogonal cameras. It just looks like it's based on distance, which inherently is proportional to screen size in perspective but not in orthogonal. I tried just disabling auto LOD in orthogonal and it does "fix" the issue now if I were to submit a PR, but it might just be better to recalculate how auto LOD is determined with screen size instead.

Edit: nvm, it does look like it does take screen space into account, but also distance. I will experiment but maybe ignoring distance in an orthographic camera and only taking into account screen space is the right way to go

@Calinou
Copy link
Member

Calinou commented Jan 29, 2022

See also #54885.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants