LCD Z-fighting about digilines

[Desour]

Related: #40

I can reproduce z-fighting (without reloading the object) very far away (at 30000).

[numberZero]

From #40:

this should ideally be tested on various gfx cards.

So 0.5mm appears to be too near.

digilines/lcd.lua

Lines 23 to 33 in 2d2e778

	local lcds = {
	-- on ceiling
	--* [0] = {delta = {x = 0, y = 0.4, z = 0}, pitch = math.pi / -2},
	-- on ground
	--* [1] = {delta = {x = 0, y =-0.4, z = 0}, pitch = math.pi / 2},
	-- sides
	[2] = {delta = {x = 0.437, y = 0, z = 0}, yaw = math.pi / -2},
	[3] = {delta = {x = -0.437, y = 0, z = 0}, yaw = math.pi / 2},
	[4] = {delta = {x = 0, y = 0, z = 0.437}, yaw = 0},
	[5] = {delta = {x = 0, y = 0, z = -0.437}, yaw = math.pi},
	}

Change 0.437 to something reasonable, like 0.435 or 7/16−1/256 (current value is 7/16−1/2000, previous value was 7/16−3/80), and tell us what values look good. Z-fighting is unacceptable ofc, but large gap is unpleasant too.

[VanessaE]

Lines 111-114 in current code; https://github.com/minetest-mods/digilines/blob/master/lcd.lua#L111-L114

They do not have to be an even multiple of anything, the positions are entirely free-form.

I changed them to ±0.42. That seems to be enough to prevent Z-fighting at normal viewing distance after re-load, and it still fades away as you walk away.

I don't know if the position being wrong is the engine's fault, the mod's fault, or irrlicht's, but I'm pretty sure it'll be the same from one GPU to another.

[Desour]

#57

[Desour]

I've tested the fading away. For me (and with the PR) it happens at a distance of ca. 20 nodes from the lcd, regardless of the position in the world. I guess the reason for this is the bit-size of the depth buffer. The fading away was caused mainly by mipmapping. >_<

[Desour]

I've tested the fading away again without mipmapping and it was barely noticable. I have to admit that I'm stupid.

[numberZero]

Works for me, Minetest 5.1.0-dev-429a98964 (Linux). What are your settings? (and GPU vendor)

[VanessaE]

In the case of signs_lib, I hopefully fixed this issue once and for all today by not storing the entity statically, instead regenerating it with with an LBM, deleting any entities that may have been there at load time, before spawning a new one (there already was an LBM in place for replacing entities lost due to /clearobjects, and all entities' textures have to be fully re-rendered on-load anyways regardless of how the entity got there, so I just expanded the LBM's purpose slightly). It's fast and less error-prone than Minetest's own on-load entity handling.

https://gitlab.com/VanessaE/signs_lib/commit/4b2abfadce911c26ba14e318ee4f0a6a3b687430

This commit did the bulk of it, plus a few subsequent commits just to clean up some leftovers and fix a couple tiny bugs that it caused.

The signs' entities all use a mesh model consisting of a single rectangle (so two triangles), with the model's origin at the upper left corner of the rectangle, and the entity's origin at the node center. The rectangle is UV-mapped to fit the image, so no special offsetting or clipping of the texture is needed.

I suggest doing the same with the LCD, or perhaps it's possible to use signs_lib to generate the display? I realize I dropped support for the old 7px font during the recent rewrite, and would need to re-add it should the LCD be altered to use signs_lib, but I may just add it anyway, if only for future use somewhere...

[SmallJoker]

#57