Fix target_voxel_size Being Ignored by Texture SDF#2525
Fix target_voxel_size Being Ignored by Texture SDF#2525christophercrouzet wants to merge 1 commit into
target_voxel_size Being Ignored by Texture SDF#2525Conversation
…2524) When `SDF.create_from_mesh` (and `Mesh.build_sdf`) was called with `target_voxel_size` alone, the companion texture SDF silently fell back to `max_resolution=64`, producing a dramatically coarser secondary representation than the sparse NanoVDB grid.
📝 WalkthroughWalkthroughThis PR fixes a bug where Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
newton/_src/geometry/sdf_utils.py (1)
356-367: Dead fallback on Line 367 after the fix.With the new semantics,
effective_max_resolutionisNoneonly whentarget_voxel_sizeis provided (otherwise it'smax_resolutionor64). In that case_compute_sdf_from_shape_implignoresmax_resolutionentirely and usestarget_voxel_size, so theif effective_max_resolution is not None else 64guard on Line 367 never matters. Minor cleanup — you can just passeffective_max_resolution(the impl signature still has a non-Nonedefault) or drop the ternary for clarity.♻️ Suggested simplification
- target_voxel_size=target_voxel_size, - max_resolution=effective_max_resolution if effective_max_resolution is not None else 64, + target_voxel_size=target_voxel_size, + max_resolution=effective_max_resolution or 64,🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@newton/_src/geometry/sdf_utils.py` around lines 356 - 367, The ternary on the max_resolution argument is dead — compute effective_max_resolution may be None when target_voxel_size is used, and _compute_sdf_from_shape_impl already handles a non-None default; replace the expression "effective_max_resolution if effective_max_resolution is not None else 64" with just "effective_max_resolution" when calling _compute_sdf_from_shape_impl (update the call site that passes max_resolution and remove the unnecessary fallback).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@newton/_src/geometry/sdf_utils.py`:
- Around line 356-367: The ternary on the max_resolution argument is dead —
compute effective_max_resolution may be None when target_voxel_size is used, and
_compute_sdf_from_shape_impl already handles a non-None default; replace the
expression "effective_max_resolution if effective_max_resolution is not None
else 64" with just "effective_max_resolution" when calling
_compute_sdf_from_shape_impl (update the call site that passes max_resolution
and remove the unnecessary fallback).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: d167fde9-731f-4cb8-9188-cdd19b4f5ca5
📒 Files selected for processing (4)
CHANGELOG.mdnewton/_src/geometry/sdf_texture.pynewton/_src/geometry/sdf_utils.pynewton/tests/test_sdf_texture.py
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
This looks like a duplicate of #2464 - @christophercrouzet can you check? |
|
I wonder if we should kick out nano vdb based SDFs for collision detection (at least what the CollisionPipeline uses) completely. I kept them so far for unit testing the new(er) texture based SDF against the nano vdb based SDF. |
|
Duplicate. |
Description
SDF.create_from_mesh(andMesh.build_sdf) computes two representations: a sparse NanoVDB grid and a companion texture SDF used by the GL viewer's isomesh pass, hydroelastic broadphase, and texture-based SDF sampling. The docstring promises thattarget_voxel_size"takes precedence overmax_resolution", but that was only honored by the sparse path — the texture path never receivedtarget_voxel_sizeand silently fell back tomax_resolution=64. Users parameterizing by world-unit voxel size therefore got a dramatically coarser texture SDF than the sparse grid, with no warning.This PR forwards
target_voxel_sizethrough tocreate_texture_sdf_from_meshand gives that function the same precedence policy as the sparse path. TheNone → 64fallback is kept inside the texture module so the caller no longer duplicates the ceil/padding math.Closes #2524
Checklist
CHANGELOG.mdhas been updated (if user-facing change)Test plan
The new regression test was also verified to fail without the source fix applied.
Bug fix
Steps to reproduce:
target_voxel_sizealone (nomax_resolution).sdf._coarse_textureandsdf._subgrid_texturedimensions.Minimal reproduction:
Summary by CodeRabbit
Bug Fixes
target_voxel_sizeparameter to properly control texture SDF resolution during mesh-to-SDF conversion, ensuring consistent control over both texture and sparse grid resolutions.Tests
target_voxel_sizeparameter propagates correctly to texture resolution calculations.