Hi,
Is there a tutorial somewhere about creating a PRT volume and using it as an initial state of a PFlow event (applying forces, collision, etc.)?
I get the concept of creating a PF source then saving and rendering using PRT loader but I’m having problem going the other way around. It looks like it’s possible. I must be missing something.
Thanks.
I’ll give it a shot…
Create a Krakatoa PRT Volume add your object
Open the Krakatoa UI
In the 'Main Controls' Rollout - Switch the default render mode from Render Scene Particles to Save Scene Particles
In the Channels Rollout - Choose any additional channels you wish to save (in most cases the defaults should be fine)
In the 'Save Particles' Rollout - Select your output path
Since you are using this as a birth object you should only need to save out 1 frame. Go back to the Main Controls rollout right+click the 'Save Particles' Button to see that you are set to render a single frame+current Frame number. Click the 'Save Particles' button to save out the single frame. A dialog will popup to confirm what channels your are about to save and what frames, click 'Ok' to save the particles.
In the Particle Loaders Rollout - Click 'Create New Loader'
This by default will create a new PRT loader at 0,0,0 and open up the Choose PRT Sequence Dialog, choose the PRT sequence you just saved.
While the Krakatoa UI is still open and you are working in it, switch the render mode back to either Particles Or Voxels. Doing this now may save you from accidentally writing over you particle sequence.
Open the Particle View and Create a standard flow
Remove the Standard Birth operator and replace it with a Krakatoa PRT Birth operator.
Select the Birth operator and click the button labeled 'None', now choose the PRT loader that contains your single Frame PRT sequence. A confirmation dialog will popup and ask if you wish to set the Render Visibility State of the PRT Loader, since you are loading these into Particle Flow you may want to choose yes to disable it, or at the very least don't forget to switch it off before you render.
I thinks that's about it.
EDIT: BTW PFvfx, great work on Avatar! 
I am going tonite for the movie. Can’t wait to see it.
Congrates Primefocus for being part of such great movie.
hi…
i need a hellp on how to render realflow cash with PRT loader
and use the velocity to color (with gradient ramp)
there is any tutorial on how to create this effect?
thanks
yuval kolton
There are tutorials on how to convert velocity to color with other particles (loaded from PRT or using PFlow directly) as well as tutorials on how to color particles with a gradient based on Age/Lifespan and FumeFX Temperature.
Assuming the data in the RealFlow BIN file contains the necessary channels, the approach should be similar.
Of course, I have no idea what is in the BIN files, so YMMV. Have you actually TRIED to do something and failed, or are you just hoping someone else will do all the work? 
If you can provide a simple sample particle BIN file, I could take a look to see if it would work or not.
Thank you JohnnyRandom.
Also found this tutorial that helped me understand the process a little more:
http://software.primefocusworld.com/software/support/krakatoa/using_prt_loader_birth_and_update.php
I am making progress. There seems to be a lot of back and forth between Max and Krakatoa (setup - save particles - load particles - modify particles - save particles - render particles)
No, there are no such tutorials (yet). I think it is a great idea, but it requires two things - Knowledge and Time. I currently lack the latter, but I hope this will change in the future.
hi.
im trying to render particles inside a alley and i need the walls to cast the sun shadow on the particles… the walls are matt object and its working with particles but not with voxels…
anyone can hellp?
thanks
yuval
Matte objects should cast shadows on both particles and voxels as long as the light has the Shadows checkbox turned on. Not sure why you are getting what you are getting.
If you can create a simple example scene that shows the problem or can provide exact steps to reproduce the issue, please post a bug on the Krakatoa support forum.
and thank you bobo for your patience… 
here is a image that show the problem with voxel.
hope it gives you enough information on the scene…
thanks
yuval
Yes, I could reproduce the problem, this looks like something that will be fixed in 1.5.2 (sometime next month I hope).
In the meantime, here is a workaround:
*Switch to “Particle Rendering”.
*Switch to “Save Particles To File Sequence” mode.
*Enter a sequence name in the Save Particles rollout.
*In the Channels rollout, check the “Calculate Lighting And Copy Lighting Channel Into Emission Channel When Saving” option - this will add the Emission channel to the list of channels to save.
*Make sure all relevant channels like Color and Velocity are included.
*Save the frame or sequence of frames to PRT.
*Now hide all particle sources you had in the scene.
*Create a new PRT Loader at the origin of the world and load the sequence you just saved.
*Check >Ignore Scene Lights and >Use Emission.
*Make sure the rendering of PRT Loaders is enabled.
*Switch back to “Render Scene Particles” mode.
*Switch the renderer to Voxels and render
The lighting calculated and saved in Particle Mode into the Emission channel will now load and render the Voxels with the correct matte and shadows. Effectively, we have baked the lighting of the Particle Mode into the PRT file sequence and we can now render in both Particle and Voxel mode without lights to get the same lighting solution.
I know this complicates the workflow and eats up a lot of disk space, but until we provide a fix for all known bugs (the list of the already fixed ones is quite impressive) in the form of a 1.5.2 update, it will get you going…
Sorry for the inconvenience!
I am working on a simulation right now, as i save my particles of the scene into the disk. It takes almost 10 min. to update the particles although once the updation is done it doesn’t take too long to save the particles Also as i have taken 10 mil. particles in my scene and gave 5 partitions to it, it updates the particles everytime it finishes one partition which is again a pain stalking for me due to more time consumtion. and infact render them but its taking hell lot of time while updating, can anybody tell me if i reduce that time ?
What if you decrease the amount of pflow particles, and use many more partitions? Try using 1 million particles and render out 50 partitions… in theory you should get the same basic look but it will spend less time updating when it goes through the pflow update calculations.
Hope this helps,
And/Or write out 1 PRT add to a new loader and Partition the PRT loader 5 times, 10 times, 50 times, or whatever. The only update you will deal with then is the PRT loader instead of Pflow.
Also possible to Cache Disk or Cache Selective(if you have enough ram) if you have box#3.
Sure,
Setup up your particle flow as usual and save it out to a single PRT like you normally would. Main Controls -> Save Particles to File Sequences, big SAVE PARTICLES button method.
When finished saving, add a new PRT loader and add the freshly saved Pflow data to it.
Turn off your Particle Flow emission now.
Open the Krakatoa UI and Go to the Save Particles Rollout create a new save path so you do not accidentally overwrite your existing Pflow save data.(it won't write it over anyway when writing partitions as the naming convention is different but if you happen to press the big button on accident you could hose some frames)
Go back to the Main Controls rollout and uncheck all but the PRT Loaders.
Go to the Partitioning rollout, choose the amount of Partitions that you would like to generate and press the Generate All Partitions Locally button or submit to Deadline.
That is about the gist of it.
Now you can load all the new partitions you just created to your original PRT Loader and then re-partition those 10 times too if you like So basically I just started with a simple Pflow setup that created 7015 particles total, less than a twenty second it was saved to a PRT, it then took less than 2 minutes to setup and save the next 5 partitions, I repartitioned it again into 10 partitions at less than 4 minutes, I now have 1 million particles in a little over 5 minutes. Of course that being a low number in Krakatoas world but saving out 1 million particles from the same pflow setup took approx 10+ minutes on my machine.
Uhm, sorry but this is just a good way to waste disk space.
The real trick is to add a Noise Modifier on top of the PRT Loader, set it to a very high frequency as described here, then enable the Seed modification of PRT Loader Modifiers in the Partitioning rollout (there is an option for that), THEN partition. The positions of the particles will be jittered around a bit and will create a more dense-looking cloud. BUT it will be a bit fuzzy. If you want really good results, going through the normal partitioning method is the way to go.
Btw reducing the number of particles per partition and doing more partitions will only speed things up if you use a renderfarm or multiple workstations to do the processing in parallel. Otherwise the cumulative time will be about the same.
Interesting, my whole point was just about eliminating the overhead of Particle Flow calculations at Krakatoa save/rendertime. So you are saying it is faster/better to Save to PRT with 50 million particles (or whatever million particles) from pflow over 10 partitions as opposed to saving 50 million particles once to PRT then generating 10 partitions off of a single PRT loader? You have 10 partitions worth of pflow calculations + writes as opposed to 1 pflow calculation to either Disk Cache or PRT Loader + 10 I/O read/writes.
I don’t see how it would be better to generate your partitions off of a non-cached object. Am I missing something?
EDIT: Also I had been meaning to ask, when using Deadline in Courtesy mode can the 2 machines be controlled by a host or is it host machine plus one? I am a little confused, I haven’t used Deadline since version1 and can’t remember how I had it setup and what worked.
It is quite possible that I am missing something
What I am saying is that you cannot really reduce the PFlow overhead if you want 50 million particles to flow through it. They will have to flow through it to get the best looking result possible. It does not matter how many partitions will be created, if the total count is 50 million, that’s how much work will have to be done.
Simply resaving a PRT Loader’s content multiple times without any modifiers does not change anything about the particles since partitioning requires some Random Seed to change aspects of the particle data (typically positions).
The workaround with a PRT Loader and partitioning it is that you can process only, say 1/10 of the particles through PFlow (5 million in this case), then produce 10 partitions with the particles slightly offset using a noise field. The result is NOT the same because 9/10 of the particles have NOT flown directly through PFlow, they are just randomly offset versions of the single partition that went through PFlow. But if the desire is to get higher volumetric density without using voxels and the fuzzy look is ok (for example for most kind of non-wispy dense smoke), then the PRT Loader partitioning is an option.
As for Deadline, it means two Slaves, Workers, Machines That Render, whatever you call them. Workstations submitting jobs haver need a license and never will. There is nothing controlling Deadline (as opposed to the Manager of Backburner and pretty much every other network manager). Deadline Slaves are smart workers and deal with the jobs themselves, thus the added stability since there is no central app that can crash and take the whole farm down. Your own workstation could be used both for submitting jobs and for rendering them, so if you have two PCs at home, that’s good enough to try it out.