Hi Bobo, I followed every step you described, everything seems to work, but at the end Pflow particles behave very wierd, sometimes they just dont show up, sometimes freeze at 1st frame, sometimes (like at the picture) leave a wierd trail, while krakatoa particles (purple) remain good… here is the sceneand particles (Max 2009 64 bit Krakatoa1.5.1.38002)
This is because the particle count is changing between frames and some particles must die.
Try adding a Krakatoa FileID Test to the flow and send particles out to an event with a Delete operator. This should remove the “trails” of particles that used to be in earlier frames but are not there anymore. I just tested this here and it worked ok, let me know if you see any other problems.
EDIT: I cannot get your files, I am behind a firewall that does not allow me to download any ZIPs from file sharing sites. Not even from our own support forum
Hi everyone, Bobo, thanks for the solution, after applying File ID Test trails realy dissapeard, but some artefacts are still present, I attach a test animation:
at the left there is an original character, at the right krakatoa particles(green) and Pflow(red) on top of each other, notice the missing Pflow at the top, i’ve ran a number of tests and this problem remains, checked this on three machines and 2 different versions of Max, what I noticed though that the pattern of this artefacts stays exactly the same on different machines and versions of max, while the only thing I shared between them are krakatoa particles, another thing I noticed – when you play animation in the viewport the artefact dissapear, while when rendering, making priview or moving time slider – artefacts remain the same…
Are you sure the PFlow is set to 100% in Viewport and Renderer? Also enable the particle count display in the PFlow and compare the number of particles in the flow with the PRT Loader number shown in the viewport.
If you can, zip it all together, rename the extension to .zippie and email it to krakatoa-support AT primefocusworld DOT com to my attention.
Checked what you said, everything is at 100%, the count of particles is really different, a bit later will send you files as well
Got the files, sent you an answer, but I will post it here too, because it is not trivial.
In short, when the PRT sequence was saved, the ID channel was also saved, but ended up with a value of 0 for every particle. The Krakatoa PFlow operators try to use the ID channel to distinguish between particles, and when there is no ID channel, they use the Index (the order) of the particles to decide which to create, which to keep and which to delete.
But when the channel IS there and its values are 0, they get confused.
I checked my own test from yesterday and it turned out that it did not have the ID channel in the PRT sequence (although I don’t remember why ;)). That’s why it worked in my test and I did not mention it.
So the possible solutions are:
A) You can resave the PRT sequence without the ID channel and let the PFlow operators use the Index. That will solve the problem but requires a bit of time to update the files.
B) You can add a KCM on top of the PRT Loader and set it to an Input node reading the Index channel wired to the Output node set to ID channel. This will update the ID channel to match the Indices of the particles in the PRT file and solve the problem using the existing PRT files without resaving.
So, the general solution in the future is not to save the ID channel.
I intend to write a tutorial about this and will make sure to emphasize that!
Thanks for your interest in Krakatoa!
Btw, I wanted to mention that all this can be done with the Evaluation version of Krakatoa without a license, so everybody reading this thread is welcome to download it and give it a try (it is addictive :twisted:)
Thanks Bobo for your reply.
Is it also possible? After loading back particles via PRT loader and if I want to place any object on those particles? (without using pflow, like your mr proxy script for pflow)
Maybe I wishlist this feature in PRT loader. (something object scattering tab in prt loader?)
We have something like that, but it does not place objects, it places their meshes. It is not part of the shipping Krakatoa version though.
You CAN place an object per particle using a script in the current Beta which gives you scripted access to the top of the stack particle channels. I might write a script that uses that to distribute mr or vray proxies that way, it sounds like a good idea… It would be like a very advanced version of a Scatter object and with the power of KCMs on the PRT Loader stack, you could do pretty crazy things…
Yes exactly, becoz current limitation of pflow with mentalray (mostly it takes lots of time in translation when used motionblur in mentalray) , I would love to have cached particles and replacing them with shape instance (mr proxy) with variation in shapes scale, rotation and position. That would be really nice and handy tool for Krakatoa. I asked coz maybe if it can take advantage of Krakatoa coding (I mean can impletemented at a core level of krakatoa) instead of maxscript.
Thanks again.
Quite unlikely, for many reasons.
First, the core development plans are already made for a year ahead and are usually stretched by surprising production needs.
Second, we don’t use mental ray in production so we don’t integrate Krakatoa with it (and the next version will bring it even farther with the new shadows implementation).
Third, if it can be scripted, it is destined to end on my plate
For those who are interested, I wrote an article about some generell voxeltests on my blog: http://www.bilderzucht.de/blog/?p=7