Finally I found time again to play with the new Krakatoa tools 
So the partitioning with tp works fine now and is super fast, only the seed does not change from session to session.
take a look at the attached images.
it also creates some render artifacts when particles have the same position. It’s visible on the voxel rendering, but I also had it on paritlcles, I just couldn’t recreate it in this debug scene.
Win XP x64, max2008 x64, TP3, Krakatoa 1.5.1.38002
For the first issue, did you cut the density of the PRT Loader by 90% to compensate for the spatial density increase of 1000%? ie, you have 10x more particles, you need 1/10 the density per particle to represent the same final density in the render.
I don’t understand the second issue. What am I looking at?
MatterWaves is implemented in a bad bad way and does not provide correct MAXScript access, so we cannot get to the Random Seed parameter.
Thus, MatterWaves are not supported by the Seeding code. If it were our bug, we would have fixed it. 
I will make sure it is noted as a known limitation in the documentation though.
When you have the same particles at the same position, you are effectively increasing the density, so shadow problems are to be expected.
You should lower the global Density based on the number of partitions, for example if you have 10 partitions, set the density to 1/10 of the original value.
Sorry for the inconvenience, we don’t have a workaround for the Matterwaves problem yet. We might try to access it via the TP SDK and see if we can get to it that way…
oh…I get that with the density. sorry…didn’t think that far 
Is it just the matterwaves that doesn’t give any acces or is it basically the whole TP?
in the second picture you see that there are 10 partitions, as there are 10 times more particles in the prtLoader than in TP.
So I have been doing more stuff, and saved Age and LifeSpan with tp to a Krakatoa cache and loaded that into a prtLoader. with a KCM I changed the color over life and rendered in additive mode. if you look at the render, there are some black dots. when I render without the kcm the dots are gone.
setting the draw point filter to nearest makes the dots a lot smaller.
is this something known?
As far as I have tested, only MatterWaves (specifically in TP 3) are affected. I don’t have a TP 4 copy to test but I suspect it is the same story.
Black dots could be caused by invalid division (division by zero) or other indeterminate operations like
Sometimes a channel might not contain what you think it would. If you right-click one of these pixels in the VFB and you see something like -1.#IND as a value, the LifeSpan of just-born particles might have been ended up being 0. You would have to ensure that the value of a divisor is never 0, for example by using Clamp or Boolean Logic operators.
Same applies to exponential functions using negative values and fractional values- see the black spots here:
software.primefocusworld.com/sof … g.php#Fire
In MAXScript and any programming language,
-1.0^0.5 --> -1.#IND
because this is asking for the square root of -1.
You can also dump the particles to a CSV file and explore the values using a text editor. Sometimes a channel could be wrong out of TP or PFlow to start with…
P.S. You can render to 480x360 or less to avoid the watermarks on the output image (mainly for YouTube uploads).
ok, will take a look at the pixel and channel values. thanks a lot.
unfortunately can’t talk about tp4, but I’m sure you will like the new stuff
We used the Beta while Riff was working with us on a couple of projects, but reverted to version 3 until 4 becomes the current one.
So we got the TP4 SDK and made sure Krakatoa works with it, but I don’t have it on my machine anymore.
you were absolutely right with the 1.#IND.
lifespan was 0 and clamping it to minimum 1 solved the problem 
thanks a lot!
