Z-Order Fighting/Flickering for Billboards spaced far apart

[najak3d]

I'm experiencing Z-order fighting among 3D world space billboards which have about z-distance of 30 between each other, and my camera is only about 500 units from them -- yet the billboard further away has UI elements showing through. (see image, red circle)

I haven't mucked at all with Z-Index -- and confirmed that all Z-Index values are 0.

To be explicit, inside the red circle, the bright green bar at the left side is the bar from the "Infantry" unit in the back, and it's occluding the billboard in the front.

[dkonik]

We haven't been able to reproduce the issue you're describing with the parameters you mentioned, but given how Nova handles render order, we do believe you could be hitting an issue/limitation. So a couple of suggestions as well as follow up questions:

• How far is your camera and content from the world-space origin? The closer everything is to zero, the better. So, for example, if you have a camera panning capability in your game and the camera can move large distances, often the recommendation is to move the world rather than move the camera (this technique has a few different names, World Origin Shifting or Floating Origin, but you can read more about it here: https://manuel-rauber.com/2022/04/06/floating-origin-in-unity/).
• One thing you could try is changing is the DrawCallDistanceAdjustmentRatio value in Constants.cs. In your case, you would want to increase to make it closer to 1 (so you could try .9995f, or maybe .9999f). Increasing it too much will result in other rendering artifacts, but if you find a value that works well in your scenario, we could expose the ability to change this value as a setting.

[dkonik]

Thanks for sending the sample project. We're able to reproduce the issue, and we believe we know the root cause. We're actively working on a fix, but unfortunately it likely won't be a one-liner. We may send you a patch after we have something, both to unblock you as well as to help us validate if it resolves the problem. We'll keep you updated!

[najak3d]

I'm glad to see that we picked the "right horse to attach our cart" for UI.

I would be honored to validate your fixes. But wanted to note for you that this is not a rush for us -- it's not "blocking us" as it's just a sporadic visual defect, that doesn't stop the rest of our development. Mainly, we just needed to know that this issue was acknowledged and in the queue to be fixed in the next few months.

If you ever want to lean on me for debugging, I would be honored to do so. The way I see it, in exchange for the honor of seeing your source code, I would like to provide for you at least one bug fix, for the benefit of everyone using Nova UI.

[dkonik]

After spending quite some time working on the fix for this, we realized that there is in fact a simple work around that should unblock you: modify the if statement on line 327 of CameraSortRunner.cs to use (.99f * setToCheckInfo.Distances.MinDistance) instead of just setToCheckInfo.Distances.MinDistance so that the full if statement looks like:

if ((.99f * setToCheckInfo.Distances.MinDistance) > perCameraSetInfo.Distances.MaxDistance &&
    !Math.ApproximatelyEqual(setToCheckInfo.Distances.MinDistance, perCameraSetInfo.Distances.MaxDistance))
{
    // We've checked all elements with overlapping min/max, so break
    break;
}

.99f should be enough, but if you continue to see issues in certain situations you can decrease the number, e.g. you could try .98f. While there should not be any side effects of decreasing this number (other than a small amount of unnecessary checks/calculations), we can't imagine that you would ever need to go much lower than that.

While this is just a workaround and not necessarily a "proper" fix, the full fix is much larger and we'll need to do a lot of testing and validation on our end to make sure we are not introducing any bugs. But in the meantime, this should be sufficient.

[najak3d]

Yep, 0.98f worked (while 0.99 partly worked, but defect was still too frequent). Thank you for this workaround!

[dkonik]

This workaround has been included in version 2.1.3!