Some more thoughts regarding Krakatoa 1.0:
*When we say “Volumetric Particle Renderer”, we mean just that. The user has control over the density per particle, which means that the shading is performed with a consistent density regardless of the particle count. So you can create 10K particles, render a quick test to adjust lighting and shading, then bump up the particle count to 10 million and render, knowing that the result will be of much finer quality, but the volumetric density would be the same.
*The shading itself is really fast, the slow portion is usually waiting for a particle system to give the renderer enough particles to shade.
I just created a default Particle Flow, set the viewport display count to 0.1%, set the System Limit to 1 Million, created 1 million particles from frame 0 to 30 with speed of 30.0 and rendered frame 30. Particle Flow calculated the particles and then Krakatoa rendered them in 37 seconds. Once the particles have been calculated though, PFlow has them cached and does not need to recalculate again unless you change some operator. So one can change the view, add lights, change materials, tweak any Krakatoa-specific settings in the Render Dialog and rerender without waiting for PFlow to rebuild again.
So I hit render again and got the same result - 1 million particles - in only 6 seconds. Half of the time was shading, the other half was getting the data from PFlow.
So I bumped up the Motion Blur segments to 10 and rendered with 10 passes motion blur in 30 seconds, which means that the average time per shading pass was really less than 3 seconds for 1 milltion particles. Then I added a light to the scene and rendered again with 10 passes mblur - the time went up to 34 seconds…
Later I tried bumping up the System Limit and the Particle Count to 2 Million - after calculating the particles once, the shading with 10 passes mblur took exactly 60 seconds, which shows that Krakatoa scales linearly (as long as physical memory is not a limitation).
*To avoid the constant waiting for particles to be delivered, we allow the user to save to a PRT file instead of rendering to the frame buffer. Once you like your particle system, you can write it to disk once and then load from disk straight into Krakatoa for rendering.
*Since Particle Flow and most other systems have a certain limit of particles they can handle at once which is generally much lower than the number of particles Krakatoa can shade, you can generate multiple files from the same PFlow but with different Random Seeds for Position, Speed and Spawn operators, then load any number of these “partitions” and render at once as a single particle cloud. We provide tools to generate these files manually or automatically via our Deadline network manager. Deadline provides a free two slaves mode so anyone using Krakatoa could also use Deadline for running partitioning jobs.
*Since any particle system can be saved to a PRT file and any file can be loaded any number of times using special Particle Loader objects, Krakatoa can be used as an extended particle system design tool.
For example, let’s say you want to model a galaxy of stars. You can design dozens of animated suns using PFlow and spherical emitters, assign mapping and play with densities, sun flares and whatever, then save each star as a PRT file to disk. Now you could create ANY number of loaders (by hand or via MAXScript), each one loading one of the PRT files. (A loader can load any number of PRT files, even Realflow BIN files). You can even overwrite the colors using the material assigned to the loader object, keyframe the PRS of the loader to have each sun moving in space, offset the animation to randomize their look, control the number of particles to be loaded per loader and basically design a whole new scene consisting of hundreds of pre-saved particle systems without any calculation overhead (execpt for disk IO). Then Krakatoa can render the scene by simply loading all PRT files referenced by the scene loader objects…
Then you could save the WHOLE new scene with all its stars to a single PRT file and repeat the process to make an even larger universe! :bounce:
*The GUI of Krakatoa is written completely in MAXScript, so anyone who does not like it can basically rewrite it or change it at will. The Scripted GUI already provides some management tools that will save you from writing your own scripts to mass-change properties of particle loaders, create selection sets for matte objects and so on.
*The History system I already mentioned is the most advanced Render Presets system available for any renderer in 3ds Max (and possibly in any 3D application). Each time you hit the Render button, a complete record of all settings in the UI is saved, together with an optional copy of the final frame for thumbnail browsing. You can also load and save presets manually at will, with full control over each single setting to be saved or loaded. A sophisticated comparison system will show you the differences between ANY two history records, presets or the current settings and allow you to simply copy any of the saved settings to your current setup. For example, you can browse through your history list and find a thumbail that shows just the effect you need. You select that history record and you are shown a list of all the differences between your current settings and the settings used to achive that result. You can double-click each one of these differences to copy the history settings into your current GUI, or load the whole preset. Chances are your new rendering will look just like the one stored in the history
Are You Hyped Yet? :twisted: