Suggestion / Idea A few bugs and feature requests

[Nyphur]

Have been using the Obi tools for a few weeks now, it's a fantastic set of tools and the softbody particle simulation is kind of genius. I've been exploring various use cases for a game in development and have noticed a few bugs and issues and had some and some features that would be great to see implemented.

Bugs and issues:

1. Obi Emitter Min pool size doesn't work when set to 1. Fix is to swap the > on ObiEmitter.cs line 462 for a >=.
   
   
2. Obi Emitter speed variable for flow rate doesn't work well for very low-resolution fluids (e.g. 0.1 resolution). I've found a few cases where decoupling emission force and emission rate was useful.
   
   
3. Certain settings can make the solver lock up and you have to kill the Unity process. I know this isn't an easy one, but is it possible to have the solver stop and throw an error if the process is taking too long?
   

Feature requests:

1. Alternative phase system: The Phase system for filtering which particles interact with which colliders feels kind of reversed, we can only select one phase to NOT interact with so there's no way to limit specific particles to a specific collider. Is the current implementation necessary for a performance or stability reason?
   
   
2. Random emission: Obi Emitter shapes generate a distribution of points to spawn particles at, and it emits particles at them sequentially, resulting in predictable patterns. Could we get an optional pseudorandom distribution order? Possibly do this at the distribution point generation time to minimise performance issues?
   
   
3. Manual EmissionMethod: The current system is great for continuous or burst emission of fluid, but to integrate it with most games will require programmatic emission of a controlled number of particles. It'd be good to add a Manual emission type where it doesn't emit until a method is called to emit a specific number of particles.
   
   
4. More particle kill methods: Right now all particles must have a life span set and are killed at the end of that. I'd love to get some alternative kill methods, like if I could emit 100 particles with no kill time and then manually kill them later, or maybe make particles killed by velocity or collision force or minimum connections (like individual disconnected particles self-destroy). Just feels like there's a lot of room for expansion here.
   
   
5. Convert fluid to softbody blueprint: This is a bit of a crazy one, but could we get a way to solidify a set of fluid particles together in their current shape, or to make them transform into a shape provided by a softbody blueprint?
   

Again, it's a fantastic tool set and I'm just beginning to experiment with how we can integrate it with our current game design so please let me know if any of these features can already be done in some way. The code is nice and clean and I'll be able to extend it further to add features like these, but other people would probably get use out of them too as they seem like common use cases for games.

[josemendez]

Hi there!

Obi Emitter Min pool size doesn't work when set to 1. Fix is to swap the > on ObiEmitter.cs line 462 for a >=.

Thanks for reporting this!

Obi Emitter speed variable for flow rate doesn't work well for very low-resolution fluids (e.g. 0.1 resolution). I've found a few cases where decoupling emission force and emission rate was useful.

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.

Certain settings can make the solver lock up and you have to kill the Unity process. I know this isn't an easy one, but is it possible to have the solver stop and throw an error if the process is taking too long?

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?

Alternative phase system: The Phase system for filtering which particles interact with which colliders feels kind of reversed, we can only select one phase to NOT interact with so there's no way to limit specific particles to a specific collider. Is the current implementation necessary for a performance or stability reason?

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

Obi Emitter shapes generate a distribution of points to spawn particles at, and it emits particles at them sequentially, resulting in predictable patterns. Could we get an optional pseudorandom distribution order? Possibly do this at the distribution point generation time to minimise performance issues?

Can't do, same reason why you can't decouple emission speed and rate. Emitting particles at random times/positions would result in pressure spikes, and random "explosions". Best I could do is use poisson point sampling but it would still result in a predictable pattern, just a different one.

More particle kill methods: Right now all particles must have a life span set and are killed at the end of that. I'd love to get some alternative kill methods, like if I could emit 100 particles with no kill time and then manually kill them later, or maybe make particles killed by velocity or collision force or minimum connections (like individual disconnected particles self-destroy). Just feels like there's a lot of room for expansion here.

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)

could we get a way to solidify a set of fluid particles together in their current shape

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.

or to make them transform into a shape provided by a softbody blueprint

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).

[Nyphur]

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.

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.

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.

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?

---

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: