Thorsten wrote in Thu Sep 20, 2018 5:38 am:Mostly the scenery developer rise the line meshes (ca. 10cm).
Mostly they do not (because these lines are real geometry and wold be an obstacle for taxiing) - it would appear that rarely some lines are raised in the mesh (never seen one myself) from the reports - if that is, it is by accident and not by design.The scenery developer dont need to rise the meshes of paintings.
And in fact they do not (I wonder if you realize at all that these lines are created automatically by TerraGear from airport description data).
In fact they DO. Look at the pictures below.
Nosewheel on ground:
Nosewheel on taxiline:
And yes, the lines are obstacles and the airplane bumps up and down everytime you cross the line.
On a quick search I found this airports with raised taxilines:
NFTF
NFFN
NVSS
NWWX
NWWW
And there are many more out there.
If you wish, i will report every airport if i found others.
Thorsten wrote in Thu Sep 20, 2018 5:38 am:But if you switch to a external view and look extremly flat over the ground, you notice that the lines are above the ground.
Let's try this again:
What you see on the screen is what the shader code renders, not what the underlyinh geometry is. That's different, because a vertex shader can displace things on the screen, a geometry shader can create new mesh parts, but the collision detection operates on the un-displaced original mesh. The taxiline flickering is addressed by such a fix - the line is displaced on the screen, but the geometry is still flat for collision detection.
In fact, the line is displaced based on your distance to it, so from the near-zone, it isn't much displaced at all, only when you're 100 meters away and the z-accuracy drops, it is moved more and more towards you.
That's the second advantage of a renderer-based fix over hard-coding this in the scenery mesh - you can dynamically react to the situation,
The shader displace the line to avoid z-fighting, thats okay and I can clearly see that in the second picture where i stay on the line.
In my opinion its a little bit too high in a very near closeup, but okay.
Thorsten wrote in Thu Sep 20, 2018 5:38 am:All textures (mostly alpha) that are used to paint on pavement (lines, numbers, signs, etc...) should have a priority higher than 0.
Why don't you look into how FG creates and textures a runway first and then explain us how it's done and what should be done?
I dont code in C++ and that was only loud thinking how to address the z-fighting.
Thorsten wrote in Thu Sep 20, 2018 5:38 am:So, if 2 or more textures have the same value in the z-buffer, the textures will be rendered in ascending order of the priority.
1) Textures have no value in the z-buffer, fragments have
2) Multiple textures are drawn on fragments as the fragment shader code says, not based on mysterious priorities
I have never code in OpenGL but i have a little understanding how the rendering work. It doesnt matter if we name it texture or fragment, the point is if the fragment has a priority in the sortorder of the fragment shader, you can also address the z-fighting.
I have a render engine in mind they work with priority, but i cant remember what engine that was.
I found only the same behavior like yours in the idTech3 engine.
http://q3map2.robotrenegade.com/docs/shader_manual/general-directives.html#polygonOffset
But this engine show the fragment not so high like FG. In fact, i can not see a distance between the ground and the second teture on top of it.