Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Suggestion / Idea  A few bugs and feature requests
#2
Hi there!

Quote: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!

Quote: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.

Quote: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?

Quote: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

Quote: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.

Quote: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)

Quote: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.

Quote: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).
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 josemendez - 24-05-2021, 08:31 AM
RE: A few bugs and feature requests - by Nyphur - 30-05-2021, 11:12 PM