And The Answer Is...

42, of course!

When I started this blog, I promised insight into Krakatoa, MAXScript, Life, The Universe and Everything.
Well, there is no better time for that than this year. 4 days ago I turned 42, and for anyone who holds the Hitch Hiker's Guide To The Galaxy dear to his heart, this age sounds quite cool.

Except it probably isn't.

You see, the other day my parents told me they read or saw an interview with James Cameron and he mentioned he was still feeling like an 8 years old. Oh my, I told them, so I am older than The King Of Pandora!? I have always felt like 16, except when I was actually 16 when I felt like 20. Crazy eh?

Anyway, I don't think I will have more answers about Life, the Universe etc., but I can surely talk about the few things that I know about. For example we are beta-testing Krakatoa v1.5.2, so I might mention some things about it.

Probably the coolest thing that happened to this version (quite by accident) was the speed up that it provides to PRT Volume particle generation. We were working on something completely different (which won't be in 1.5.2, but I guess you will all get sooner than later) and discovered that our memory management wasn't working as expected. Normally, when loading particles from most sources like PFlow, TP, PRT sequences, Mesh Vertices etc., Krakatoa not only gets the particles, but it gets the actual particle count long before it has loaded a single particle. All these sources are able to tell Krakatoa "I am going to give you N particles" and Krakatoa can collect these numbers and reserve memory for all of them before it starts loading their data. (This is the case in the 64 bit build, in 32 bit half of the time it might not be able to allocate enough to fit them all in... Switch to 64 bit if you haven't yet!)

There are a couple exceptions to this - CSV files do not provide even a hint about the actual particle count of the incoming particles - the only way to find out would be to actually read them all, and since reading text files is slow enough, we just do it once and allocate memory as we go. Currently, the same applies to PRT Volumes. The PRT Volume could theoretically estimate the final count based on the mesh, voxel size etc., but it is a bit complicated with all the Shell options and testing against the mesh volume, so right now it does not report any expected count to Krakatoa.

The result of loading PRT Volumes in v1.5.0 and 1.5.1 was exponential slowdown as the particle count went up. We realized that this was due to many (and slow) memory allocations and decided to allow the user to allocate enough memory for a given amount of particles via some manual controls in these cases where Krakatoa does not know the final count. The result was quite mind-blowing. Creating 50 million particles with a PRT Volume went from 11+ minutes down to 17.5 seconds which is 38 times faster. When I reported this to our boss, he asked jokingly "Why not 40x?". So I tested 100MP and that was 92 times faster, so I guess everybody should be happy now. After closer inspection we realized that the memory allocation logic in the previous versions had some flaws, so we are working on fixing them in hopes to be able to get the same speedup without manual memory allocation controls.

Another quite positive development that has been on my Wishlist for a while is the addition of a Particle Input Stream. This allows anyone with basic MAXScript knowledge to open the render-time particle stream of a PRT Loader or PRT Volume and read particle data from it. For those of us with advanced MAXScript knowlegde, it meant the introduction of the Krakatoa Particle Data Viewer utility which can be used to peek into the particle data of a scene object. It lets you select a range of data to display, filter that data by any combination of search criteria, even filter by the value of the Selection channel which could be set by a KCM, thus allowing for filtering by arbitrary MagmaFlow logic! Finally, selecting one or more rows in the editor will highlight the corresponding particles in the viewport!

In MagmaFlow, we added Quaternion operators, the missing and quite important Natural Logarithm operator and fixed some bugs in the handling of nested BlackOps. Flows will now save a material library with any maps used by TextureMap Input nodes and will load them back when loading the flow. TextureMap Inputs can now show a preview of the selected map inside the MagmaFlow command panel. Connections to scene object will be restored when loading the flow if a scene object with the same name exists. Object references using the $ path syntax inside Script Input nodes are now supported for interactive updates. We have some more quite sexy operators in the works, but they might have to wait for the next major release, so I will stop here.
Related to KCMs, we are introducing two new MacroScripts - one for saving a modifier stack to disk, one for loading it from disk. This lets you create a whole bunch of related (or not so related) KCMs on an object, save them to disk together with any other modifiers found on the stack like deformers, Krakatoa Skin Wrap etc, then select one or more objects in the same or in a completely different scene and apply the same modifiers to them.

For the few people using the Presets and History dialog (according to our surveys, most users are confused by it, but I am unsure how to improve it, so I am open to suggestions!), we added two vertical icon strips for faster browsing of records by image. You can now just scroll the image strips and load presets or browse thumbnails, saved preview images or settings much more intuitively.

If you read my blogs, you probably remember my rant about how people don't use the MacroScripts with those colorful incons we provided? Well, we not only replaced the icons with slightly better ones, we also added a Krakatoa menu to the Main Menu bar of 3ds Max (which can be turned off in Preferences) so you can now access all tools and settings from there without having to customize a toolbar.

Initially, we wanted v1.5.2 to be a pure bug fix release, so we squashed a whole lot of bugs - you can read their obituaries here. At this point, we are in the same situation as with 1.5.0 which could have been called 2.0.0 without any problem - 1.5.2 could easily be called 1.6.0 since it brings quite a few new features too.

As mentioned, Krakatoa 1.5.2 is currently in Beta. If you have a commercial license and you want to test it but have no access to the Beta forum, let us know. If you don't have a license, you will have to wait a few more weeks...