Dyn 3284 depthbias #11400
Dyn 3284 depthbias #11400
Conversation
set depth bias high for non selected geometry
set depth bias for meshes on selection and deselection do not push verts along normals
sm6srw
left a comment
There was a problem hiding this comment.
Great, looks like a simplification to me. One small thing then LGTM!
| internal const double DefaultFarClipDistance = 100000; | ||
| private const int DepthBiasVertexColors = 10; | ||
| private const int DepthBiasNormalMesh = 100; | ||
| private const int DepthBiasSelectedMesh = 0; |
There was a problem hiding this comment.
Just curious how you ended up with these numbers? Maybe worth a comment?
There was a problem hiding this comment.
Are they the same as the old shader implementation?
There was a problem hiding this comment.
I didn't reference the old shader, but I can look - I vaguely remember both depth bias and nudging were used.
The docs for depth-bias describe that the numbers can be interpreted multiple ways depending on the format of the depth buffer - I tried to find values that would work in either case. See the link above.
There was a problem hiding this comment.
to me - it looks like helix uses a 32bit depth buffer (and 8 bit stencil buffer) -
| DXGI_FORMAT_D32_FLOAT_S8X24_UINT | A 32-bit floating-point component, and two unsigned-integer components (with an additional 32 bits). This format supports 32-bit depth, 8-bit stencil, and 24 bits are unused.⁵ |
|---|
which means the value is scaled by 1/(2^32), something like:
Example: DepthBias = 100 ==> Actual DepthBias = 100/2^32 = .0000003
very small changes in depth.
There was a problem hiding this comment.
Could you explain the difference between VertexColors and NormalMesh and why they require different depth biases?
There was a problem hiding this comment.
@aparajit-pratap - imagine the case where you have two spheres at the same position, with the same radius. One was created by the ByGeometryColor node - IMO the preferred behavior is that the colored sphere appears on top of the non colored sphere.
Today this doesn't work because most DynamoModelGeometry3d objects have vertex colors (white ones, contributing no color) - I'm not sure why. When we address that this will ensure that objects with vertex colors are drawn on top of geometry without colors)
src/DynamoCoreWpf/ViewModels/Watch3D/shaderSource/vsDynamoMesh.hlsl
Outdated
Show resolved
Hide resolved
add test
Purpose
This PR removes vertex nudging in the vertex shader - this nudging was done for vertex colored geometry and selected geometry.
It never worked well for vertex colors because for some unknown reason all geometry has vertex colors.
It kind of wokrked for selected geometry, but for small geometry the nudging could actually make the geometry appear exploded when selected.
This PR instead uses depthBias https://docs.microsoft.com/en-us/windows/win32/direct3d11/d3d10-graphics-programming-guide-output-merger-stage-depth-bias which is for controlling which of two coplanar polygons will appear in front by nudging not the verts, but their positions in the depth buffer. We don't lose early z or other perf tricks with this like we would with writing to the depth buffer ourselves.
logic is as follows:
when a mesh is created we assign a depth bias depending on if the render package marks the mesh for vertex colors or not.
Later when the mesh is selected, we set the depth bias to 0, so it renders in front of everything else, then when unselected we set the values back to the defaults which were used at construction time.
In my manual tests it seems to work pretty well, vertex color geometry is still hit or miss because of the long standing issue that all geometry has vertex colors, but selection highlight seems robust.
TODO
Declarations
Check these if you believe they are true
*.resxfiles