My challenge now is to get a nice way of pushing about 200 MLN points through a simulation.
To cut the long story short I am collapsing something.
My initial workflow assumed:
Splitting dataset into manageable chunks
Running through Particle flow
rendering with Krak
My simulation is not really sophisticated and includes a few events:
[list=]
[]I have a 3D structure of points in space
[]Trigger gravity via animated noise map. Particles start falling down
[]Bounce them once off the floor
[]Bounce them 2nd time off the floor
[]Send to a new event
[]Drive with FumeFX smoke simulation
[/list]
Now I am thinking about adapting it to Ember/Stoke workflow.
So I would drive 1/10th of the particles through PFLow and Stoke it basing on full dataset and proxy PFLow.
In theory the weak points are:
I think there may be a problem with bounced particles. Assuming I have 10 particles hitting floor nearby w/ minimal time offset, they’d get averaged, interpolated and the source particle would not really bounce nicely.
I lose lots of resolution if I use FFX sim to drive Pflow particles (10%) and drive the rest basing on the proxy
I can easily get FFX field directly into Stoke, but I need to figure out if there is a way of capturing somehow the particles meeting certain criteria (bounced the floor 2nd time) and then disactivating Pflow driver and activating FFX Driver in Stoke.
Also, I am curious if it is possible to to a simple gravity fall down and bounce off the deflector w/out Pflow that I would obvioulsy like to avoid.
Can this be done somehow with Magma on top of Stoke?
Yeah, the collision will be the tricky part. We had a discussion yesterday regarding whether Stoke should support collisions either at particle level, velocity field level, or not at all. But right now we have no short term plan to add anything in that area.
Currently, it is up to the driver system (either FumeFX or PFlow) to deal with the collisions.
You cannot use Magma to modify Stoke particles during the simulation, only after the simulation. For example, it would be possible to check the Z axis of a particle against a ground plane mesh or just a Z value and if it is below, you could either set its Z to that value so it stops going down, or otherwise modify the particle (select it for deleting, or invert the Z so it starts moving up again). Unfortunately, the latter would not really look exactly like bounding off. So you really need your vector field to react to the obstacle.
I would suggest testing with a very low particle count of driver particles and relatively low particle count of Stoke particles to get a quick idea what it looks like. Then try to simulate a small region with 1/10th of the final count as drivers and full count of Stoke particles to check out the detail, and if necessary, tweak the spacing of the Stoke grid to adjust the detail…
Unless you are running Magmaflow in the simulation, ala Ember, doing anything complicated like that collision sounds unworkable. Doing such a setup in Ember right now isn’t all that great, as the options for doing field filtering are limited.
Seems like you could do a post-sim Magmaflow that made sure that none of the particles penetrated the collision object, but integrating the velocity changes from that with the sim would be impossible now.
It is a multi-event pflow system with a collision spawn in the system. The event001 particles are deleted upon collision, so any influence they have should be gone before there is any advection from the stoke particles on the teapot. AFAICT the Stoke system is grabbing the velocities from the second event.
More or less just demonstrating the use of a multi-event plfow system. Whether or not it directly correlates with what you are doing, well that is up to you.
Right now Stoke gets velocities only from the first event, but this is a UI limitation.
Stoke and Ember need an Event as input, we have to add the ability to select a whole system or a list of events.
But you can easily assign the second event to a node using MAXScript.