SDF: Continued discussions

[noblegmr]

Following up on my previous post about SDFs (Signed Distance Fields) in PhysX, I'd like to discuss some challenges we've encountered while implementing them in our stack.

Dense SDF Resolution Issues

Breaking Point at Fine Resolutions

We've discovered that Dense SDFs exhibit problematic behavior when the spacing resolution goes below 0.005m. Specifically, we're seeing inaccurate distance values in regions where they should be positive (greater than 0). For comparison, I've attached visualizations showing SDF behavior at:

• 0.01m spacing (expected behavior)
  
• 0.005m spacing (showing artifacts)
  

In these visualizations, we're only displaying the zero-value isosurface (the surface of our meshes). We're trying to understand the root cause of this degradation and potential solutions.

Surface Value Inconsistencies

When examining values near mesh surfaces in our Dense SDF (at 0.01m spacing), we've observed inconsistent distance measurements. Points that should be equidistant from the surface can show variations of up to 1cm. We're looking for approaches to improve this precision.

Questions About Sparse SDFs

We're also seeking clarification about SDFs in the isaac simulator:

1. Are the SDFs we generate and visualize in the simulator Sparse SDFs?
2. If so, what parameters control their density?

I've attached a visualization from the ISAAC simulator for reference.

Any insights into these issues would be greatly appreciated, particularly regarding:

• The resolution limitation in Dense SDFs
• Methods to improve near-surface accuracy
• Understanding and controlling Sparse SDF parameters.

[nvtw]

Hello

About the artifacts you observe when using dense sdfs at high resolution:
Dense SDFs are not recommended due to their huge memory footprint. If I remember correctly, the max resolution along an sdf dimension (x, y or z) is capped at 1250. The reason is that signed integers start to overflow for larger dimensions because 1250^3 is already close to the limit number a signed integer can represent. I cannot answer the source of the artefacts you're seeing. If your meshes are watertight and correctly oriented, then this should not happen. I would be grateful if you could provide data such that we can reproduce and fix the issue.

Surface Value Inconsistencies:
I can try to reproduce the issue, having data that helps to reproduce it would be great. We might have a bug during SDF calculation. Dense SDFs use a cell centered grid while sparse SDFs use a corner centered grid for compression reasons. We had bugs in the past where the shared SDF construction code accidentially used sample points half a cell size off due to the different alginments of dense and sparse sdfs. Do you observe inconsistent suface vaues with sparse SDFs as well?

Questions About Sparse SDFs:

1. When you set a subgrid resolution > 0, then a sparse sdf will be used. The debug view will still show all samples as with a dense sdf but the underlying representation will be sparse. Please note that a sparse sdf can provide distance values everywhere in the object's bounding box but the distance values are far more accurate close to the mesh's surface than they are further away. This is ok since contact points will be on the mesh's surface.
2. The density of a sparse sdf is controlled by the sdf cell size (having a resolution parameter would be more intuitive to be honest). The resolution is the number of cells along the longest axis aligned bounding box axis and it's computed as longestAABBAxis/sdfCellSize. Sparse sdfs are then compressed into blocks. The block size is controlled through the subgrid size. 6 leads to a good compression. Smaller subgrid sizes lead to more addressing data needed. Larger subgrid sizes lead to less sparsity and more memory consumption. 6 is in many cases the sweet spot. Please have a look at the SDF snippet that is shipped with the PhysX SDK.
3. If the near surface accuracy needs to be high a certian distance away from the actual mesh surface for sparse sdfs, then increase the narrow band thickness. The narrow band is an offset applied inwards and outwards of the mesh surface. Every sparse grid cell that overlaps the narrow band will be kept. Sparse grid cells that don't overlap the narrow band won't get stored. You still get distance information there but it's less accurate.

Please let me know if I should provide c++ or python code about how to set certain parameters. I think you can find all you need in the SDF snippet that comes with the PhysX SDK but maybe further explanations are required.

Hope that helps

[noblegmr]

Hi @nvtw !

Thank you for your detailed response regarding the SDF implementation. I have some follow-up questions and observations based on your explanations.

Regarding Dense SDF Artifacts:
I understand the current limitation with signed integers causing the 1250³ resolution cap. However, I'm curious about why signed integers were chosen over unsigned integers, which would allow for higher resolution values? I've attached the watertight mesh where we observed value degradation of ≤ 0.005m (in an email chain separated from this thread).

Surface Value Inconsistencies:
For the inconsistent surface values you mentioned, I've attached the specific SDF (in an email chain separated from this thread) where we observed these inconsistencies, particularly near the triangular regions in the STL. We haven't tested this with sparse SDFs yet, as we're currently only using dense SDFs in our software stack.

Questions about Sparse SDFs:

1. We still have some confusion about how the subgrid size works in practice. Does it reduce the number of sampling points within each block and then approximate the distance value when a query point falls within that block?

2. Given the 1250³ resolution limitation, is it possible to achieve sub-centimeter resolution (ideally around 1mm) near the STL surface using sparse SDFs? Our attempts to create sparse SDFs at this resolution have been unsuccessful so far.

3. Regarding the narrow band thickness: We've experimented with this in Isaac Sim, and the default values worked well for our needs, as our primary focus is increasing near-surface resolution (from 1cm to 1mm).

The PhysX SDK examples have been extremely helpful in our implementation. Could you please point us to the specific query function we should use for sparse SDFs?

Thank you!

[nvtw]

Having a higher limit with an unsigned int would work but we don't encurage that high resolution dense or sparse sdfs. Signed integers allow for sdfs up to 2GB of memory. Many common GPUs could only hold around 8 sdfs of such a high resolution wich is not really a lot. SDFs were integrated into PhysX for challenging collision scenarios of small to medium sized objects. Very large object should get split into smaller objects or use different colliders (e. g. the triangle collider which can handle full, static game level meshes).

Sparse sdfs have a list of sparse blocks and a background sdf. The background sdf is dense and has the resolution fullSDFRes/subgridSize. So if you subgrid size is 6, then the background sdf has 6^3=216 times less samples than a full resolution dense sdf. Now every cell in that low res background sdf is checked for overlap with the triangle mesh sufrace narrow band. If they overlap, 6x6x6 (or whatever your subgrid resolution is) block gets stored into the list of subgrid blocks. This allows to get rough distance values everywhere and accurate distance values near the surface. Notice that subgrid blocks in perfectly flat areas are also not stored because the background sdf can perfectly capture the sdf of flat surfaces.

The sdf can be as accurate as roughly half the cell size. If a sample point is near two surfaces, it will store the distance to the closer surface, that's the approximation that has to me made. Also notice that SDFs were introduced for collision scenarios, more advanced use of them is possible but not officially supported. The PxScene has a function called evaluateSDFDistances which allows to query interpolated distances and approximated gradients for a list of sample points (batched API).

The following screenshot shows the subgrid blocks stored for a lego brick sdf (one cross section). Black regions still have a background sdf but samples are only available on the corners of subgrid blocks. This strategy allows to use fast addressing and hardware accelerated trilinear interpolation.

[noblegmr]

Hey @nvtw!

Thanks so much for your help earlier! I've been diving deeper into our SDF implementation and wanted to share some interesting findings & concerns about the SDF values we're generating, especially near the surface of our STL objects.

What We're Seeing

We're noticing some inconsistent behavior with our SDF values, particularly when we get close to object surfaces. These little discrepandies are causing our collision detection to behave in unexpected ways.

Context & Usage

In our implementation:

• We use a sphere (defined by center and radius) to interact with objects
• The center of the sphere is used to query the SDF value
• We subtract the radius from this value to determine distance from any object

As you can see in the first image, even when our tool sphere is clearly not touching the part, the SDF value is telling us there's a collision. The SDF value at that point is 7.37 cm, but our radius is 8.5 cm (visualized as 0.085 m). and hence the distance value is calculated to be -1.12.

Our Current Setup

We're running with Dense SDFs at a resolution of 1cm (0.01 meters). Here's the configuration we're using:

"SDF_Params:"
    "spacing": 0.01,
    "subgridSize": 0,
    "numThreadsForSdfConstruction": 20,
    "bitsPerSubgridPixel": 8

All other parameters are at default values.

Additional Observations

Inconsistent Distance Values

This visualization shows that points equidistant from the surface vary significantly in their SDF values (ranging from 6-8cm).

Surface Point Verification

When visualizing all points with SDF values less than 0.1cm, only points below the surface satisfy this condition, while we would expect points both above and below the surface.

Attachments

1. The STL file used to generate this SDF : SDF_test.zip

2. A list of sphere center positions visualized in the final image: collision_points_radius.json

I'd love to hear your thoughts on what might be causing these quirks in our SDF values! Perhaps we're missing something obvious, or maybe there's a setting we could tweak to get more consistent results?

Additionally is it possible for the team to provide some code to query a sparse SDF that we generate? I was able to create a sparse SDF thanks to the snippets but I could not find much on querying the SDF

Looking forward to your insights, and thanks again for your help with this!

[nvtw]

Hello,
I had a look at the meshes in SDF_test.zip and they do look problematic. Keep in mind that the PhysX SDK SDFs are developed to represent physical objects. To properly represent a physical object with a triangle mesh, the triangle mesh must fully enclose the object's volume meaning there are

• No holes in the mesh (watertight)
• No self intersection (the mesh should be manifold)
• Consistent triangle orientation/winding (normals of adjacent triangles point into consistent directions)

The sdf code in PhysX can handle violations of the above properties to some degree but the meshes in SDF_test.zip are too convoluted. S in SDF stands for Signed, so the SDF code always tries to separate the inside of the object (negative SDF values) from the outside. But with a sheet-like triangle mesh with inconsistent triangle winding, it has no chance to distinguish inside and outside reliably. The SDF it computes will not be correct at all. A mesh with consistent triangle orientation would appear nicely shaded in the screenshot below.

The documentation could be clearer about desired properties of triangle meshes for SDF generation but you can find inormation here:
https://docs.omniverse.nvidia.com/extensions/latest/ext_physics/rigid-bodies.html#physx-short-sdf-collision
and here:
https://nvidia-omniverse.github.io/PhysX/physx/5.5.1/docs/RigidBodyCollision.html#dynamic-triangle-meshes-with-sdfs

[noblegmr]

Hi @nvtw,

Thank you for your reply and clarification!

I've implemented several techniques to convert our pointclouds and meshes into watertight, manifold versions, then re-attempted querying the SDFs—unfortunately encountering the same inconsistency issues. I also tested with a pre-verified watertight and manifold mesh from GrabCAD, which produced identical problems.

I've attached screenshots for your reference. interestingly, we've noticed this issue only occurs when the surface begins to slant at a certain angle (as shown in the attached image), we've seen this behavior closer to the SDF surface for both non-watertight and water-tight meshes Do you have any insights on what might cause these SDF calculation errors?

I'm also attaching the zip file containing the mesh shown here. the SDF settings are the same as in the previous reply.
manifoldMesh.stl.zip

[nvtw]

Could you provide source code to reproduce the issue? The simplest way is usually to modify the SDF snippet source code and then share the modified cpp here.
Also in case you just need distance information and don't need to rely on inside/outside information, consider using the ClosestDistanceToTrimeshTraversalController together with the TinyBVH. An example of how to use it can be found in the method PxDeformableSkinningExt::initializeInterpolatedVertices in file ExtDeformableSkinning.cpp. This method does not rely on SDFs and is still fast (but not as fast as SDFs). But the distances should be very accurate whereas SDFs use approximations.