Obi Official Forum

Hi, I wonder what would be a good way to modify distance field during runtime.
In my case there are several distance fields, we can treat them as animation keyframes to make this example simple -I want to interpolate between them over time and use it for collision.
The problem with ASDF is those trees have got different number of nodes and it's not trivial to generate new interpolated SDF. What would be good way to tackle this problem?

The best way would be to generate SDF for every update and just swap current nodes in distance field (note I use burst backend), I guess another option is to just sample both an interpolate result, but I would need to modify obi sagnificantly.

Furthermore main question is if such a collision is going to work properly when it comes to simulations itself, I did test with hard swapping colliders and without interpolation it jumps, because of depenetration, so I am not even sure if this would work for normal timesteps (50-60).

(07-10-2025, 01:09 PM)Qriva0 Wrote: [ -> ]Hi, I wonder what would be a good way to modify distance field during runtime.
In my case there are several distance fields, we can treat them as animation keyframes to make this example simple -I want to interpolate between them over time and use it for collision.

Hi!

This idea won't work at all, but more on that below.

(07-10-2025, 01:09 PM)Qriva0 Wrote: [ -> ]The problem with ASDF is those trees have got different number of nodes and it's not trivial to generate new interpolated SDF. What would be good way to tackle this problem?

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.

You can achieve this by setting the max error parameter to zero (so nodes will always be generated regardless of how much remaining error with the ground truth surface there is) and controlling the depth of the tree using max depth. 

Note that the max depth parameter is clamped to a minimum, you might need to slightly modify Obi's code to allow it to reach zero.

(07-10-2025, 01:09 PM)Qriva0 Wrote: [ -> ]Furthermore main question is if such a collision is going to work properly when it comes to simulations itself, I did test with hard swapping colliders and without interpolation it jumps, because of depenetration, so I am not even sure if this would work for normal timesteps (50-60).

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.

kind regards,

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?

(08-10-2025, 09:53 AM)Qriva0 Wrote: [ -> ]Hi!
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".

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?

Correct. Off the top of my head, there's no easy and accurate way to calculate a surface movement/velocity vector from two SDFs, as you'd need to get correspondences between points in each SDF to do that. Take this with a grain of salt though as I've never actually tried it out.

(08-10-2025, 09:53 AM)Qriva0 Wrote: [ -> ]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?

That's the gist of it, yes. You'd need to somehow calculate and store velocities as well, to get proper collisions.

(08-10-2025, 09:53 AM)Qriva0 Wrote: [ -> ]But except that, would that be very bad if movement of SDF surface was not huge?

Depends on how much "bad" you're willing to tolerate in your case. You would get no friction at all (since the SDF velocity is zero) and you'd get some popping/jitter as the SDF surface moves around pushing particles out of its way. If all you want is to roughly keep particles out of the SDF volume, it may be ok. If you want something resembling actual collisions then I would discard the idea.

(08-10-2025, 09:53 AM)Qriva0 Wrote: [ -> ]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?

The softbody implementation in Obi is meshess, as it uses shape matching. For surface collisions it uses triangles. However keep in mind that surface collisions are just a cheap approximation of true edge vs triangle vs point collisions, they may not offer 100% smooth collision detection under all circumstances.

I'd need to know more about your use case to give useful feedback. Rod vs softbody collisions should just work even without surface collisions, as long as the rod and the softbody are sufficiently sampled with particles. Now, if either of them uses sparse sampling (meaning there's gaps in between particles) surface collisions should work except in scenarios involving large forces or high velocities.

kind regards,

(08-10-2025, 10:03 AM)josemendez Wrote: [ -> ]Correct. Off the top of my head, there's no easy and accurate way to calculate a surface movement/velocity vector from two SDFs, as you'd need to get correspondences between points in each SDF to do that. Take this with a grain of salt though as I've never actually tried it out.

That's the gist of it, yes. You'd need to somehow calculate and store velocities as well, to get proper collisions.

You are right this is not trivial if we want to know exact point to point movement, I thought about simplification along the normals, so I know time between flipbook frames and I take that to calculate velocity from delta. I would compare it to tweaking collider thickness. and taking that delta as velocity.

(08-10-2025, 10:03 AM)josemendez Wrote: [ -> ]Depends on how much "bad" you're willing to tolerate in your case. You would get no friction at all (since the SDF velocity is zero) and you'd get some popping/jitter as the SDF surface moves around pushing particles out of its way. If all you want is to roughly keep particles out of the SDF volume, it may be ok. If you want something resembling actual collisions then I would discard the idea.

Yeah, no friction is problematic and to be honest depenetration can cause sagnificant "jumps". I might try to use collider thickness to simulate and see how it actually behaves.

(08-10-2025, 10:03 AM)josemendez Wrote: [ -> ]The softbody implementation in Obi is meshess, as it uses shape matching. For surface collisions it uses triangles. However keep in mind that surface collisions are just a cheap approximation of true edge vs triangle vs point collisions, they may not offer 100% smooth collision detection under all circumstances.

I'd need to know more about your use case to give useful feedback. Rod vs softbody collisions should just work even without surface collisions, as long as the rod and the softbody are sufficiently sampled with particles. Now, if either of them uses sparse sampling (meaning there's gaps in between particles) surface collisions should work except in scenarios involving large forces or high velocities.

My rod is not dense, but I used surface for both, just to be sure particles do not penetrate the surface, for cloth it works really well, so I expected something similar from softbodies, but in reality it did not work so well. I can't send videos here, so I am going to send one to your email.

(08-10-2025, 10:36 AM)Qriva0 Wrote: [ -> ]You are right this is not trivial if we want to know exact point to point movement, I thought about simplification along the normals, so I know time between flipbook frames and I take that to calculate velocity from delta. I would compare it to tweaking collider thickness. and taking that delta as velocity.

I believe that would solve depenetration "jumping", but still yield no friction since lateral movement of the surface is not taken into consideration: surface velocity is always along the normal.

Will take a look at the video you sent via email and get back to you.

cheers,

Wouldn't it be possible to make a collider that wraps two DF colliders? There would be an overhead of sampling two colliders, but that should make it possible to smoothly blend between them, right?

(12-10-2025, 04:06 PM)goosejordan Wrote: [ -> ]Wouldn't it be possible to make a collider that wraps two DF colliders? There would be an overhead of sampling two colliders, but that should make it possible to smoothly blend between them, right?

You could of course just sample both SDFs and interpolate the resuls, but you to do that you need to traverse both SDFs instead of traversing one and interpolating the node at the same memory offset in the second SDF (which is why suggested making sure the topology of both sdf trees is identical).

All the other issues mentioned in this thread would still take place - no velocities involved, no friction, and no proper contact resolution - so this solution would take you to the same place at double the cost.