AWS Thinkbox Discussion Forums

Getting that "PFlow" Fume Look

When seeding PFlow particles into a FumeFX simulation, this often results into a certain sharp and stringy kind of look (When rendered with Krakatoa). I played a bit with Stoke, but I wasn’t able to get anywhere near tht kind of look, no sharp tedrils at all but everything seemed a bit smeary. I am more than certain the reason is me having no idea on all the settings and possibilities inside Stoke, so it was great if anybody could point me into the right direction.

I’ve been following the Stoke/ FumeFX tutorials so far and I think seeding using a PRT FumeFX Object in teh Distribution source with the Velocity field of the fluid plus Liquid Behaviour could get me close…but no. Any hints were very much appreciated.

In general, “stringiness” is caused by the emission of particles at about the same position, but slightly offset in time. An obvious way would be for example to emit from vertices or edges of a mesh instead of using random points on a mesh surface, or the volume which produces generally more smeared results.

Yesterday I was playing with a setup that required that look and I ended up emitting particles only from the edges of a mesh to create obvious bands of particles that would stick together over time.

In the case of FumeFX, it might be worth it trying to use a Krakatoa PRT FumeFX object that creates explicit particle samples within the voxels of the simulation, and then using that as the Distribution source of Stoke. This way, you will have a discrete number of emission points you can control and even modify, and you can tweak the Jitter radius of the Stoke emitter to emit either from the same point (radius 0.0) or nearly from the same point (e.g. 0.001) to control the “stringiness” of the resulting particle streams. Assuming that the number of emitted particles is significantly higher than the number of seeding points, of course.

It is quite possible that the way we seed particles in the FumeFX voxels is different from the PFlow FumeFX Follow implementation. Also, the Stoke advection is generally more precise than PFlow integration even at 1 frame integration step, so the results can look different in that they diverge more than in PFlow.

Posting some screenshots or example scenes to illustrate what you are getting and what you want to achieve might be useful, too…

Thank you very much. Finally I had some time for getting back at this. It seems your suggestions are working quite well, using a PRT_FumeFX helper as Distribution source and playing with the jittering value gives results very similar to the PFlow FumeFX Birth/ Follow kind of look. I am still trying to play with how to control the number of emitted particles inside stoke.

There is a Particle Birth with a Rate/ Frame setting as well as a Source Rate in the Distribution tab and I am not sure how those two are connected.

The Particle Birth Rate/Frame options are used as follows:

Each Distribution object provides its own absolute Source Rate. For example, if you pick a Sphere and a Box, each one will get a default Rate of 100. But the default Rate/Frame under the Simulation rollout is set by default to “Total Rate, Relative Split”. As result, you enter 10000 in the Rate/Frame, and you get that value distributed between the active emitters proportionally to their absolute counts. So if both had 100 and 100, you get 50% and 50%, or 5000 + 5000. If you change the Absolute Source Rates in the Distribution rollout, the percentage will also change. These per-object values are also animatable, so you can animate the relative percentage as you want.
This is the default mode because it gives you one total count and if you keep on adding emitters, they will all split that count between them.

If you switch the mode to Total Rate, Equally Split, the per-object counts will be ignored and the Rate/Frame count will be split equally between all sources. This lets you quickly do equal distribution without having to touch the per-object Rates. You can animate the Total Rate itself, but the split will be between all active emitters. So if you picked a Sphere, a Box and a Cyllinder and disabled the Box, the remaining two will split the particles 50/50.

If you switch the mode to Total Rate, Every Source, once again the per-object counts will be ignored, but the Total Rate will be used for EACH object. So if you had the Box and Sphere and 10000 in Total Rate, you will get 20000, 10K per emitter. If you enable a third emitter, it will add 10000 more per frame and so on. This is useful when you have determined that a certain count is good for a single emitter, and you want to keep on adding more emitters that automatically get that optional count assigned without you touching anything else. For example, you figured out the best count for a single Sphere emitter. You clone the Sphere 4 times and pick all spheres as emitters. Instead of having to multiply the Total Rate by 4, you don’t have to do anything. If you clone some more and pick the clones, they will all automatically get the same count.

The last mode is Absolute Per-Source Rate. In this mode, the Rate/Frame is grayed out and the absolute Source Rate entered (and possibly animated) in the Distribution list will be used. So if you had the default 100 for each object, 100 particles will be emitted from both the Sphere and the Box. This gives you the most control since you specify the actual counts per object, but it is more work to enter (and possibly animate) all the values.

There is one more factor to consider - When the Distribution object is a particle system, you have the option to “Use Seed Count As Rate”. What this means is that if you pick a PRT Loader with 1234 particles, then Stoke will emit exactly 1234 particles. This checkbox overrides the Total Rate mode settings, and the Distribution list shows “Auto” in the Ratio column.
If the option “Use New Particles Only” is also checked and the PRT source you picked contains a valid ID channel, then particles will emit only once when they are first loaded, and then never again. So if the PRT sequence had 1234 particles on frame 0000 and then on frame 0001 it had 1240 particles where only 6 were new, only 6 will be created on frame 0001. This way, the Stoke particles will match exactly the count of the source system over time.

I admit that’s a lot of options, but I felt that they all have their place to provide both the fastest workflow in every situation, and the maximum flexibility when needed.

Privacy | Site terms | Cookie preferences