Help Force Zone apply different accelaration to 2 ropes

[chenji]

Hi,

I'm using force zone to simulate bouyancy of fishing ropes underwater. I've set Radial and Accelaration mode. My question is, is it possible to let 1 force zone add different accelaration for 2 different ropes (since different type of fishing rope may has different bouyancy force value)? Note the 2 ropes are bound with stitcher. So they are expected to be underwater at the same time.
Do I have to use 2 force zones and the 2 ropes must in different Obi collider category? Any better ways? Because if there are may ropes it's a bit difficult to keep them in different Obi collider category.

[josemendez]

Hi,

I'm using force zone to simulate bouyancy of fishing ropes underwater. I've set Radial and Accelaration mode. My question is, is it possible to let 1 force zone add different accelaration for 2 different ropes (since different type of fishing rope may has different bouyancy force value)? Note the 2 ropes are bound with stitcher. So they are expected to be underwater at the same time.
Do I have to use 2 force zones and the 2 ropes must in different Obi collider category? Any better ways? Because if there are may ropes it's a bit difficult to keep them in different Obi collider category.

Hi!

It's not possible for a single force zone to apply different acceleration values depending on which actor the particles belong to. How about using force instead of acceleration, and then use the particle's mass to control how much each rope is affected by the force? A heavier rope will sink more than a lighter one.

kind regards,

[chenji]

Hi!

It's not possible for a single force zone to apply different acceleration values depending on which actor the particles belong to. How about using force instead of acceleration, and then use the particle's mass to control how much each rope is affected by the force? A heavier rope will sink more than a lighter one.

kind regards,

I'll try it. Thanks. Would be better if it's supported in the future.

[josemendez]

The problem of "Force" mode is, the direction of the force is not toward the surface of the collider, so it cannot be used in my scenario. Or, do I misunderstand the usage of this mode?

The mode (acceleration/force/wind) has nothing to do with the direction. The type of the zone (radial/directional/vortex) is what determines the direction of the acceleration/force/wind.

For water/buoyancy, you should be using mode = force and type = directional anyways. This is because unlike gravity, buoyancy is a force, and it has constant direction when inside the medium (towards the surface). Using mode = acceleration and type = radial doesn't really make sense for buoyancy.

kind regards,

[chenji]

The mode (acceleration/force/wind) has nothing to do with the direction. The type of the zone (radial/directional/vortex) is what determines the direction of the acceleration/force/wind.

For water/buoyancy, you should be using mode = force and type = directional anyways. This is because unlike gravity, buoyancy is a force, and it has constant direction when inside the medium (towards the surface). Using mode = acceleration and type = radial doesn't really make sense for buoyancy.

kind regards,

Yes I've noticed that. Prev post is deleted. The problem of force is, it's a little difficult to adjust the force value as the radius/volume of the 2 ropes may vary. I'll try to find some tricky way to achieve this.

Why I prefer mode = acceleration: it's not related to mass, line radius (or volume in water), but only to material density . This way, I can calculate the acceleration based on the density ratio of the material to water. If I use force mode, I need to calculate the volume of the line in water, which is a bit difficult

[chenji]

As an update: Considering it's difficult to achieve this (no matter whether I use acceleration or force mode, I cannot use 2 different force values to apply force on 2 ropes, which may make the bouyancy simulation unreal) , I finally decide to use the acceleration value calculated by main rope's density. Fortunately I'm developing a 1st person game so the sub rope is usually far away from the camera and it may get visually unreal bouyancy only when the hook breaks, so game player may not notice this in my game.

I hope this feature (1 force zone, different force val/direction for different actors) can be supported in future version.

[josemendez]

As an update: Considering it's difficult to achieve this (no matter whether I use acceleration or force mode, I cannot use 2 different force values to apply force on 2 ropes, which may make the bouyancy simulation unreal) ,

I'm not entirely sure what your use case is, sorry. Force zones already support affecting each actor/particle differently, by using force mode.

It's also how it works in the real world. Take buoyancy, for instance: buoyant force acting on a completely submerged object only depends on the density ratio of the object and the liquid it's submerged in.

The density of the liquid (and all its other properties) is the same for all submerged objects, so the only remaining variable is the density of each object: buoyant force = fluidDensity * objectVolume * -gravity. Since acceleration = force / mass, you end up with acceleration = fluidDensity / objectDensity * -gravity. Since fluid density and gravity are constants, you can treat the density ratio as a single variable defined per object that you can control by altering the object's mass.

So following this, you can set the mass of each of your actors differently (accounting for their volume as well, in case you want) and it will somewhat accurately simulate buoyancy, resulting in the same accelerations you'd get from different force values for each actor/force zone combination.

This way, I can calculate the acceleration based on the density ratio of the material to water. If I use force mode, I need to calculate the volume of the line in water, which is a bit difficult

You can use the force zone's falloff to approximate the submerged volume using the distance of each particle to the surface. For instance if you set max falloff distance to the diameter of the line, you'll get maximum buoyancy when the line is completely submerged, and it will linearly decay to zero as the line goes above the water surface.

In any case, the fishing line is so thin and its volume so small I doubt this will have any impact on its behavior.

I hope this feature (1 force zone, different force val/direction for different actors) can be supported in future version.

If you mean support for manually specifying an arbitrary force for each actor that may go inside a force zone, that would be pretty impractical from a UX perspective as it would force you to specify a force value for every possible force zone/actor combination in the scene. This is the same reason why most existing physics engines don't specify a friction coefficient for each possible combination of materials (which would be the physically accurate thing to do), and instead give each material its own friction coefficient.

Still, note you can write your own force zones that affect particles in any way you want. There's an example of this (a gravity well) in the manual: https://obi.virtualmethodstudio.com/manu...icles.html

kind regards,

[chenji]

You can use the force zone's falloff to approximate the submerged volume using the distance of each particle to the surface. For instance if you set max falloff distance to the diameter of the line, you'll get maximum buoyancy when the line is completely submerged, and it will linearly decay to zero as the line goes above the water surface.

Take this sample, if a rope A whose diameter is 1m and a rope B whose diameter is 0.01m in the force zone, it's still difficult to achieve what you mentioned as you can only specify one value for all of them. So the main issue I think is, we are unable to specify different value for different actors in one force zone.

If you mean support for manually specifying an arbitrary force for each actor that may go inside a force zone, that would be pretty impractical from a UX perspective as it would force you to specify a force value for every possible force zone/actor combination in the scene. This is the same reason why most physics engines don't specify a friction coefficient for each possible combination of materials (which would be the physically accurate thing to do), and instead give each material its own friction coefficient.

I think it would be enough if there is an EventHandler(ObiActor actor, out Force forceOrOtherThingLetWeChange) that is called when a force zone calculates the force it applies on a particle. We can subscribe it and change the force/direction if needed.

So following this, you can set the mass of each of your actors differently (accounting for their volume as well, in case you want) and it will somewhat accurately simulate buoyancy, resulting in the same accelerations you'd get from different force values for each actor/force zone combination.

If I change the mass of the rope, its physics behavior will be changed when it's not in water which is what I want to avoid. I may change its mass when it's in water and change it back when it leaves water but it's a little complicated. Moreover it's wrong that the more mass an object has, the more it will sink. (A big boat floating on water vs a small stone sink), so the simulation is unreal if I totally rely on mass. My requirement is, there are 3-4 kind of ropes in my game. Density ratio vs water ranges from 0.5 to 1.0. I want to simulate their bouyancy as real as possible.

[josemendez]

Take this sample, if a rope A whose diameter is 1m and a rope B whose diameter is 0.01m in the force zone, it's still difficult to achieve what you mentioned as you can only specify one value for all of them. So the main issue I think is, we are unable to specify different value for different actors in one force zone.

I see, however you can create identical two force zones with different force values and then use collision filters so that one force zone affects rope A and the second force zone only affects rope B.

This is simple to setup, however you may run into scalability issues if you need many different zone/actor combinations.

I think it would be enough if there is an EventHandler(ObiActor actor, out Force forceOrOtherThingLetWeChange) that is called when a force zone calculates the force it applies on a particle.

Having an individual callback per particle would be way too costly in the CPU backend - with each call happening in a different thread, limiting usefulness - and outright impossible to do in the GPU backend.

Instead, Obi has collision callbacks that report a list of all contacts generated during a frame. Collision callbacks happen in the main thread, so you're free to process them single-threaded or roll your own multithreaded code to process them in parallel. You can also tell which actor each particle involved in a contact belongs to, by checking the solver.particleToActor array, so you can calculate and apply a different force depending on the actor they belong to.

This is the same system force zones, triggers and colliders use internally, so it comes at no extra cost.

Moreover it's wrong that the more mass an object has, the more it will sink. (A big boat floating on water vs a small stone sink), so the simulation is unreal if I totally rely on mass.

Not at all, you know the boat is hollow and the rock is not, but you could make the boat sink and the rock float just by adjusting their mass - without altering their volume. This does not make it any worse, or less real.

In other words: there's no way you can tell the difference in volume between two identically sized spheres, a hollow but heavy one and a solid but light one, as long as their density ratio with water is the same. For an external observer, they have identical mass and volume. If picked up, you'd notice they have different mass but would still not notice any difference in volume. So it's safe to completely disregard volume and only work with mass.

Mathematically, keep in mind acceleration due to buoyancy only depends on the density ratio. So you end up with fluidDensity/particleDensity = fluidMass/particleMass, volume does not appear. That's why I proposed particleMass = densityRatio as a solution. There's no point in having an explicit "volume" variable that is going to be completely folded into a constant anyway.

[chenji]

I see, however you can create identical two force zones with different force values and then use collision filters so that one force zone affects rope A and the second force zone only affects rope B.

This is simple to setup, however you may run into scalability issues if you need many different zone/actor combinations.

Yes this is what I said in my init post. It may work for 2 ropes but does not work if rope number increases.

Having an individual callback per particle would be way too costly in the CPU backend - with each call happening in a different thread, limiting usefulness - and outright impossible to do in the GPU backend.

Maybe force zone can support a callback per actor, and let us change data for different actors?

So you end up with fluidDensity/particleDensity = fluidMass/particleMass, volume does not appear. That's why I proposed particleMass = densityRatio as a solution.

I've tried set particleMass=0.001 and Force to 0.01, expecting to get 0 accelation but the behavior is a little different with accelation mode=9.8. May be related to the fact that my rope's mass is not totally same. The control point's mass is different as I want to keep a low mass ratio with the attachment. For now I'll go with accelation mode, use main rope's density to calculate accelation  value, and use multiple force zone if there are more ropes need to appear at the same time (in my game, at most 3 force zones are needed so it should be ok with this approach) .