AWS Thinkbox Discussion Forums

KrakatoSR Integration for CINEMA 4D

Anyone else there tried or is trying integration of KrakatoaSR for CINEMA 4D???
I am looking for the way to integrate KrakatoaSR for CINEMA 4D in easy way like plugin sort of, but script is OK though if I could
work with both powerful tool - CINEMA 4D and KrakatoaSR together.


1 Like

yes, KrakatoaSR will be fully integrated with the upcoming DPIT Effex v2.0:

nah, I doubt that, it will be only supporting the builting EFFEX generators.

We already had a talk about the problematics Cinema 4D holds, but still we are working on the release of your plugin, so there are no limitations on the Krakatoa side like access to all the render features and setting as well as full support for TP, external particle file formats etc

I would definetely refrain from buying a plugin that has Krakatoa added just as a feature to make itself look more shiny :unamused:

Take Care, Jong-Hyo



It will support not only own.

source - 

No, I meant RealFlow Particle bins for example, or geometry/meshes etc
 this is all only integrated in the the real Krakatoa plugin

Funny, if you look at plugin-cafe, Samir is working at it. and for example, screen shot has matte objects

it likes py/cython plugin(python search path in gui), i think it possible to hijack by py and make bin loader
 or Oreally pCache can load bin and re-transfer to tp.

Well, it looks like he just started working with the final release of Krakatoa SR, I started to work with the python build, that was the only available version back then.

Anyways, rest assured that “my” go at the integration will be feature complete, versatile, unlimited in features and not depending on anything but Krakatoa SR to work, and free;)

Great to hear that something is under way.
Hope to have the bridge between Krakato SR and CINEMA 4D soon.


You are welcome. We are working in it right now and it will be released asap.


looking forward to your plugin.
I just play with Samir’s DPIT2 integration of krakatoa and it basically works fine.
It is implemented as a Render-post effect so no compositing is needed.
You can create a scene, do a DPIT2-simulation and render it with whatever renderer you like, be it Iray, Vray, AR etc. As long as the renderer works really !! within C4D (not exporting the scene like Maxwell) , krakatoa (Effex) will be fired along with the rendering process and be added as post effect.
So, Samir’s solution works basically good.
But he skiped some (or better a lot of) setting-features that the ‘whole’ krakatoaSR offers, like in the shader-model. So, it is currently a very basic plugin.
Also I didn’t get a really nice shading with it so far, but that could be me, not the plugin.
But Samir’s DPIT2 offers an export of the particle-simulation in various formats, and gladly includes also the .prt format.
So, if your plugin is more complete with krakatoa’s features, we can export DPIT2-particle-simulations and then do a professional render with your plugin as longs as it doesn’t work separately, but can be combined in a whole render-process like Samir’s solution offers now.




rest assured that our official Krakatoa SR plugin will be complete and not as limited.


nice to hear.

In the meantime, here is some first very basic playaround with Samir’s integration in DPIT2:

Which would that be exactly? Let me know please. All features that KrakatoaSR offers are actually implemented (except for those that do not make sense as the particles do not carry information that are required to be processed by the shading models). So let me know which ones are missing.


Its taken care of already, so no need to change anything. The official plugin will be updated and available for free soon.

Samir, as I already wrote in the NaviĂ©-Forum in my ‘DPIT & Krakatoa’-Thread, I miss some vital parts of the Krakatoa-SDK in your post-effect-plugin.
Those are for example:

  • No feature for multiplying your DPIT-particles at rendertime within Krakatoa (‘Repopulation of existing particles’). Using DPIT itself for that kills mostly an animated scene because of the RAM-consumption.
  • No feature for ‘Matte Meshes, Holdout Masks, and Shadow Maps’ to render shaddows on non-particle-objects in the scene for a real visual integration. Therefore, all Krakatoa-rendered DPIT-stuff is hanging shaddow-less within the scene in the air (See my rendered examples above)
  • No ‘LightingDensityPerParticle’-feature. Only ‘DensityPerParticle’ is supported by you.
  • No option to choose between ‘Particle’ and ‘Voxel’-Render-mode.
  • Absorbtion-Color-feature could be better arranged to visualize the rendered targed color of the particles (see MX-Plugin, they work with two color-fields, one shows the absorption-color, the second one the color that the particles will have later when rendered, that is better to understand for the user)
  • No option to have ‘particles generated from objects’ with Krakatoa (Effex). DPIT itself does that painfully slow and even on a high-end machine like mine it is nearly impossible with using high-res objects.
  • No further settings within the particle shaders possible, only the default values seems to be used internally.



Hi (my answer from our forums),

Thanks first of all. Let me try to answer individually

The simple reason is that Effex will have an own ‘repopulation’ feature which is also multithreaded and not a render-only feature. There was a similar feature though to the v1.7 ParticleAttach clone feature for rendering. The repopulation feature of KSR is (last time I looked) not multi-threaded but more seriously only works for the Krakatoa rendering (one could convert to a KSR particle set, repopulate and use the result for new Effex particles and changing the current ones, but these are two steps that are not really necessary and cost valueable performance time that is simply avoided with an own solution).
This is a feature, considering Effex, that should be applicable to any particle set Effex supports (this includes cachers etc. which is especially important for exchange), that’s why it’ll be available in the simulation pipeline already (as other nodes in Effex also only applicable at render time if you want to). Actually it is already there, you can use the Sheet operator to fill wholes in the whole liquid particle body but our particle filler will have additional options.

Just because it’s not in the rendering interface, it doesn’t mean Effex doesn’t allow or support it. :wink:

Sorry I don’t know what you mean. Meshes are automatically matted (hold out masks). You can exclude meshes from being used as matte too. If you skip the rendering of C4D (there is a checkbox) you get exactly what KrakatoaSR renders, so you can do your compositing yourself. If you activate the multipasses you also get normal, velocity, occluded rgba & depth passes (though the depth pass is buggy in the early bird version). So all passes that KSR renders. Or what do you mean?

And according to the Krakatoa developers there is no feature in KrakatoaSR that gives you shadows. We would need to integrate shadow support for it on our own (based on a DSM file KSR can export), which we’ll do in the future (though it’s not yet a priority for the first version
however we have shadowing code available in our voxel renderer already and a DSM should be quite easily converted to our proprietary volumetric shadow map. But Effex parts are currently more important and time is short until release) but it is not a native KSR feature that we don’t support
the sdk simply doesn’t give us shadow rendering.
Please see the discussion here in the KSR forum: viewtopic.php?f=166&t=9402

If there is please point me to it and I will gladly add support. Otherwise I don’t understand what you exactly mean. Please elaborate. Thanks

Thanks. Yap, missed that one! Just added it. In the release version available then.

Simple reason, we have our own advanced voxel renderer which offers more and more specific feature support (as you can imagine). It’s the Gas Renderer. Just splat your particles onto a custom scalar channel and render that channel. We specifically added Krakatoa for its particle rendering (splatting) technique which is simply great, fast and a standard. But we have a highly multithread, highly Effex specific optimized voxel renderer on our own so we don’t need the voxel mode.

ok, that’s a feature request but not a native KSR feature is it? If so I cannot find it. Could you point me to it? Unfortunately, I don’t know the MX plugin so a screenshot would be helpful. Surely sounds useful.

Sorry, I don’t understand what you mean with this sentence. Could you elaborate?
You can render points of any meshable objects with the Effex Krakatoa implementation. Just drop the object into the particles field. Did you mean that?
Creating 14 Million particles within the volume of any object takes on my i7 quad core exactly 2.2 seconds. It could probably be worth looking into some further optimizations to gain some speedup but not sure which part is painfully slow for you (the whole emission procedure is 100% multithreaded)? Please be more specific so I can fix or change the behavior you encounter. Feel free to post a scene file.

Sorry I cannot confirm. We support the:

  • isotropic mode: no settings are available for this one
  • henyey-greenstein & schlick: we support the global anisotropy value, there is no other value for these phase functions. And we support per particle anisotropy defined by any Effex particle property, so the user has full access and full customizability
  • phong: we support the global specular level & power settings, there are no other values available. And we support per particle definitions of these. So fully customizable.

And it works all fine here. Please elaborate what exactly you mean so I can take a look. Thanks

even our beta plugin was more advanced than this
 seriously, and charging money for this is just plain cheeky

R-K, better stop wasting money or efforts and wait for the real deal

Hi Samir, thanks for the detailed reply.

Let me precise some of my points.

  1. Shaders:
    I meant the individual settings within each shader type.
    I attach the corresponding part of the SDK-documentation:
  1. Krakatoa-Shaddows:

here is the link to my question from the Krakatoa-Max-Forum concerning that point to make clear what I mean:
please look the answers here:

  1. No choose-option for Particle or Voxel-mode:

OK, but when I want to do a render with Iray or Vray, it would be nice to have it as I want to render all (DPIT-solution and the other Non-DPIT-scene-parts) in one step using Krakatoa as post-effect along with the main rendering (Iray, Vray).
The Gas-renderer is not available for Iray, Vray, I think ?

Look here at 8:25 min:

For the ‘particles generated from objects’ I will check and try what you wrote.

Best regards,


Tyler, I wait impatiently for the release of your solution :wink:


Thanks. Just as the sdk docs show we have all these settings available for the shading models we support, so I am still not sure what you mean I’m afraid. Could you further elaborate?
Please see my previous answer for details.

Thanks. yep, it just says what I wrote in my previous answer actually. DSM file etc

We support Vray’s own volumetric renderer by passing the simulation data to Vray with a special channel shader. That was also already possible in v1.5 btw and works a treat. Iray, I don’t know, never used it actually.

thanks, I’ll check it out.

Privacy | Site terms | Cookie preferences