(Again chastise me if you don’t want feature requests here…)
I would love to see the Jitter Radius have X,Y,Z amounts. Ideally there could also be a checkbox to align the coords for this adjustable jitter with the velocity vector. So that way I could keep particles in a straight line along their vector, but vary their position… Or I could vary them out around their vector.
I would also love to see the presets feature from Frost added to Stoke. I am finding myself wanting to try a variety of setting without having to save different MAX files.
This is really more of a PRT Loader feature request… (And for all I know Max has some way to do this…)
What if you could take your particle sequence (like .bin files from RealFlow) and zip them up into a single archive. Then the loader could read the files directly from the zip archive. This would allow an artist to archive (zip) their particle sequences for faster network loading, and data management. It likely would have very little speed penalty and the I/O tends to be the slow part.
The system could transparently support zips of all the support particle file types. If you wanted they could have special file extensions (like the way a .jar file for Java is a renamed Zip). Though I think it might be best if it support files simply named .zip so people wouldn’t have to think about it.
This might have threading issue with WRITING, but I would think you could read them in parallel…
But what about bin files? Or would I convert them to prt files first? I know RF 2012 will write prt files as well, though something I read or something I watched was saying to use the .bin files form RF, and not the prts.
PRT files contain a zipped stream, so if you try to compress one with a compressor, you will get almost no benefit. Only the header of the PRT file that describes the channel names and some other data is uncompressed but that is just a few bytes.
Zipping all files into one big archive would have more negative implications - you wouldn’t be able to save multiple PRT files at the same time from one machine (Stoke) or multiple machines (Krakatoa+Deadline), you would not be able to easily replace one bad file by resaving it without having to deal with a huge multi-GB (sometimes TB!) file and so on.
BIN files are not compressed, but that makes their loading easier. Note that RF 2012 does not save PRTs correctly, but the next release will likely fix that (we informed NextLimit of the problems). So if you need your BIN data anyway, there is no reason to duplicate it as PRTs. But if you intend to delete the BINs, you could convert them to PRTs first. All you have to do is create a PRT Loader, open Krakatoa, switch to saving mode, specify the desired channels and frame range and resave. We might provide easier-to-use converters in the future.
OK. Here’s another more useful request… This is for PRT Volume… It would be nice if there was a limit memory to X setting… Why? Because when you drag on the spacing slider and accidentally get it VERY small then Max locks up, and tries to take down the whole machine with excessive paging! If there was a limit memory usage to X setting that would not let you set the spacing so low that it would exceed X Gig that could stop it. The user could set X in this case, or turn it off. This could save a default value for the system.
Luckily I caught it soon enough and was able to kill Max before the whole machine became unresponsive…
In Stoke… the Total Count (of particles in the Simulation rollout) would be more useful if there were commas in the numbers (or if it showed scientific notation, but I think commas would be more user friendly for artists). When you clicked on it, though, the commas could go away so that you could copy the value without commas if you needed to.
As is I find it hard to tell if I am created 10 million or 100 million particles, as it is hard to count consecutive zeros.