Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SDF interpolation
#3
Hi!
(08-10-2025, 08:11 AM)josemendez Wrote: The simplest way I can think of is to make sure both trees have the same topology: same depth, every level densely populated. Then you can just interpolate every node with its corresponding node in the second distance field.
Yeah that was the same idea I had in mind, but instead of generating full volume with 0 I thought about some kind of prost processing to construct tree that contains all possible branches from "flipbook".

(08-10-2025, 08:11 AM)josemendez Wrote: This is the main problem indeed: collisions won't work properly when using SDF "flipbooks" (interpolated or not).

Collisions are inherently velocity-based: if you have two objects A and B and you know their velocities, you can calculate the point where they will collide in the near future, and reduce their velocities to prevent penetration. You can also alter their velocities in the direction tangential to the contact normal to account for friction.

However if either object moves and its velocity doesn't reflect this movement (for instance, its velocity its zero) then it has effectively teleported, and it may end up penetrating other objects. The physics engine cannot do anything to prevent this penetration as it can't predict it in advance, and once it can detect it it's already too late: it can only try to correct it after it has already happened. This is done by pushing either/both objects out of each other, but this modifies their velocities in an unphysical way. Obi allows you to control the maximum velocity that objects can move out of each other once they've already overlapped (ObiSolver->max depenetration).

So in the case of SDF flipbooks we don't have any velocity information, so we lose proper collision response (no overlaps, friction) and fall back to depenetration, which is just a quick fix for a situation that shouldn't have happened in the first place.

This is the same reason why animating MeshColliders in Unity doesn't make sense and why it's not supported at all.
Thank you for your feedback! So to make it work properly I would need to know vector field of movement, and that is not possible in current package without modification, correct?
What you described makes sense, so I would need to have two SDF's interpolated, but on top of that I would need to calculate velocity of that movement and apply this to particles?

But except that, would that be very bad if movement of SDF surface was not huge? Maybe I should explain what I wanted:
The core idea is that I want to have collision of rod with some soft materials aka flesh, so I made softbody initially, I enabled surface collisions, but for some reason it's unstable, I guess shape constraint it too "strong" to keep rod depenetrated when pused against the surface, or perhaps this is related to collision itself? I think softbody uses triangles instead of tetrahedrons, not sure if this is huge difference? In any case rod patricles liked to stuck in softbody or the whole collision was buggy. Because of that I threw the idea, and used SDF instead, but I wanted to at least that surface to be "deformable", not by rod, but in general, by some other script and this is why I asked about SDF interpolation.

So long story short, can you see some reasonably easy to implement options for those scenarios?
Reply


Messages In This Thread
SDF interpolation - by Qriva0 - 07-10-2025, 01:09 PM
RE: SDF interpolation - by josemendez - 08-10-2025, 08:11 AM
RE: SDF interpolation - by Qriva0 - 08-10-2025, 09:53 AM
RE: SDF interpolation - by josemendez - 08-10-2025, 10:03 AM
RE: SDF interpolation - by Qriva0 - 08-10-2025, 10:36 AM
RE: SDF interpolation - by josemendez - 09-10-2025, 08:53 AM
RE: SDF interpolation - by goosejordan - 12-10-2025, 04:06 PM
RE: SDF interpolation - by josemendez - 12-10-2025, 10:36 PM