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
Add setting for near plane distance. #6395
Conversation
builtin/settingtypes.txt
Outdated
@@ -532,6 +532,9 @@ pause_fps_max (FPS in pause menu) int 20 | |||
# View distance in nodes. | |||
viewing_range (Viewing range) int 100 20 4000 | |||
|
|||
# Near plane distance in nodes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe add a note here that you should usually not need to change this value + the example you mentioned (=0.25 on mobile devices)
Interesting, might be useful for other reasons, but cheap devices will not be using 'active block range' that large, because that also vastly increases ABM load which is already heavy. |
It fixes quite a few problems on these weaker devices. For comparison here is fairly large entity drawn with the default active block range. The large green area is supposed be a PCB, and the black box is a cube "chip" on top of it. Here are renderings from an Raspberry Pi 3 at near plane 0.1 vs 0.25. Notice how the cube gets a weird bottom edge with the default near plane. |
Ok useful. |
There should be a limit. Too large values can be used for x-ray vision. And non-positive values are invalid. |
src/camera.cpp
Outdated
@@ -551,7 +551,7 @@ void Camera::updateViewingRange() | |||
f32 viewing_range = g_settings->getFloat("viewing_range"); | |||
f32 near_plane = g_settings->getFloat("near_plane"); | |||
m_draw_control.wanted_range = viewing_range; | |||
m_cameranode->setNearValue(near_plane * BS); | |||
m_cameranode->setNearValue(MYMIN(MYMAX(0, near_plane), 0.5) * BS); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have functions for this, either rangelim(near_plane, 0.0f, 0.5f)
or maybe std::clamp(...)
not sure which.
Either way please state as floats with a 'f'.
- Add more details to near_plane setting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* Allow setting the near plane * - Add near_plane limit of 0.5 to prevent x-ray. - Add more details to near_plane setting.
* Allow setting the near plane * - Add near_plane limit of 0.5 to prevent x-ray. - Add more details to near_plane setting.
* Allow setting the near plane * - Add near_plane limit of 0.5 to prevent x-ray. - Add more details to near_plane setting.
* Allow setting the near plane * - Add near_plane limit of 0.5 to prevent x-ray. - Add more details to near_plane setting.
* Allow setting the near plane * - Add near_plane limit of 0.5 to prevent x-ray. - Add more details to near_plane setting.
* Allow setting the near plane * - Add near_plane limit of 0.5 to prevent x-ray. - Add more details to near_plane setting.
* Allow setting the near plane * - Add near_plane limit of 0.5 to prevent x-ray. - Add more details to near_plane setting.
* Allow setting the near plane * - Add near_plane limit of 0.5 to prevent x-ray. - Add more details to near_plane setting.
* Allow setting the near plane * - Add near_plane limit of 0.5 to prevent x-ray. - Add more details to near_plane setting.
* Allow setting the near plane * - Add near_plane limit of 0.5 to prevent x-ray. - Add more details to near_plane setting.
One weaker GPUs, such as the ones found in cheap tablets, you can sometimes see z-fighting between entities even when they are 1 node apart at larger distances ~200 nodes. (Granted I had increased the active_block_range before this happened). This may be because they are using 16 bit depth buffers, but I'm not sure on the exact cause.
Setting the near plane to 2.5 (0.25 blocks) fixed this for me by pushing out some of the depth buffer accuracy toward farther away objects. The only down side of this I have found is when in no-clip mode, objects clip a little sooner.