Closed Desour closed 1 year ago
This is not perfect. :slightly_frowning_face:
It can never be perfect, not until Minetest allows directly compositing arbitrary text onto the surface of a node. Just go with ±0.42 to be safe.
±0.42 isn't good enough either. Even ±0.4 (the old value) isn't. At the world edge, the text ends up in the nodebox after rejoining, sometimes at least.
Edit: I can't reproduce anymore. ¯\_(ツ)_/¯
I thought that world-edge issue was fixed already (it used to badly affect mesecons and other nodeboxes)?
Fwiw, signs_lib
uses this on its wall signs, which are comparable, if a bit thicker than an LCD:
https://gitlab.com/VanessaE/signs_lib/blob/master/init.lua#L92-107
signs_lib.regular_wall_sign_model = {
nodebox = {
type = "wallmounted",
wall_side = { -0.5, -0.25, -0.4375, -0.4375, 0.375, 0.4375 },
wall_bottom = { -0.4375, -0.5, -0.25, 0.4375, -0.4375, 0.375 },
wall_top = { -0.4375, 0.4375, -0.375, 0.4375, 0.5, 0.25 }
},
textpos = {
nil,
nil,
{delta = { x = 0.41, y = 0.07, z = 0 }, yaw = math.pi / -2},
{delta = { x = -0.41, y = 0.07, z = 0 }, yaw = math.pi / 2},
{delta = { x = 0, y = 0.07, z = 0.41 }, yaw = 0},
{delta = { x = 0, y = 0.07, z = -0.41 }, yaw = math.pi},
}
}
I haven't heard/seen any complaints...
Screenshots removed, they only showed problems arisen by mipmapping.
signs_lib
seems to use ±0.41.
I've changed the number to 0.42
, 42 is a good number.
Well it IS the answer to life, the universe, and everything. :smile:
(The most reliable fix might be to make the front face of the node transparent and adding the face instead as the entities texture. And the loading problems could be fixed by making the text object non-static. Anyway, this little PR's fix here should be fine enough.)
Making the LCD surface a part of the text entity would prevent the use of texture packs.
Better to yell at MT devs here: https://github.com/minetest/minetest/issues/1367
17.5mm (7/16−0.42) is too far. It’s barely noticeable currently, but to fix problems mipmapping causes (see #58), background is needed in the entity, not in the nodebox, so the gap will be visible: Try 2.5mm gap (0.435 offset), that should be enough remembering 1mm serialization precision (that’s V3F1000...). If not... ugh, 0.43?
remembering 1mm serialization precision
Plus floating point inaccuracies at high values, so the situation gets worse the further away from the origin you go.
Since 5.0.0 this should no longer be an issue. Can anyone confirm whether it's fixed now?
@SmallJoker thats not fixed
I retested with a distance of 0.43 and could not get any Z-fighting with this value.
Committed as 9c2b980
Fixes #56.
Z-fighting is more rare.