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.