[2.1] Strange behaviour in intersections of meshes Topic is solved

[gabbsson]

Ogre Version: 2.1
Operating System: Ubuntu
Render System: OpenGL

Hello!

I'm having an issue where to meshes that intersect have trouble deciding whats on top.
This picture should explain what the problem is:

The intersection should be a smooth line, not look as if they are melting together.

I'll keep looking for the cause, but I'd appreciate any help that would speed up solving the issue.

Cheers!

[xrgo]

What's your near and far camera clipping distances?
Could be a precision problem

[gabbsson]

What's your near and far camera clipping distances?
Could be a precision problem

I was using:

Far 1000
Near 0.1

I changed it to 500 and 1 and its gone so you were correct! Thanks a ton for the quick response.

May I follow up with something; what are good values for near and far clip? Is there a rule of thumb for selecting them?

Edit:

Just for my own understanding, the near and far clip decide the precision of (z?)-depth? I kept experimenting and realized the less extreme clip distances I have the closer objects can be without acting strange (what looks like z-fighting)?

[dark_sylinc]

The near clip plane has a much more profound effect on the Z precision. This is because, unfortunately, the range [0;0.5] is occupied by [near; near*2.0]

In other words, more than half(*) of the available precision is dedicated to [near; near*2.0] which is absolutely overkill, and the rest of the precision is dedicated to [near *2.0; far).

So when you increase the near plane, you gain a ton of precision on things that are close to the camera.
Reducing the range between near and far also helps, obviously.

(*)It's more than half because of ]how floating point works (the link is for half floating point, but it perfectly applies to 32-bit floating point as well, just with higher precision).

Reverse Z was implemented in Ogre 2.2 and helps a lot with this issue, because it reverses the range: The range [0.5; 1.0] is occupied by [near *2.0; near], which means less than half of the available precision is dedicated to the often-most useless part.