Help Can;t get scaling and behavior right...

[aardworm]

Hi I like the asset, however, it’s quite hard to make something with it. I’m trying to make dynamic crying with water that rundown the cheek of a character. Judging from the description this should be possible. The character is about 2 meters tall. 

I’m having a couple of problems:

1. It seems the Emitter should always be a child of the solver. Is there a way around this? Because other otherwise you can only simulate liquid on an object that stands still…
   
2. I can’t get the scaling right. When I use method 1 (or 2) from this video. Either the physics become floaty or the mesher (or renderer?) doesn’t render the liquid properly. However, the particles look fine. https://www.youtube.com/watch?v=W0ojzG5dzjU&list=PLnCR8_XCOgrbhhk40Bxbw8gcnaiy5PYL_&index=2&ab_channel=VirtualMethod
   
3. No matter what I do, I can't get the rendering right... Image here:  https://ibb.co/L0qNCvD
   

[josemendez]

Hi!

I’m trying to make dynamic crying with water that rundown the cheek of a character. Judging from the description this should be possible.

Possible, but absolute overkill. A simple texture-based approach driving material roughness would get the job done easier and at a very small fraction of the cost.

Emitter should always be a child of the solver. Is there a way around this?

No, since you need a simulation space for the simulation to happen in. Same reason you need a canvas for UI rendering, or a root bone for character animation.

Because other otherwise you can only simulate liquid on an object that stands still…

Why would that be? You can move the solver, emitters, colliders, and the fluid particles themselves. No need for anything to stand still.

I can’t get the scaling right. When I use method 1 (or 2) from this video. Either the physics become floaty or the mesher (or renderer?) doesn’t render the liquid properly.

If you adjust the size of particles, you need to adjust the mesher's voxel size accordingly. That is, if you make particles smaller, make the voxel size smaller too.

No matter what I do, I can't get the rendering right... Image here:  https://ibb.co/L0qNCvD

Other than the particles being rendered as well (simply disable the ObiParticleRenderer component for them to go away) and isosurface being completely off (you need to use a smaller value) not sure what's wrong with rendering in that pic? Could you be a bit more specific?

kind regards

[aardworm]

Hi again,

thank you for the prompt response!!!

Possible, but absolute overkill. A simple texture-based approach driving material roughness would get the job done easier and at a very small fraction of the cost.

Fair enough! But I'd like to have realistic fluids in general as liquids and fluids will be a common theme in my game, including blood etc.. And I'm also looking for realistic physics as I think such systems, once set up properly, look better.

Why would that be? You can move the solver, emitters, colliders, and the fluid particles themselves. No need for anything to stand still.

True, I thought of that as well, but how would you do something like in Ghost of Tsushima. They spawn blood around the blade as well as a the point of impact. You'd write a script to make the emitter follow the blade and the character's impact points?

Thank you for the tips! I have the fluid looking like I wanted it now!

[josemendez]

Fair enough! But I'd like to have realistic fluids in general as liquids and fluids will be a common theme in my game, including blood etc..

I mean, "full" fluid simulation - which is what Obi does - is several orders of magnitude more expensive than what you'd  normally use for say, blood splashes in a game. After all, these are not normally simulated at all but just a few billboards/decals. You need to ask yourself if the extra realism is worth the sacrifice in other areas of the game.

And I'm also looking for realistic physics as I think such systems, once set up properly, look better.

Yes they can look better, but will also eat up a much larger chunk of your budget. As you know, the typical budget for a game is 16 ms/frame. If you're willing to spend say 30% (5 ms) of your frame budget on a character's tears, they better be extremely critical for your gameplay. Otherwise you will soon run out of juice to do basically anything else in the game.

Obi is designed for use cases where fluid simulation is a key component of the game (say, a game about driving fluid trough a maze) or very visually prominent. I wouldn't recommend its use for minor/secondary eye candy.

True, I thought of that as well, but how would you do something like in Ghost of Tsushima. They spawn blood around the blade as well as a the point of impact.

I'm not sure about the problem you're seeing here: just spawn fluid wherever you need it?

kind regards

[aardworm]

I mean, "full" fluid simulation - which is what Obi does - is several orders of magnitude more expensive than what you'd  normally use for say, blood splashes in a game. After all, these are not normally simulated at all but just a few billboards/decals. You need to ask yourself if the extra realism is worth the sacrifice in other areas of the game.


Yes they can look better, but will also eat up a much larger chunk of your budget. As you know, the typical budget for a game is 16 ms/frame. If you're willing to spend say 30% (5 ms) of your frame budget on a character's tears, they better be extremely critical for your gameplay. Otherwise you will soon run out of juice to do basically anything else in the game.

Obi is designed for use cases where fluid simulation is a key component of the game (say, a game about driving fluid trough a maze) or very visually prominent. I wouldn't recommend its use for minor/secondary eye candy.


I'm not sure about the problem you're seeing here: just spawn fluid wherever you need it?

kind regards

Thank you! I understand but my game will have sword mechanics and blood simulation like Ghost of Tsushima.
It seems Ghost was made with using fluid simulation, particle effects and blood decals. This (video) is what I'd like to achieve as as well. The blood system has decals and particle effects. I'm just wondering how I'd include the fluid simulation. Meaning, you'd probably have to move the fluid emitter to the location where the blood is needed. And if you're slicing two people at once, you 'd need to have multiple blood emitters in the right place. 

Or how would you set up your project if you'd like to have liquid simulation in addition to particles and decals?

[josemendez]

Thank you! I understand but my game will have sword mechanics and blood simulation like Ghost of Tsushima.
It seems Ghost was made with using fluid simulation, particle effects and blood decals. This (video) is what I'd like to achieve as as well. The blood system has decals and particle effects. I'm just wondering how I'd include the fluid simulation. Meaning, you'd probably have to move the fluid emitter to the location where the blood is needed. And if you're slicing two people at once, you 'd need to have multiple blood emitters in the right place. 

Or how would you set up your project if you'd like to have liquid simulation in addition to particles and decals?

I’m sad to inform you that the author of that video has absolutely no idea what “fluid simulation” means :/.

The video clearly shows a regular particle system + texture splatting, which is a technique related to decals: instead of using a set of pre-defined textures as your decals (which would result in the blood stains on the floor not lining up with the particles that generated them, and jarring reuse of the same textures time and time again) you set up an empty texture and “splat” (rasterize) each particle where it hits the texture. This way you obtain a decal that’s unique every time, and follows the particle splash pattern precisely.

However this technique involves no fluid simulation whatsoever. For something to be a “fluid simulation” it has to solve the Navier-Stokes equations in any of their many forms. The specific flavor of these equations solved and the approach used determine the kind of fluid simulator:

- cell based (aka Eulerian), such as level-set, lattice boltzmann, most SWE solvers, or stable fluids - used by Ghost of Tsushima for grass wind and blood advection on rivers.
- particle based (aka Lagrangian) such as SPH or PBF
- hybrid such as MPM or PIC/FLIP.

You can google these terms to get a lot of information on each method. Obi is a lagrangian solver, more specifically a PBF (position-based fluid) solver. You don’t need it at all to obtain the effect shown in the video, in fact it would only hinder you by consuming resources doing nothing of value for your use case. A fluid solver is only required when you need to simulate pressure, vortices, viscosity or surface tension effects, none of which have any noticeable effect in a blood splat on the floor (mainly because blood does not accumulate enough to slosh around or have any visible currents/vortices in it, it just lays there on the floor). If you were to simulate a relatively large volume of accumulated blood like a bucket or a pool, using fluid simulation would begin to be a reasonable idea.

You need a good decal/splat based solution, and maybe a GPU-based particle system like Unity’s VFX Graph. My advice would be to do a bit of research on the subject. If at any point you feel like getting a refund for Obi Fluid, just let me know.

Kind regards

[aardworm]

I’m sad to inform you that the author of that video has absolutely no idea what “fluid simulation” means :/.

The video clearly shows a regular particle system + texture splatting, which is a technique related to decals: instead of using a set of pre-defined textures as your decals (which would result in the blood stains on the floor not lining up with the particles that generated them, and jarring reuse of the same textures time and time again) you set up an empty texture and “splat” (rasterize) each particle where it hits the texture. This way you obtain a decal that’s unique every time, and follows the particle splash pattern precisely.

However this technique involves no fluid simulation whatsoever. For something to be a “fluid simulation” it has to solve the Navier-Stokes equations in any of their many forms. The specific flavor of these equations solved and the approach used determine the kind of fluid simulator:

- cell based (aka Eulerian), such as level-set, lattice boltzmann, most SWE solvers, or stable fluids - used by Ghost of Tsushima for grass wind and blood advection on rivers.
- particle based (aka Lagrangian) such as SPH or PBF
- hybrid such as MPM or PIC/FLIP.

You can google these terms to get a lot of information on each method. Obi is a lagrangian solver, more specifically a PBF (position-based fluid) solver. You don’t need it at all to obtain the effect shown in the video, in fact it would only hinder you by consuming resources doing nothing of value for your use case. A fluid solver is only required when you need to simulate pressure, vortices, viscosity or surface tension effects, none of which have any noticeable effect in a blood splat on the floor (mainly because blood does not accumulate enough to slosh around or have any visible currents/vortices in it, it just lays there on the floor). If you were to simulate a relatively large volume of accumulated blood like a bucket or a pool, using fluid simulation would begin to be a reasonable idea.

You need a good decal/splat based solution, and maybe a GPU-based particle system like Unity’s VFX Graph. My advice would be to do a bit of research on the subject. If at any point you feel like getting a refund for Obi Fluid, just let me know.

Kind regards

Thank you very very (!) much for the tips. I'll have a look into this and I'll consider your offer! 

Two questions though; what would be the "cleanest" way to have different liquids come out of multiple moving objects (so multiple emitters)? As the emitters have to be parented to the solver, I'd have to make the emitters be in the right location and orientation. So I'd make a script for the emitters to move to the right places?

And second question; 
How do you trigger fluid emitting via script?

[josemendez]

Two questions though; what would be the "cleanest" way to have different liquids come out of multiple moving objects (so multiple emitters)? As the emitters have to be parented to the solver, I'd have to make the emitters be in the right location and orientation. So I'd make a script for the emitters to move to the right places?

Depends on what kind of simulation you're after. If you want to simulate in world space (makes the most sense in your case imho), you can just have the solver at the scene's origin and place your characters under it, with the emitters parented to their sword.

Note that emitters don't need to be direct children of a solver, it's enough for them to be in the same hierarchy. Colliders can be anywhere in the scene.

If you don't want the characters themselves to be below a solver, you can use position constraints to move the emitters together with the swords.

In any case, you don't need to write any code.

And second question; 
How do you trigger fluid emitting via script?

You just set the emission speed:

Code:

emitter.speed = 2; // emit fluid at 2 meters/second.

// later...
emitter.speed = 0; // stop emitting fluid.

let me know if I can be of further help,

kind regards

[aardworm]

Thanks again for the prompt and detailed explanation!!!

I have one more question out of the top of my head. Is there a way to make the liquid sticky and not the surface? I found that I can set the collider's surface to be sticky, which is great. But I have multiple kinds of liquid running off of a body. Meaning, I can't set the stickiness of the body but have to control it via the liquid's properties. Or maybe I'm missing something?

[josemendez]

I have one more question out of the top of my head. Is there a way to make the liquid sticky and not the surface? I found that I can set the collider's surface to be sticky, which is great. But I have multiple kinds of liquid running off of a body. Meaning, I can't set the stickiness of the body but have to control it via the liquid's properties. Or maybe I'm missing something?

This works the same way it does in Unity's physics engine, and most existing physics engines: using collision materials.

You can set a collision materials for both colliders and fluid emitters. When fluid comes in contact with a collider, their respective materials will be merged to get a single set of collision parameters (friction, stickiness, etc). See:
http://obi.virtualmethodstudio.com/manua...rials.html

When a collider or fluid has no collision material, zero is assumed for all collision parameters: zero friction, zero stickiness, etc.

So answering your question of "making the liquid sticky and not the surface": just set a sticky collision material for the emitter instead of (or in addition to) the collider.

kind regards,