Psys demo 2: Location Emitter and Mesh Emission

So i fiddled around a bit more with the idea of having attributes but decided against it.
It added a lot of complexity and work-arounds into the mix and seemed like an overkill
for now.


Here's another video showing a comparison between location emitters and Mesh emissions.

Psys: demo 2: Location Emitter and Mesh Emitters from bhavesh pandey on Vimeo.


So for now I have decided to focus more efforts on implementing Ray-Triangle intersection
routines for the particles and hopefully implementing an accelerated data structure for fast neighbour
lookups (but nothing too elaborate).
Maybe another weekend.

Psys demo 1: AABB

Ok, so I have added a kill() routine as well as another routine to compute an
Axis Aligned Bounding Box for the Particle system along with another routine to
draw this AABB.

Psys demo 1: AABB from bhavesh pandey on Vimeo.

Now, I would quite like to implement 2 more things into this.
1) Ray / Intersection capabilities akin to Houdini's Ray SOP for basic collision detection etc.
2) An accelerated data structure for fast neighbour lookups.

After this I'm pretty sure I'll have most of the things I'll need for the time ( :D )
I would like to spend some  time cleaning the code and then profiling + optimising it further
along with some other projects I have in mind.

Will post another update later..

Ciao.

Psys..particle system library

Well, so I have been tinkering with the idea of creating my own particle system library (yes..yet another library for particles! but I intend to try and implement it a bit more like Houdini's pops..or rather I'm hoping to!!) to be used with OF as a personal project. Also I like the idea of developing something I will be comfortable using knowing that it tries to be consistent with the way Houdini works (i.e with respect to the workflow) and I can use as a base for other projects I will be undertaking later on.

Well so here's how the design goes (very rough and brief):

There's a ParticleSystem which contains emitters. It can have any arbitrary number of
emitters in it which is setup by the user.
Emitters are only used to emit into the  ParticleSystem. They do not manage
or care about particles only about how particles get emitted, their initial velocities
initial positions etc.
Kind of like Houdini's Location/Source pops inside the POP context which can have any number of emitters in it and all the emitters care about is Emission of Particles.
To keep things simple I have not yet implemented any deletions or killing
of particles but its kind of inevitable.

Also I have taken care to make it such that the result is always reproducible
using same seed values (which does take some extra steps).
At the moment there are 2 emitter types supported.

1. Emitters akin to Location POP: They have controls for defining initial position of particles and intital velocities. As well as an activation flag which can be turned off to stop the given emitter and a jitter scale which just adds in some jitter.
2. Emitters akin to Source POP:    These use any triangulated mesh and emit particles from it. Theres support for inheriting colors from the mesh as well along with all the other features of the former type.

I've also designed a templated Attribute class for these but they are proving a bit tricky with all the different value types. One idea is to have pre-defined vectors to hold each value typed attribute
etc and push each attrib in relevant vectors.

and then set/get using specialized templated procedures.

But I'm still trying to get to a better solution for this.

Anyways this is a screenshot from what I have been able to get so far:

(Most of you should recall the openVDB dragon!)

The particles here are emitted from a base mesh with colors set on it.
The Emitter class just detects if the base mesh has any colors and if it does
it inherits it.
The particle have a basic perlin noise applied on them as a force and thats about it.

I intend to implement the killing procedures and then it would more or less have
what I'll need for the time being.

Render-time Resolution Scaling of Smoke/Volumetric Effects

Sometime back we finished a show where the smoke was not looking as detailed as we would have liked. I then started working on an asset which is an attempt towards resolving this issue.

This asset is able to work on low resolution simulations modifying/adding more detail on it.
It uses the velocity of the fluid to advect the fluid (density field) and add some displacements (along a divergence free vector field calculated at render time) all at render time and is virtually resolution independent as the higher resolution volume is procedurally created from the lower resolution volumes.

For the following tests, the only fields cached out were:
1) Density
2) Velocity
3) Temperature

This approach sort of bypasses the need to resimulate at higher resolutions and
can be divided on the farm much like any ordinary rendering jobs (since the method does not require any information from/about the previous/next frame )


Rendertime UpResing of Volumes, comparison. from bhavesh pandey on Vimeo.

Will do a few other tests as well and update later.

Fire and Water interaction ( Evaporation, Condensation etc )

This is one project I did some time back before running off to a splendid holiday with family.

These are few tests where Fire and Water simulations interact with each
other simultaneously .i.e both these elements are simulated together at the same time
in a single setup (which uses a bunch of microsolvers to move/communicate/manipulate the data around).

In the following video we have fire heating up the water and churning it up as well
as water evaporating at the boiling point.


Boiling Water from bhavesh pandey on Vimeo.

In the video below we have, fire inside a fictitious cold container (sounds ridiculous, I know)
which causes condensation as well as evaporation of water which gets heated beyond the boiling point (as can be seen in the form of smoke trailing behind the heated water).





This is quite interesting, since the usual approach is to simulate these elements separately and then stitch them together after the fact.
I have a few other tests and would be updating on this soon (hopefully....)

Cheers....

Render-time Up Resing of Volumes / Volumetric Data

I have been thinking about some posts on here, but couldn't really squeeze out any time for it. Been quite busy with work.

Anyways, I have been working on a tool which scales the resolution of the volumes at render time.

I'm still working on this tool, trying to refine the whole procedure / logic and trying to get a higher fidelity in terms of movement, base shape preservation etc.

Here's a test using a simple low res smoke sim: