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.
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…logically
- 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