thanks to you and johnny, really appreciate the input! i guess instead of doing a brute force amount of particles I could cut the initial amount down and partition it out. Always good to learn the nuisances .
Krakatoa
I’m using Krakatoa for the first time, and was wondering if there is any way I can optimise it to decrease the generated file sizes ie. anything that I have missed that is being output unnecessarily.
A single partition (pflow driven by fume with a 750,000 particle spawn rate) is leaving me with 15GB used over 200 frames.
I just want to make sure this I have not missed anything - all I have done is set the particle colour, no other settings enabled (mblur, dof etc.)
Cheers
What channels were saved to the PRT sequence? Most probably you don’t even need the Color, just the Position, Velocity and possibly the ID channel (but it depends on what you will be doing with the particles later, so Position and Velocity might be enough). If you are doing Partitions, you could skip the ID.
By default, the channel layout (“Save Channels”) is set to Position, Velocity, Density, Color, Normal and ID, or 36 bytes/particle. Removing the last 4 channels leaves you with just 18 bytes/ particle, or half of that. Keep in mind the PRTs are zipped, so the actual size reduction might not be the same, but it should help.
That being said, Krakatoa trades off disk space for direct access and thus speed. So it is kind of expected to have a Terabyte disk for just partitioning…
Exactly what I needed - cheers Bobo.
It was exporting the default channels, so it’s now down to half the size.
Just a short note that Krakatoa v1.6.0 is now available for download from our website:
http://software.primefocusworld.com/software/products/krakatoa/download/
As always, you can run it in Evaluation mode without time restrictions, with the only feature limitations being watermarked output at resolutions above 480x360, no network rendering and disabled Bonus Operators in PFlow (Krakatoa Collision, Krakatoa Geometry Test and Krakatoa Geometry Lookup).
All other functionality is identical to the licensed version and should give you enough room for training or rendering small YouTube tests.
If you are an existing customer with valid support contract, you will be getting your new license shortly.
Have fun, share and enjoy!
Congrats on 1.6, your point releases are more like full version upgrades, I wish other companies would follow your stride (the only other that I can think of that come close is Chaos Group) 
BTW about our support contracts, do you generally let us know before they expire?
That is a question for Sales - you should email Deirdre to check, but I think we do.
As for the versions, they are just numbers, after all.
We decided to follow a scheme like C.J.M.B where
C is the Core version
J is the Major version
M is the Minor version
B is the Build number (based on Subversion)
In other words, 1.x.x means we are still running the same core as the original Krakatoa release, since we haven’t done a full refactoring yet. When 2.x.x comes along, it will be a rewrite the way Brazil 2 was.
The Major version number saw a huge jump from 1 to 5 last year because 1.2.0 did not feel right for the amount of features added. We played with the idea to jump to 2.0.0 with it, but we missed the time window, and probably for the better as the current versioning makes more sense. On the other hand, 5 to 6 was more of an evolutionary step, some multithreading here, some shadows and render elements there, some enhancements to existing features, but nothing with the scope of MagmaFlow or Voxel Rendering we saw in 5.
The Minor versions are for bug fixes. 1.5.1 fixed what was broken in 1.5.0 and added some bells and whistles. There might or might not be a 1.6.1 depending on how many bugs we have missed.
The Build number is not Krakatoa-specific, it includes all code submissions to SVN including Deadline, Awake, Flood and all internal projects and scripts. So it changes quite rapidly. In theory, if we find a minor issue in the current 1.6.0.43178, we could release a 1.6.0.43xxx that fixes it without bumping up the minor version counter…
Thanks, will do.
As for the versions, they are just numbers, after all…
Interesting approach and duly noted 
5 to 6 was more of an evolutionary step…
Agreed, this release has some real handy workflow enhancements IMO
Hope you guys get to take a short break after all the work you’ve done before you start freaking me out again with cool stuff, still trying to get caught up with 1.5 
Bobo, I think you should have adopted Autodesk’s naming and gone by year, and while you’re at it you may as well skip ahead another year… Krakatoa 2012! :rolleyes:
Autodesk has made me seriously confused about what year I’m actually living in with their early releases :twisted:
Can krakatoa import FTC (foam) or MTC (mist) files generated from realflow 5’s hybrido fluid solver through the PRT loader?
No, only Particle BIN files in the RealFlow 3 and 4 formats. I have heard that RealFlow 5 BIN files continue to load in Krakatoa, but we don’t support RF5 officially as it was released too late in our development cycle. If the FTC and MTC formats are documented and contain point data, we might look into them in the future.
Awesome! I’ve just downloaded the evaluation version. 
I’m having a problem with PRT FumeFX. I can only see half of the FumeFX sim in the viewport/render.
Any clue what might be causing this ?

No clue.
Is this FumeFX 2 or 1.2? In the latter case, it would be interesting to know whether v1.5.1 would “see” all voxels or not. I wonder if it would be possible to peek into the values in the sim (Fume has some display options to show the data content in the viewport) and see whether Smoke and Fire are 0 or higher everywhere. But I have never seen anything like this.
Was this scene created from scratch? For example, if you had an early Beta of Krakatoa (1.5.2) installed and made it with it, some parameters could have stuck in the parameter block and caused the viewport limit to affect both the viewport and renderer or something. I have seen this in the past. But if you created the PRT FumeFX fresh in 1.6.0, then I don’t know.
Can you start from scratch in an empty Max scene, create a fresh FumeFX, create a fresh PRT FumeFX out of it and see if you can reproduce the same result with exact steps? If you manage to repro, please post the steps.
I wonder if it would be possible to peek into the values in the sim (Fume has some display options to show the data content in the viewport) and see whether Smoke and Fire are 0 or higher everywhere.

Yes, it’s FumeFX 2. I had the older version of Krakatoa, but I had never used it in this scene because of FFX2 non compatibility. I also tried merging the FFX container in a new scene and creating a new PRT FumeFX, but the same.
Although i get some warnings in the Krakatoa Log:
WRN: fumefx_particle_istream::load_voxels() - Failed to load some channels from .fxd file "G:\FFX_Temp\eod_kaboom\FumeFX01_0029.fxd"
WRN: The requested channels were: 0xa and the recieved channels were: 0x8
I have Fuel, Smoke, Temperature and Velocity channels in my sim. Also I can’t see any dots (particles) in the viewport for the first frames of the sim (0-15). If I create a new scene from scratch (not the explosion i made, just a simple source), it works perfect.
You can do it with a KCM - the color channel gets displayed in the viewport, so if you take the channel data, map it to 0-1 and use that as texture coords of a gradient, it should work. There is an example doing the gradient thing in the Krakatoa documentation, you could start there and modify it, should work 
Hah, I totally misread what’s quoted and what’s posted
anyway - nice explosion shape you got there 
