Sorry to interupt, but are we there yet?
Thanks
Al
Wait for a v2.0 announcement around Siggraph. We might or might not be there by then… but we would like to be.
hey bobo, there’s any way to reduce the wheight of the .prt files… they are hard drive eaters!. if i delete some channels this may reduce it?
Are there any ways to reduce the size of EXR files without losing data? 
PRT files use the same concept as OpenEXR - it ZIPs the data stream on the fly, so the files are already a couple of times smaller than raw particle data. Saving only the channels you need is one way to reduce the size. The content of the data also plays a huge role - static particles have a Velocity channel of [0,0,0] which zips greatly, but the moment the particles start moving, the channel becomes different per particle and the file size goes up naturally.
It is just the nature of the beast. With images, you can probably live with reduced quality (JPG) by throwing away data. In PRTs, you want to keep the data as it is if you want the right results.
There are some things we are researching to allow for better workflows and potentially saving less particles and producing more at render time, but no procedural approach can compare qualitatively to explicitly provided data.
Since Disk Space is cheap compared to Time in real-world production, buying more TB of server space is considered a better alternative than having artists spend days waiting for PFlows to recalculate. Thus we prefer to dump huge amounts of data to disk once and massage it in post to get the right results. In Avatar, there was a “false color image” of the Flux Vortex fields around the Tree Of Souls seen on one of the 3D screens which was made using several million particles reinstanced and heavily modified via Path Deforms and other modifiers using a large number of PRT Loaders. So one possible approach to reducing storage usage is to find ways to recycle existing particle sequences by loading them multiple times and deforming them with modifiers or modifying their appearance using KCMs.
If you have specific ideas and technical solutions, please let us know.
Hi guys,
Been out of touch with Krakatoa for a few months. Today I was opening a old file that I was testing a few months ago, and the very handy Krakatoa GeoVolume mod, seems to have vanished.
I assume I was working with the Beta version at the time.
It was a very neat mod, cos I could just select a bunch of objects and apply the mod to them all.
Was there a reason for discontinuing it. Sorry if this already been covered in the forum.
go to the Geometry tab => Krakatoa => PRT Volume i think thats what you are looking for
Yeah, it seems to do the same, as the modifire, but can only select one object at the time.
Select all the objects you want to fill, then click the Geo button on the Krakatoa toolbar.
We wanted to show the particles in the viewport and be able to run KCMs and Deformation modifier on top of the PRT Volume. This was tricky to impossible with a modifier which worked at render time only.
As Chad said, customize your Krakatoa toolbar and use the dedicated macro script to create multiple PRT Volumes from multiple geometry objects.
I did try the Tollbar button, but it didnt quite help as it creates one PRTVolume per object.
On my old file I had over 3000 spheres that I applied the GeoVolume modifire, instancing the whole thing, so any changes were updated in all of the objects.
I just thought it was a great feature to have, and would be fantastic if you could add it as an alternative to the PRTVolume.
Cheers
There’s a reason for that, too. This way, the levelset for the volume is created in the bounding box of each sphere. This can save a lot of memory.
If you really wanted them to all be handled together (like if they overlapped a lot anyway), you could always just attach them together into one object.
Also note that there are other ways to get many spheres to do what you want.
First of all, you can use a Particle Flow or TP with Sphere shapes. In the former case, you can create a Mesher and make a PRT Volume out of it. In the latter, you can pick the TP system as PRT Volume source directly.
If you have a pre-keyframed spheres animation using some other method (like Reactor or PhysX simulation), you could dump the positions, velocities and radii/scales of all spheres to a PRT file using the MAXScript Particle Stream interface, then load the resulting PRT sequence in a PFlow with Sphere shapes and use the Mesher/PRT Volume method as described above.
In fact, I wrote myself a Blob Mesh modeler by using a large amount of Sphere Atmospheric Gizmos that would get exported to a PRT file by just hitting a shortcut (using a simple MacroScript). The resulting PRT was then meshed by our inhouse PRT Mesher so I could just move some Spheres around, hit a button and get an isosurface out of them on the fly…
And here is the result:
Thanks again guys.
Sorry, but I probably didnt quite explain myself properly. I actually want each of the spheres to be turned into a buch of particles. See the original setup on the post bellow:
http://forums.cgsociety.org/showthread.php?t=758476
The spheres are animated, simulated in Realflow.
I could use the Geo button, but if I later want to adjust the settings would have to delete them all and apply it all over again, as they are not instanced.
Cheers
No , you explained it well. It is possible that I didn’t explain myself well.
I just proposed that you dump the info about position, rotation, scale and possibly the Radius of the spheres to PRT via MAXScript, load that in PFlow and recreate the SAME animation using particles driven by the Spheres.
Alternatively, you could write a Script Operator to read the data from the scene objects and create one particle per object, using the corresponding geometry as shape, then update the positions of the particles using the positions of the spheres.
This will give you a single PFlow Mesh representing all spheres with their motion and geometry, and you need a single PRT Volume to turn the whole system into a cloud of particles, like seen in this example (which used Thinking Particles though):

So I’ve started playing with Krakatoa for rendering pflow particles. I’ve got an object going over water and have create water spray. I’m using about a 1m particles. What I’ve noticed is that the pf source keeps updating itself making it very slow as its only using 1 cpu core, is this correct or can it be speed up?
Reading the documentation and doing the introductory tutorial might have answered that question, but here it goes:
This is a PFlow limitation.
*If you are constantly tweaking the look of the PFlow, you have no alternative - it will be slow.
*If you are rerendering the same frame of PFlow without making changes to the flow itself, PFlow should cache the particles and render instantaneously.
*If you are happy with the look of the PFlow and want to tweak lighting, shading etc, you can save the flow to a PRT sequence and avoid the recalculating.
*If you are happy with the look but want more particles, you could partition the flow to create multiple sequences that accumulate to more than 1 million.
Using the Output Scaling feature of the >Iterative option in the Main Controls rollout, you could also render a lower resolution image with a fraction of the particle count to get a much faster preview while tweaking. See this page for details.
Hope this helps.
Hi there,
I’ve recently started digging into Krakatoa and I’m experiencing a little difficulty.
I have a particle emitter that’s Path constrained onto a spline and I am trying to save a sequence of Krakatoa .prt files of that animation. I’ve done so and it saves the particles, but not its animation along the spline. Is there any way that I can do this?
Thanks a lot