I have a large triangle strip making a ring 0.1 units above a larger TCastlePlane. They interfere. I have set the scene’s sorting order to bs3DGround. I don’t have this issue with the roads in my world, because they are small compared to the terrain, but here they are almost same size and I guess it is having a hard time sorting them? I thought I remember there being a way to simply force the terrain to the back, which is safe here flat. But not finding that now.
Hmm, I thought I found it with setting the plane’s RenderLayer to rlBack… but it didn’t help.
-
As for
RenderLayer
: actually the default is “back”, see Castle Game Engine: CastleTransform: Class TCastleTransform . So to make it useful, you’d actually want to set road (or everything except the terrain) torlFront
.That said, I am unsure if this is what you want – things with
rlFront
are really always rendered in front, from all camera angles, even if they are obviously much much far in the back when looking at 3D distances. -
As for blending sorting: You can set
BlendingSort
tosortCustom
and then assignOnCustomShapeSort
. See Castle Game Engine: CastleViewport: Class TCastleViewport and our blending docs: Blending (Rendering Partially-Transparent Objects) | Manual | Castle Game Engine . On I found the forum thread where I mentioned it too – Background water texture modifying foreground leaves in tree .That said, from your description it is not sure if “wrong blending sorting” is your problem.
-
Your screenshot seems to show regular Z-fighting. This just happens because the Z-buffer precision is limited.
If so, exploring AD 1 or AD 2 will not really be useful for you
The solutions to Z-fighting:
-
Make the distance larger than 0.1. The Z-buffer precision is just not good enough to reliably compare small numbers when the distance from them to the camera is very large.
-
And/or increase the camera
ProjectionNear
. Increasing theProjectionNear
generally drastically improves the Z-buffer precision, and when you have a big world, you can probably increase it a lot without losing anything – I assume you do not put camera “very very close” to your objects. -
And/or increase the camera
ProjectionFar
. By default we use a special matrix which actually makes it infinite (there’s math proving that it doesn’t really cause a significant loss in normal cases).
Out of these 3 advises, increasing the
ProjectionNear
(if you can) will fix your issue quickest, probably. IncreasingProjectionNear
has a big positive effect on precision. -
Thank you. Using ProjectionNear := 10
solves the z-fighting without increasing the height of the mesh. Good to know the term for that now too.