Yesterday, 03:52 PM
(This post was last modified: Yesterday, 04:20 PM by josemendez.)
(Yesterday, 02:55 PM)chenji Wrote: 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.
(Yesterday, 02:55 PM)chenji Wrote: 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.
(Yesterday, 02:55 PM)chenji Wrote: 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.