Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  OnParticleCollision
#1
Hi.I have a question on OnParticleCollision.Is it possible to get collision between 2 obi fluid?i get collision from obi rocks ,but not from obi fluid.Sory for my bad english.
Reply
#2
(29-01-2020, 09:09 AM)palad333 Wrote: Hi.I have a question on OnParticleCollision.Is it possible to get collision between 2 obi fluid?i get collision from obi rocks ,but not from obi fluid.Sory for my bad english.

Hi,

Fluid particles do not collide with each other. Density constraints (not Collision constraints) are used to try and keep the mass in the vicinity of a particle constant.

Collisions are only used between solid (granular) particles.

What do you need this for?
Reply
#3
(29-01-2020, 09:17 AM)josemendez Wrote: Hi,

Fluid particles do not collide with each other. Density constraints (not Collision constraints) are used to try and keep the mass in the vicinity of a particle constant.

Collisions are only used between solid (granular) particles.

What do you need this for?

Thanks for a quick response.
I need get collisions betwen lava and water,vaporize lava and water ,and create on this place rocks.Now i use trigger collider for this,but it is not perfect solution.
And one more question.
How can i restart solver after changing blueprint in my emitters? i need to change particles count to on device in runtime
Reply
#4
(29-01-2020, 09:26 AM)palad333 Wrote: Thanks for a quick response.
I need get collisions betwen lava and water,vaporize lava and water ,and create on this place rocks.Now i use trigger collider for this,but it is not perfect solution.
And one more question.
How can i restart solver after changing blueprint in my emitters? i need to change particles count to on device in runtime

There's no notion of "lava", "water", or any specific material labels in Obi. It does not make sense to have those for fluids. Unlike granular materials, fluids are not discrete, but continuous materials that just happen to be approximated in a discrete way. Do not think of fluid particles as "drops", but "windows" into a continuous field: fluid properties are not only defined in the particles, but at any point in between them.

All material properties are copied to particles when they are emitted, and evolved during simulation. You can read fluid data (density, vorticity, or diffusion data) at any place and moment and act accordingly. Take for instance the ObiFoamGenerator component: it spawns diffuse particles in places where fluid density is low and vorticity is high. It doesn't use collisions to determine when particles "touch" each other.

In your case, you could give your particles a "temperature": there's four custom diffusion channels for each material, that you can use in any way you want. Make lava hot and water cool, and generate rocks when temperature is medium.

See the Raclette demo scene for an example of this: temperature is mapped to viscosity: hot->viscous, cool->inviscid. The fluid is initially cold, it falls on a hot plate, gets hot, melts, slides down and then touches a cold plate where it gets viscous again.

The FluidMixing demo also shows how to use the custom diffusion channels, this time mapped to particle color using the ObiFluidPropertyColorizer component.

Allocating memory at runtime (specially for large amounts of particles) is not recommended. Use a blueprint with the maximum amount of particles you expect to have in your scene. Blueprints act as particle pools, so only the particles actually emitted have any impact on performance.
Reply
#5
(29-01-2020, 09:48 AM)josemendez Wrote: There's no notion of "lava", "water", or any specific material labels in Obi. It does not make sense to have those for fluids. Unlike granular materials, fluids are not discrete, but continuous materials that just happen to be approximated in a discrete way. Do not think of fluid particles as "drops", but "windows" into a continuous field: fluid properties are not only defined in the particles, but at any point in between them.

All material properties are copied to particles when they are emitted, and evolved during simulation. You can read fluid data (density, vorticity, or diffusion data) at any place and moment and act accordingly. Take for instance the ObiFoamGenerator component: it spawns diffuse particles in places where fluid density is low and vorticity is high. It doesn't use collisions to determine when particles "touch" each other.

In your case, you could give your particles a "temperature": there's four custom diffusion channels for each material, that you can use in any way you want. Make lava hot and water cool, and generate rocks when temperature is medium.

See the Raclette demo scene for an example of this: temperature is mapped to viscosity: hot->viscous, cool->inviscid. The fluid is initially cold, it falls on a hot plate, gets hot, melts, slides down and then touches a cold plate where it gets viscous again.

The FluidMixing demo also shows how to use the custom diffusion channels, this time mapped to particle color using the ObiFluidPropertyColorizer component.

Allocating memory at runtime (specially for large amounts of particles) is not recommended. Use a blueprint with the maximum amount of particles you expect to have in your scene. Blueprints act as particle pools, so only the particles actually emitted have any impact on performance.

Thank you, I understand, I worked in Houdini for several years, I just needed to know more details.
Reply