This is the first time I’ve been able to play with this wonderful plugin. I put together a pretty simple X-Particles setup, and wanted to put it up to see if I’m doing this right.
Thanks again for allowing me to play with this amazing software.
Shawn
And another one.
Smoke_Trail.mp4 (3.37 MB)
Very nice!
How many particles have been simulatied to achieve this look? And would you share your settings? So we can all learn from each other.
Cheers
Simon
Sure thing. I’ll get some particle counts and settings up here as soon as I can.
Thanks
Here are the settings for these two files. I used X-Particles for both. The falling particles scene gets up to 3 million particles, while the Trails scene hovers around 1 million give or take a thousand.
Let me reiterate something as it might not be clear:
We don’t recommend using the “Override Density” spinner for several reasons.
First, “Override Density” is an absolute value for the whole scene. It will destroy incoming Density if the particles have one. For example, if you are using PRT Volume, each particle has a fractional Density value so if you change the particle count per voxel or tweak the spacing, the total density per cubic cm remains constant. Same with Repopulation where the new particles get a fraction of the original density. If you check “Override Density”, EVERY particle in the scene will be be overwritten and those subtle or not so subtle adjustments Krakatoa has done for you would be gone.
Second, the “Override Density” has a limited precision. You cannot enter a tiny value like 0.000000001 because C4D spinners won’t let you.
So in general, we recommend using the Final (and Lighting) Pass Density spinners. These values are MULTIPLIERS to the incoming Density values, so they don’t override the Density, they boost it or reduce it but retain subtle differences.
You get two values - one is the base, the other is the exponent. The result is Base * 10 ^ Exponent, in other words 5.0 Exponent -1 means 0.5. And 1.0 Exponent -9 produces the above tiny number. Positive Exponents produce large numbers, like 1.0 E 6 produces 1,000,000 or one million. So if you simulate with 1 million particles and then increase the simulation to 10 or 100 million, you just have to change the Density Exponent by -1 to reduce 10 times or -2 to reduce 100 times, and your final render look will be retained (10 times more particles with the same per-particle Density which defaults to 1.0 will of course produce a more dense cloud, so you have to counteract by scaling the final density accordingly).
The only reason we even have a Global Density Override is historical. Some RealFlow BIN files contain a Density channel which has a completely different meaning in RealFlow and is often 0.0. Such files would come in Krakatoa as invisible and people were unsure what was going on. This was before we had Channel Modifiers and Magma and stuff. So we added that option to allow users to override the Density and see all particles, often just for debugging purposes 
In the mean time we fixed our BIN reader (at least in KMX) to rename the BIN “Density” channel to “RF_Density” or something like that so it does not affect rendering…
Of course, it is up to you to use the controls as you want, but it is my job to educate 
Thanks for the clarification. That was a lot of math, but I think I’m beginning to wrap my head around it.
Does the density of the particles come from the emitter then?
Not necessarily, but it could.
Most particle systems in C4D, Max and Maya have no concept of Density Per Particle as it relates to Krakatoa. So we make the assumption that every particle that does not tell us anything about a Density channel has a value of 1.0 units per cubic system unit (cm in default C4D settings).
In the case of Krakatoa PRT objects though, esp. PRT Volume, the value is already defined by the object. If you set the Spacing to 1.0 cm and produce 1 particle per voxel with no jittering, you will have a grid of particles where each particle will have a value of 1.0 because it is alone in a 1 cubic cm voxel! But if you enable Jitter and increase the number of particles per voxel to 10, each particle will be set to 0.1 so that a 1 cubic cm voxel still receives 1.0 total Density…
A PRT sequence coming from another application could contain an explicit Density channel, so a PRT Loader could have its own Density per particle, but in most cases there isn’t one and the value is once again assumed to be 1.0.
You could use the Viewport Color Gradient in a PRT Loader, or define a color gradient in X-Particles, or use some of the TFD channels to do a color gradient and then copy the Magnitude of that channel into Density using the Magnitude Tag to vary the per-particle value over time.
Each Krakatoa Source has overrides for Color, Emission, Absorption and Density, so you can have a constant value for all its particles, but it can be different from the value of another Source object. For example, if you want to have two PRT Loaders of the same sequence, both without a pre-defined Density, but the one to appear 10 times less dense, you can simply override its Density to 0.1 in the Source Setup tab itself. But if the sequence does contain an explicit per-particle Density channel that is not 1.0 and you still want one of the two PRT Loaders to appear 10 times less dense, you can add a Channel Scale Tag and scale Density by 0.1 to preserve the original channel and only multiply the values instead of overwriting them…
Pretty much the same applies to ALL channels that affect the rendering, including Color, Emission and Absorption. They don’t necessarily exist in the actual Emitters (except Color), but are assumed White, Black and Black by default if not defined in the Emitter. They can be overwritten per Source, loaded from disk if saved in a PRT sequence, scaled per Source, or overwritten globally with a single value…
Hope this helps.