Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Suggestion / Idea  A few bugs and feature requests
#3
(24-05-2021, 08:31 AM)josemendez Wrote: You can't decouple emission speed/force and emission rate.

This is only possible for regular particle emitters, since each particle is largely independent from each other. Also possible for FLIP simulators, since pressure is not solved on particles but on a grid.

However when simulating fluids using fully lagrangian methods, each particle represents a certain volume of fluid. This means that if you place particles too close to each other, local density will increase and as a result, a pressure spike will take place. This spike will send particles flying away from each other: a fluid "explosion". This is *always* undesirable, as you can't control how/when this will happen.

The emitter carefully adjusts emission rate depending on emission speed and fluid resolution so that particle spacing guarantees no pressure spikes.
That makes sense, thanks for the info!

I had already experimented with decoupled emission speed and rate before posting though and found that in some cases lower emission force produced good results and didn't lead to pressure spikes or any weird behaviour. It was mostly with low resolution fluid, where it would fling the fluid more than necessary.

(24-05-2021, 08:31 AM)josemendez Wrote: We can show a progress bar and let you cancel it if needed. I haven't found such a case though (unless you set extremely large values, like 1 million blueprint capacity, etc). Can you go into further detail?
A progress bar might help for blueprint generation but the other problem is runtime lockup of the solver as then we just have to force-quit unity. I don't know how feasible it is, but it'd be fantastic to be able to give a solver a timeout value so that it will shut off if it's in play mode and it's taking an absurd length of time on a single frame, say 30 seconds?

I'll try to take a note of what setups cause this to happen when it occurs again, but it wasn't a huge number of particles. I believe I experienced it with high viscosity values or certain surface values.

(24-05-2021, 08:31 AM)josemendez Wrote: The current phase system is going away in Obi 6.2, replaced with a category system (like the one used by Box2D or Unity's ECS physics). See:
http://obi.virtualmethodstudio.com/forum...-2933.html

That's amazing, thanks! It's exactly what I had in mind, and 15 separate layers is more than enough.


(24-05-2021, 08:31 AM)josemendez Wrote: You can call emitter.KillParticle(index) whenever you need. Couple this will collision callbacks / triggers /advection, and you can do lots of things: kill particles on contact with colliders, when entering certain zones, when nearby other particles, when isolated, etc.

Note you can use float.PositiveInfinity as the lifetime, to effectively make immortal particles. In the editor, you can do this by typing "Infinity" into the lifespan field (https://answers.unity.com/questions/2104...inity.html)

Can already be done: set their inverse mass to zero, turn them into granular particles, then override their positions manually. There's a sample scene in Obi 6.1 that does this. Let me know if you need help with it.

This is all fantastic, thank you! Are the collision/trigger callbacks not very expensive? I instead created a manual emission method that emitted a certain number of particles and returned their indices, then used those in a script. In my case I made it emit 1000 particles split into 5 groups of 200 and then created spheres that attract their assigned list of 200 particles. Does that sound reasonable or would you suggest another way?

(24-05-2021, 08:31 AM)josemendez Wrote: Can't be done at runtime, because softbody blueprint generation is very expensive. Even simple blueprints take a few seconds to generate, you can't do this in realtime (in most cases you'd need to present the user with loading bar of some kind).

Ah, I wasn't thinking of necessarily generating a blueprint at runtime. I was wondering if we could basically make the fluid take the shape of a pre-generated blueprint. So you could press a button and the fluid would form into a sphere or a cube or a dragon, and then press another button and it'd collapse to the ground as a liquid again. We could just read the blueprint data to get the particle positions or even link it to a live softbody simulation so it'd behave as a squishy mass of fluid.

I was just wondering if this is something that's already implemented in some way, like can we just render a softbody as a fluid?


I implemented my own version of it as an experiment, it just switches gravity off and moves the particles toward the new positions pulled from the selected blueprint. It also works with a live actor:
Reply


Messages In This Thread
A few bugs and feature requests - by Nyphur - 21-05-2021, 09:18 PM
RE: A few bugs and feature requests - by Nyphur - 30-05-2021, 11:12 PM