new user to stoke / magma /genome…awesome tools!! high five!
the top ‘flow’ is what I copied form one of the Youtube videos (is there a downloadable 1080 version?)
the bottom, active flow is essentially a Vector Noise BLOP, exploded and i added a Simple Fluid op with a blend…all good.
I am trying to animate the noise, but simple auto key-ing parameters like the Noise Offset vector, results in slow computer , so i am figuring there is a better way to animate the noise?
Possibly the simplest way would be to use the Noise texture map of 3ds Max which is a 3D procedural map with a Phase and everything you need. Just animate the Phase there
All you need to do in Stoke is create an Object>TexmapEval node, drag from the Lookup Point socket to make an InputChannel Position, pick a Noise map as the texture to evaluate, and connect the output socket to Velocity.
You can then manipulate the resulting vectors as you want…
The Phase is not quite like a Z offset, but you might be able to get something that looks nice by just shifting the noise vertically. (in 2D, a Noise map shifted along W looks very similar to a Phase change, but it is not the same thing).
Obviously, there is no phase in our Noise operators, so the other alternative would be to blend between two Noise operators -might produce similar results…
yeah…the blend might work nicely and solves another issue, of making the particles morph to a resting shape…good idea
on another note, I tried using RandomWalk and is just not playing nicely with stoke (spacewarp from BlurBeta), so I am running a Pflow with the random walk operator driving some Pflow particles.
I have seen you can save a Field, but how can i use pflow particles to generate one, so i can then throw some Stoke at it later?? i might need a third coffee to get my brain working i know
Actually, the Stoke category contains two special operators that can turn particles (including a live PFlow event) to a Field by splatting the channels onto a grid. This is exactly what the Stoke Particle Simulator does when you pick a particle system and tell it to use some grid spacing to drive Stoke particles.
The one operator is a general purpose ParticleSplat, the other is the PVelocitySplat which is meant for sampling Velocities and has a built in divergence removal.
What you did though is quite cool because it does not depend on the distance to the source particle - NearestParticle will find a particle somewhere, regardless how far it is, as long as there are more than 0 particles in the stream, while the Splat operators produce a grid where a voxel might or might not contain a particle (and thus a valid velocity).
well my result wasn’t that exciting , i did export the field out , first as a VDB (small files 800k) with a boring result, the particles in stoke spread evenly form a sphere, with little variation, not like the original Pflow.
Then I disabled the ‘normalize’ on the flow and exported as f3d (bigger files 11.7 MB) with a marginally better result.
So i have not done that much progress…but will try the splat.
Is there a way to clamp the field post loading it? or to exaggerate the velocity, so slower cells are made slower and faster ones faster?
forgot, also is there any pro’s / con’s to vdb / f3d/ or the other format??
Well, you did not really transfer the Velocity of your PFlow particles to the Field, you converted the Positions of these particles to new vectors. Basically it was like “find the closest particles of Pflow and draw a vector in its direction”. Thus, any particle in the resulting field will try to chase the PFlow particle like with a Find Target, not move LIKE it. Like with programming, the field does what you asked it to do, not what you thought it should do
You can load a field in Stoke Magma and do whatever you want to its channels. For example, using a Power operator can boost high values and reduce low ones. Let’s say you have a Velocity field where the Magnitude ranges from 0.1 to 10.0. You can take the Magnitude to the Power of 2, so that a value of 0.1 will be 0.1*0.1 = 0.01, a value of 1.0 will remain 1.0, and a value of 10.0 will produce 100.0. The take the input Velocity vector, Normalize it and Multiply it by the new Magntitude^2 and output as Velocity… You can clamp the Magnitude using the Function > Clamp operator (we even ship a BLOP called ClampVector that lets you clamp the X, Y and Z of a Vector at once, but using the above method where you split the Vector into Normalized Vector and Magnitude to manipulate them separately is probably a better idea).
You should be using VDB files, period. The Stoke Field Simulator uses them as its caching format. OpenVDB is just awesome.
Field3D is an earlier format by Sony, and it is supposed to do the same, but we support it only for data interchange with 3rd party applications. I have never used it myself and probably never will
FXD is of course the file format of FumeFX. If you are using Stoke to enhance FumeFX workflows, FXD is probably your format of choice for data interchange, since Fume does not read VDB yet, and its F3D implementation uses a custom compression plugin that we don’t support. FXD has limitations when used as a Stoke Field caching format, because it was designed to store only channels FumeFX supports (Smoke, Fire, Fuel, Velocity, Temperature) and not arbitrary named channels like VDB and F3D do. Also, it does not support negative voxel coordinates, so the grid gets shifted when saving and the FumeFX / Stoke Field Loader has to be transformed to load the data in the same place.
In many cases, you should be able to use a live Stoke Field without the need to cache to disk at all. When using Stoke Field Simulator, you will get a VDB sequence as a side effect anyway.
so i got a bit further, some good results , some odd results. Although i understand why i am getting this, the Stoke particles are simply drifting on parts of the field with no information…so they remain still.
you can see the particles stopping, and also a vertical pattern in some areas…is this the actual field…i thought it was a lot smaller than that grid?
This is what i am doing in the Stoke Field, i tried greeting a velocity channel, but the PRT (BIN from RealFLow) didnt have one(?) so i am using Pvelocity Splat to get it…is this dodgy? Can i have a brain implant so i know all of Magma?
What i am trying to do, is get a Real Flow simulation, which would be the boundary for a stoke simulation, to dfill with some sort of moving, non liquid fluid…to quote the client…but is proving hard!
I will explore how i can used a Frost mesh to affect the Stoke particles, to maybe react when they get close to it…even harder i know!
Thanks for the time you take to get this noob up to speed!!
*A RealFlow BIN file should ALWAYS contain a Velocity channel. How did you try to get it? The only way would be through the ParticleSplat, PVelocitySplat and NeatestParticle/ParticleSumRadius/ParticleQuery operators. In all cases you should be able to see a Velocity channel once you pass the particle stream to these operators.
*The PVelocitySplat and the ParticleSplat perform the same operation. The ParticleSplat gives you ANY channels available in the source, so to speed things up and use less memory, you should use only one of them.
*You should NEVER Normalize the Velocity channel coming from RealFlow, or from anywhere. Velocity values come in specific units (we use generic units per second), so Normalizing the value is the worst idea ever. You can scale it if needed, but not normalize.
*The Density channel of these Splat operators would be based on the amount of particles found on the grid. It looks like you were killing the Magnitude of all velocities to 1.0, then scaling by the Density. This makes no sense to me.
*Note that PVelocitySplat outputs a Density as a Float[3], while ParticleSplat outputs a Float as you correctly discovered. You could use only the PVelocitySplat in your flow if you insert a Magnitude node after the Density output. Assuming you want to keep the same logic, of course.
*If you end up using PVelocitySplat, make sure the option to Remove Divergence is UNCHECKED! It will both speed up calculations and import the particle data unchanged from RealFlow instead of trying to make it look more fluidy.
In general, Stoke particles will stop if the Velocity on the grid becomes zero (in PFlow, particles would continue with the last known Velocity). You could have a Krakatoa Magma modifier on top of the modifier stack to fade off the Density of particles to 0.0 when the Velocity > Magnitude approaches 0.0. But if you get the Velocities with their original Magnitudes on the grid, chances are the particles won’t stop as much…
