We posted the Beta 7 build on Friday.
We invited a large number of new Beta testers into the final stages of the program.
4 days later, we have 8 downloads of the build and 19 views of the page, many of them from my machine
We are still finding most bugs in-house, so the question is - does the current version of Krakatoa work for you? Do you find any bugs in it?
Or does the current lack of FumeFX 2 support prevent you from testing the latest build? (we are working on changing that ASAP).
We are nearing the final stretch of bug fixing before we release Krakatoa 1.6.0 sometime around the end of the month.
If you are hitting any problems, now is the time to let us know!
does the current version of Krakatoa work for you?â yes
Do you find any bugs in it? ârarely
Or does the current lack of FumeFX 2 support prevent you from testing the latest build?âyes as for me anyway Krakatoa is stage 2 software, stage 1 being anything that drives the primary motion.
Because you are not supposed to use that large button
There is a Krakatoa Menu with much better controls to assign/un-assign Krakatoa and keep all settings when swapping renderers.
Same actions can be assigned to a toolbar or even keyboard shortcuts.
Anyone using the Render Dialog to assign Krakatoa or open the UI is not using it right
Why would you use Krakatoa with Phoenix? Isnât it wonderfully integrated with VRay already?
Keep in mind we have no insight into Phoenix, in fact I havenât seen it yet personally.
Been requesting Krakatoa integration already hehe. It is indeed very nicely integrated with VRay in many ways. Krakatoa on the other hand addâs a whole lot of flexibility on the other hand. As in tweaking the simulation, adding all sorts of offsets, retimings, go crazy on the sim etc. Even tho i really dig Phoenix, Krakatoa is something i use for different things and in different ways and it hurts to miss it for Phoenix sims
Ah, back on topic - so where is the bug report about that, I ask?
The switching between Krakatoa and other renderers will crash Max 2010 and 2011 if Compress On Save is checked because of a bug in Max where Render Presets get corrupted on 64 bit systems. Unchecking Compress On Save fixes the issue, but I can understand if this is not an option.
I reported this to Autodesk, but you know how long it will take to get this fixed. It is mentioned in the Known Issues topic at the bottom of software.primefocusworld.com/sof ⌠_notes.php
If this is the problem you are experiencing, please let me know.
I just added a workaround method for switching between renderers when Compress On Save is found enabled in 3ds Max 2010 64 bit and higher.
Basically, the system will switch to a âmemory slotâ storage scheme where the current rendererâs settings will be kept for the duration of the current 3ds Max session.
So instead of writing render preset files, it just keeps the renderer in a variable and assigns it back as needed.
If you restart Max, the memory slots will be empty and you cannot restore settings from a previous session, but still it is not a bad approach.
If you turn off Compress On Save, it will revert back to the original method with RPS files backup.
Ok, this probably is not a bug. I could just be having an off week.
Using 42948 with max 2010 sp1, I cannot get the effect as seen in http://software.primefocusworld.com/software/support/krakatoa/zdepth_pass_using_magmaflow.php to render. The âEmission set to expected float[3], ignore lighting, huge densityâ setup to get basically what the KCM Render Element does, just without the KCM Render Element. No matter what I do, I can only get grey values in the render, and they seem to be dependent on the density more than emission.
This might not be a bug, but it IS a new behavior.
In build 42948, the Emission Strength was separated to allow the âboostingâ of Fire from FumeFX independently.
So in order to achieve the same result as in that tutorial, you will have to set both Final Pass Density and Emission Strength to exactly 1.0/0, otherwise your final pixels might end up in a completely different color. In prior versions, there was no way to adjust the intensity of the Emission, and the Density was modifying it too. By setting both Density and Emission Strength to 1.0 and drawing with Nearest filter, you should get the correct color values in every pixel with Alpha of 1.0 and Emission exactly as calculated by the KCM. Note that if you want to scale the KCM value down 10 times, you can now set the Emission Strength to 1.0/-1 instead of changing the flowâŚ
Wacky. I was going to tell you that your method doesnât work, since it doesnât work in my scene, however it works fine in a brand new scene. So Iâm going to try to merge to a new scene and pretend this never happened⌠Thank you for the clear explanation, though. Iâm seriously having a bad week. Not quite over my post-SIGGraph cold or something.
The Krakatoa menu no longer crashes. Yay!
Unrelated, but the KCMâs no longer auto-rename for me. 2010 x64 sp1.
There might be something wrong, we will investigate. I have the feeling I have seen it stuck before, then working again. But since it is new to me too, I might be missing something.
Also note that the Render Element approach will draw 2x2 pixels per particle, while the KCM + Emission approach draws just one, so I would recommend the Render Element, or using the KCM flow in a Krakatoa CustomData element.
As for the menu, the next Beta 9 will also add support for the Render Elements storing/restoring when using the new Memory Storage due to âCompress on Saveâ being on. With that, switching renderers will be pretty much identical to when using RPS files, except that it wouldnât remember settings between sessions.
Why 2x2? Hole filling? Seems like a one-way street, you can easily bleed out to fill holes in post, but you canât un-chunky the points.
EDIT: Regarding the odd behaviour, is there an easy way to turn the whole Krakatoa panel to âfactory defaultâ? I was trying to figure out if I had accidentally thrown something.
First of all, when rendering in the latest build, the per-particle density MUST be 1.0. If a particle has a density of 0.1, it will output a higher emission, if it is above 1.0, it will produce lower emission. So Density Override with default white color should be enabled to ensure this.
Second, if you are rendering with Nearest filter, both the KCM RGB and the Render Element will fill one pixel exactly.
But if you are rendering the RGB with Bilinear or Bicubic, each particle will be drawn in 2x2 pixels, so the Render Element will fill all 4 of them with the same depth value. The particle is technically speaking affecting all of them, some more, some less.
If you enabled Filtering in the Render Element, the output will also be anti-aliased (which is a bad idea for ZDepth, but could be a good idea for other Render Elements like Diffuse and Specular).
So you have full control over the render element - 1 pixel, 4 pixels or 4 pixels filtered, depending on the Final Pass Filter and Filter Render Element settings.
Regarding resetting to defaults, switching back to the previous renderer using the Menu/Icons and then switching to Krakatoa and answering âNoâ to the question about restoring the last known settings will assign a Krakatoa with default settings. These wonât be factory defaults if you have customized the startup defaults using the right-clicking on controls menus or the Preferences options for storing all settings as startup defaults, but they will be the initial settings you would get when assigning Krakatoa to an empty scene. Alternatively, you can say
renderers.current = Krakatoa()
to assign a fresh renderer instance with statup defaults.
But given the above explanation about Density=1.0, that shouldnât be necessary.
