Keeping trianglestrip from interferring with plane?

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.

  1. 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) to rlFront.

    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.

  2. As for blending sorting: You can set BlendingSort to sortCustom and then assign OnCustomShapeSort. 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.

  3. 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 :slight_smile:

    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 the ProjectionNear 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. Increasing ProjectionNear has a big positive effect on precision.

1 Like

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.

1 Like