Hi
First of all: It’s awesome to finally have Krakatoa in Cinema 4D! Just did some quick tests last night with 300.000 x-particles rendered as ca 110.000.000 Krakatoa particles on my mac book pro! Thats insane
Feedback:
C4d: 15.037
Osx: Mac Book Pro, 10.8.5, 8gb ram
I’m experiencing pretty hard crashes now and then when test rendering. Full reboot is only solution. It’s not possible to kill the c4d process in neither Activity monitor nor with the terminal (‘kill -9 CINEMA 4D’) Even with modest particle counts. No discoverable pattern so far. (See attached crash log)
No progress bar in the statusbar when rendering to viewport.
Can’t specify log file filename in render settings ‘Logging section’ I think the dialog box is for choosing files, not saving. Writing full path by hand works.
If no output path is defined in the native c4d output tab when rendering to files, c4d issues default warning about files not being saved, even though output paths are defined in the Krakatoa output tab. I don’t know if you plan to keep the separate file output system or tie in with the native c4d output system. If you plan to keep it, you should consider overriding the c4d warning message.
I had a similar problem when trying to stop a render while it was “Preparing”.
I had to force quit, and then reboot.
I then tried again and realised that C4D was still accumulating RAM after I Stopped the Render.
I left it for an hour, and the render had stopped without a problem.
So it doesn’t seem to be a Memory leak, but the inability to stop the process.
I propose to check Activity monitor and look at the RAM if this happens again.
Have not seen any issues on Windows, except where expected - requesting too many particles causing a lot of swap disk usage, or passing incorrect values (which in Beta 1 is easy, but is totally fixed for Beta 2 by limiting all values to valid ranges).
It was missing the {SAVE;} flag in the filename control. This is fixed for Beta 2. In fact fixing it yourself in the existing Beta 1 would be trivial.
Krakatoa uses its own OpenEXR library implementation to ensure the output is unclamped on all platforms. I just realized the original developers set the RGB Beauty output to JPG so I changed that to EXR too. The main idea of Krakatoa’s own output is to ensure everybody is always outputting EXRs and nothing else. No other file format makes sense for Krakatoa rendering.
Of course we are aware of Adobe’s legendary inability to support industry standards like OpenEXR in AfterEffects correctly, so you might end up using something else out of C4D, but if you are serious, you would have to run NUKE or Fusion to get the best results compositing your renders…
As for the suppression of the native C4D messages, we will have to investigate if that would be technically possible. It is logged as a bug/wishlist item.
After some more testing with beta 2, it’s obvious that the crashing i was experiencing, is only related to cancelling a render in progress. It seems that Cinema is struggling to cancel ram intensive renders (Or at least ram intensive Krakatoa renders). I’ve done several tests with 50-100 million particles. If i cancel one of these renders, Cinema pops the warning about aborting the render, and then becomes unresponsive after i close the message box. I can see that Cinema keeps allocating ram to the already cancelled process. Sometimes i’m able to kill the process, sometimes not. Haven’t seen any patterns yet. I’ve tried to wait to see if anything happens after 20-30 minutes, but the process just keeps allocating more ram until the computer becomes completely unresponsive.
It seems that the default value for “Shell thickness” in the Krakatoa PRT volume object is rather high (10000000000 cm) In MY it’s 5 and in MX it’s 1.
Thanks! Keep in mind both C4D and Krakatoa try to be well multi-threaded, and I heard from our developers they had a lot of issues even poping up a simple License dialog as a child process of the main application - it was causing threading issues. We will look closer and try to figure out what is going on. I haven’t experienced this in Windows, but it does not mean it would not happen there too. I am just a bit more conservative when it comes to extreme settings, and if I see that my RAM is going up the roof, I kill C4D alltoghether
True, it came this way from Uglykids. The good thing about having a huge value is you can change/ animated the Start to shrink/grow the whole volume without leaving a hole inside. Setting it to 1 or 5 assumes the user wants to produce a thin layer. Both assumptions are valid. But I will make it default to 10cm or something like that to stay consistent with the rest of Krakatoa.
