Is it possible to use the fluid renderer without the fluid physics?

[ITR13]

Is it possible to either use the fluid renderer on a unity particle system, or to input the position, velocity, or acceleration of the particles based on a script? 
More specific, my usecase is that I have a burst/jobs implementation of boids that I want to make look "liquidy", and is considering Obi as a solution.

[josemendez]

Is it possible to either use the fluid renderer on a unity particle system, or to input the position, velocity, or acceleration of the particles based on a script? 
More specific, my usecase is that I have a burst/jobs implementation of boids that I want to make look "liquidy", and is considering Obi as a solution.

Hi!

The fluid renderer can only render fluid particles (you can't render arbitrary meshes), but you can drive fluid particles yourself, and you can deactivate any part of the simulation you're not using.

In Obi you can read/write any particle property (positions/velocities, as well as any other property) at runtime:
http://obi.virtualmethodstudio.com/manua...icles.html

Particle data is laid out in a SoA way (one array per property) and they can be mapped to NativeArrays for easy access from jobs.

You can also globally enable/disable any constraints you're not using (density, collisions, etc):
http://obi.virtualmethodstudio.com/manua...olver.html

So in your case, easiest approach would be to disable all constraints in a solver, emit particles programmatically and drive their data yourself using custom Burst-ed jobs. Full source code is included in case you'd need to tweak internals.

kind regards,

[ITR13]

Hi!

The fluid renderer can only render fluid particles (you can't render arbitrary meshes), but you can drive fluid particles yourself, and you can deactivate any part of the simulation you're not using.

In Obi you can read/write any particle property (positions/velocities, as well as any other property) at runtime:
http://obi.virtualmethodstudio.com/manua...icles.html

Particle data is laid out in a SoA way (one array per property) and they can be mapped to NativeArrays for easy access from jobs.

You can also globally enable/disable any constraints you're not using (density, collisions, etc):
http://obi.virtualmethodstudio.com/manua...olver.html

So in your case, easiest approach would be to disable all constraints in a solver, emit particles programmatically and drive their data yourself using custom Burst-ed jobs. Full source code is included in case you'd need to tweak internals.

kind regards,

Thanks!