move near clipping plane further away for more depth buffer precision.

[mjkkirschner]

Purpose

An issue stemming from this change:
#12607
reported here:
https://forum.dynamobim.com/t/edges-preview-issue-why-do-the-edges-look-like-this-in-the-new-version-of-dynamo/81229

The artifact that is shown is that edges of the surfaces which should be hidden are being drawn as if they are on top of the surfaces in front of them.

While testing this I noticed that the effect was worse the further the geometry was from the camera (as we zoomed out).
My guess is that the depth buffer is not as precise far from the near plane, especially as our near and far plane are calculated dynamically as the camera moves.

As we introduce depth bias, those changes, while small near the near plane, become larger as precision decreases at the far plane.

I believe this article confirms my hypothesis:
https://developer.nvidia.com/content/depth-precision-visualized

okay so - some options:

1. implement this reversed depth buffer approach mentioned in the article - I don't believe helix supports this so we'd need to do a bunch of work there, and likely in our shaders as well.
2. this PR - simply moves the near plane further out (by a factor of 10) - we get a bit more precision, but we still keep the near plane in front of any geometry.
3. reduce our depth buffer biases - this will yield more z-fighting in general, but can probably still be made to work for selected geometry.

This PR goes with 2.

It seems to work for current issue at hand reducing most of the artifacting lines, and it also still works for the TSplines example we fixed in the previous PR that introduced this issue.

some before and after images:

Declarations

Check these if you believe they are true

• The codebase is in a better state after this PR
• Is documented according to the standards
• The level of testing this PR includes is appropriate
• User facing strings, if any, are extracted into *.resx files
• All tests pass using the self-service CI.
• Snapshot of UI changes, if any.
• Changes to the API follow Semantic Versioning and are documented in the API Changes document.
• This PR modifies some build requirements and the readme is updated

Release Notes

Attempted to improve rendering of curves that should be hidden by meshes when geometry is far from camera.

Reviewers

(FILL ME IN) Reviewer 1 (If possible, assign the Reviewer for the PR)

(FILL ME IN, optional) Any additional notes to reviewers or testers.

FYIs

(FILL ME IN, Optional) Names of anyone else you wish to be notified of

[pinzart90]

LGTM, I guess adding a test for this is way too hard (unless we do image analysis/comparison)
Maybe we can add a separate jira task to analyze solutions for the most common z fighting/depth buffer issues that users might come across .

[mjkkirschner]

LGTM, I guess adding a test for this is way too hard (unless we do image analysis) Maybe we can add a separate jira task to analyze solutions for the most common z fighting/depth buffer issues that users might come across .

We actually have image comparison tests! Unfortunately to keep them stable between graphics cards and different machines we needed to add quite a big fuzz factor :( - we could revisit that at some point as well.

[pinzart90]

@mjkkirschner do you think there might be any performance implications for this change ?

[mjkkirschner]

@mjkkirschner do you think there might be any performance implications for this change ?

I think the GPU in modern graphics libraries (dx11 > etc) will not render multiple pixels at the same location if the depth of the new pixel is greater than something already in the depth buffer - but I cannot remember exactly. If thats true, than performance should be the same...

[aparajit-pratap]

Are these near plane and far plane constants that you're playing with in this PR the a and b values in that depth bias equation?

[mjkkirschner]

Are these near plane and far plane constants that you're playing with in this PR the a and b values in that depth bias equation?

The equation in the article that includes a and b is not a depth bias equation - but the depth equation from the world z... so yes and no, the a and b are definitely related to the near and far plane in that equation, but d is not depth bias, but depth. (the value in the buffer)

depth bias has its own horrible equation depending on what format the buffer is in - Helix appears to use a 32bit float depth buffer.

[aparajit-pratap]

I'm not sure I understand - you say that the near and far plane distances are calculated dynamically depending on the camera position. If that's the case, then what is this constant value?
nearPlaneDistanceFactor

In any case, don't let my questions prevent you from merging this PR.

[mjkkirschner]

@aparajit-pratap as one moves the camera, or zooms we do this:
near = closest.AlmostEqualTo(0, EqualityTolerance) ? DefaultNearClipDistance : Math.Max(DefaultNearClipDistance, closest * nearPlaneDistanceFactor);

in most cases this boils down to:
distance to closest model object * nearPlaneDistanceFactor: the smaller the factor is the nearer to zero the near plane will be, and the less precision we will have in the depth buffer.