[BUG] Inconsistent sign + inaccuracy in SDF computation

[ehsanhaghighat]

Bug Description

Hi Team,

We have a pipeline that relies on accurate SDF inputs, previously computed using Open3D. Before choosing Open3D, I extensively tested all available open-source options and I found Open3D implementation as the most robust (to mesh issues) and most accurate implementations. I tested on sampled data from ABC datasets.

I recently tested warp for such a computation. I did observe a significant speed up over open3d, but I also found inconsistent results. I tested mesh_query_point, mesh_query_point_sign_normal and mesh_query_point_sign_winding_number. Here are a few images of SDF evaluated on random geometries:

Note: Colors are selected such that inside (-) is blue, outside (+) is red, and zero-levelset is white. Parts are centered around their centroid and scaled to fit in cube of dimensions [-1,1]^3. SDF1, SDF2, SDF3 are computed on XY, XZ, YZ planes passing through the part's centroid. FACE1 is a depth field, outside the unit cube, computed using mesh_query_ray.

Random sign change:

vs

Unexpected artifacts:

Not recognizing inside and outside correctly:

One last example:

It would be great to add some unit tests based on Open3D outputs.

System Information

No response

[shi-eric]

Thank you @ehsanhaghighat for the detailed bug report. @AnkaChan will look into this issue. It might help to provide links to the assets you used for the figures.

[AnkaChan]

Hi ehsanhaghighat, thank you for reporting this. However, from you figure I cannot easily tell what wrong. Can you highlight the parts that is wrong? Can you be more descriptive about the errors and artifacts?