Krakatoa Beta 12 Discussion Thread

We’d like to use this thread to discuss specific new features in 12 - they were mentioned in the download thread, but since we don’t have the documentation ready, you might have questions about how to use them…


GENERAL



  • Finished refactoring of the Particle Streams system to allow adding and removing custom channels.

This has no direct influence on the surface (yet), but affected the handling of particles under the hood, so watch out for any bugs and error messages related to particle channels, loading/saving/rendering. Our experience with the build is that everything worked smoothly, but we could have missed some cases...


  • Added support for Custom and Factory Defaults.
    • Custom Defaults can be created from the current GUI settings using a new button in the Preferences rollout.
    • When a new instance of Krakatoa is created, these settings will be used to initialize all settings.
    • Another button in Preferences removes the Custom Defaults and reverts to Factory Defaults by renaming the INI file with the Custom defaults from .INI to .BAK
      o The custom defaults can be edited manually in the INI file if necessary

This was requested on the forum a week ago and is now implemented. Go to the Preferences rollout and look at the two new buttons. The main idea is to be able to set up your GUI as you like it for typical work, then press the "Save Current Settings As Defaults..." button - all relevant settings will be stored in an INI file in the Max Plugcfg\Krakatoa folder. Next time you assign Krakatoa as your renderer, these settings will be read and assigned to the renderer as startup defaults instead of the factory defaults we have encoded in the script. So for example if you want your particle color to be Red, Lighting and Motion Blur enabled, Shutter Angle 360 instead of 180 and Segments 8 instead of 2, you can adjust these once, save the defaults and then you will get these settings preset whenever you start a new Krakatoa project.

This also saves the rolled up state of all rollouts (except for the Preferences and About rollot) so you can set up your GUI as you want it and save the defaults to have for example Matte Objects rollout always open on startup and so on...

Note that some settings will not be saved - for example the drop-down list selections or tool settings of the Particle Systems and Loaders rollouts - these are not saved with the Renderer and thus cannot be handled by the defaults mechanism. It only handles values stored in the Renderer instance.


RENDERING AND SAVING



  • Added support for Near and Far Camera Clipping Planes

We needed this for a project we are working on - it means that you can slice through a volume of particles and render portions of it by just setting the Camera's Custom Near and Far planes to matching values. You could also render multiple slices by shifting the near and far planes in multiple renderers and try to comp them together with stuff between the layers (as Chad was proposing to save layers in an RPF file).



PRT LOADERS



  • Added Particle Density Source drop-down list to use Saved Density, Material Opacity or Both


  • Expect more options to be added in the future, for example we feel that "Use Global Density Only" would be cool to have as you might not want to use what is saved or any material. For now, you can get this behavior by assigning a material with 100% opacity and using the "Material Opacity" mode.

  • Added Playback Graph option and spinner to control animation playback using keyframes.


  • This behaves just like the PointCache2 Playback Graph option. You can use it in two manners - either set it to a non-animated static value, which gives the option to keep a single static frame throughout the whole animation (sort of like "Load Single Frame Only", but with a spinner control which frame to use!), or keyframe the spinner to define a custom animation. For example, if you have an animation of an explosion over 100 frames, you could ping-pong the animation by setting a keyframe with value of 0 on frame 0, 100 on frame 50 and 0 on frame 100 - the explosion will play back at double speed from 0 to 50 and then backwards from 50 to 100. To reverse an animation, just set a key with value of 100 on frame 0 and a value of 0 on frame 100.
    And so on.
    Note that the Frame Offset is still taken into account, so if you keyframed a custom animation in the Playback Graph but wanted to shift it by 10 frames, you don't have to move the keys up in TrackView (although you could), but can just change Frame Offset from 0 to 10.


  • Added display of Particle Count (Disk, Render, View) in the GUI
  • Added display of Particle Count in the Viewport next to the bounding box.


  • Note that the label buttons >Disk, >Render and >View actually control what value is shown in the viewport at the corner of the bounding box. The values in the GUI will update only when you change some spinners or press the Update Info, but not when you change the time slider. To see the actual values, always press the Update Info button.

    The Disk value is read from the headers of the PRT files so it does not take long to acquire. The Render value is calculated from the Disk value based on the Percentage spinners. The View value is what is actually being drawn in the viewport, so if you disable viewport display, it shows 0.


    • Added an option to specify the particle display type - Small Dots, Large Dots and Velocity.
      • Small Dots is the mode used by PFlow and Krakatoa 0.9.10
      • Large Dots is the mode used by Krakatoa 0.9.6
      • Velocity is similar to Lines in PFlow (but orders of magnitudes faster). When there is no velocity, no particles will be drawn. PFlow switches automatically to small dots when the velocity becomes 0, but this is time expensive and thus not supported by the PRT Loader. If you want to see static particles, switch to Small Dots.

    I did a test with 800K particles in PFlow and PRT Loader. Our lines display is 30 times faster and about as fast as the Dot display in both PFlow and PRT Loader. But if your particles are not moving at all, no particles will be drawn IN DIRECTX MODE. In SZB they show up as single dots, but nobody works in SZB anyway. So we decided to not try to fix this - if your particles are static, don't switch to Velocity display.

    We will add tools for mass-switching all the new properties in PRT Loaders to the Particle Loaders rollout in the next build.


    I will continue with the rest of the features in a separate post. If you have questions or comments regarding 0.9.12, please feel free to post to this thread.

    Weep for the SZB. It was the only way to show large masses of particles without them “clumping” as DX and OGL do. I still use it in max 8.



    Ok, so why is the velocity display faster? Because only moving particles are displayed, or is there something special about lines? If its the latter, can’t you just make static particles show as lines that are, oh, about 1 pixel in length? I have no idea what goes on under the hood, so I’m just thinking out loud.


    • Chad

    Ok, so why is the velocity

    display faster? Because only

    moving particles are

    displayed, or is there

    something special about lines?

    If its the latter, can’t you

    just make static particles

    show as lines that are, oh,

    about 1 pixel in length? I

    have no idea what goes on

    under the hood, so I’m just

    thinking out loud.



    No, we are displaying ALL of them as lines. It is DirectX that refuses to draw a line that has a zero length (in other words, if the two points are coincident, the particle just disappears). We tried to add a slight difference to the positions, but the result was a flashing cloud of particles because DirectX would draw some and not draw others depending on how much screen pixel they cover - you can get the same effect by using PFlow Lines with a very low speed, around 0.1 or something…



    The reason it is much faster is that we don’t draw polylines but segments. PFlow draws a single polyline representing up to 16 particles at once, with every second segment invisible. It is 16 times faster than drawing each particle as polyline, but still orders of magnitude slower than drawing segments. I guess there must have been some reason why Oleg decided to use polylines vs. segments, but we will have to ask him.



    When the speed becomes 0, PFlow replaces the line with a dot marker, that’s why it still shows particles when they are not moving in DirectX. We decided not to add an if test for each particle’s velocity, as it would slow down the general redraw. If you want to see static particles, you are free to switch to dots. If you want to see velocities, then, well, a velocity of 0 will display as 0 and only SZB will draw it as a dot, DirectX will show you nothing…





    Cheers,



    Borislav “Bobo” Petrov

    Technical Director 3D VFX

    Frantic Films Winnipeg