If I play with the additive mode and I switch off again, the particles remains always with the same color (black in my case) and if I try to change, even override color, emmision, absortion or nparticleColor, it ignores me and the particles looks always black.
The worst part is if I close maya and turn back again, the problem remains. So I have a corrupted scene with an animation of 2,5 million black particles, xDDD.
I uploaded the scene. maybe I’m doing something wrong, but I deleted fluid caches, nparticle caches, changed ppColorRGB and nothing, the particles remains black. testCalibrationKrakatoaMY.rar (17.5 KB)
Have you tried providing a light source? Like a Point or Spot light?
Krakatoa does not render colors unless there is an explicit light source in the scene.
I added a Point light and the colors rendered.
Force Additive is fully self-illuminated (Color is copied into Emission), so it will render colors even without lights.
Turning off the Force Additive goes back to Volumetric shading which requires a light to produce a Diffuse component.
In the Max version, we have a tool that is supposed to help in such cases. I will see if I can provide a similar Sanity Check tool for KMY - for example, it would answer questions like “why do my particles render black” by analyzing your settings and finding such Gotchas…
I apologize, in my test scene I had a spot light but I’m trying now and it’s ok. Depending on scale I need to crank up the intensity of the light around 500 in linear decay and use absorption and a very low density. Works perfect!
Sorry again.
I think that this help tool is not necessary, it’s very clear how works, only we must take care of the scale of the scene, Also, I’m sure you have other priorities.
Too late, I already started writing it.
The main reason to add a Sanity Check is that it took me longer than 15 minutes to figure out what was “wrong” with the scene, mainly because I assumed there was a light in the scene.
With the new tool, if there are no lights visible in the scene, the Sanity Check will warn you about it. In addition, it will provide tools to fix issues. (This is already part of KMX). For example, when it tells you that you can either create/unhide a light, enable emission or turn on Force Additive, double-clicking these suggestions will actually perform them. So it is a quick way to both debug the scene and fix conflicts of settings. Convenience is something that is a highlight in the Max implementation that is still missing in the Maya implementation…
Also, it will both help new users understand what is going on, and save us support time explaining to people why something does not look right.
Regarding scene scales. I have written about this before, but I will make it part of the documentation.
Basically, our volumetric shading is highly dependent on the scene scale.
The Density is expressed in units per cubic spatial unit. In other words, 1.0 is per cubic system unit. A system unit generally means nothing. In Max, the default assumption is that 1.0 is 1 inch, and you have the ability to adjust this in the scene settings, but it does not affect how Krakatoa calculates Density. In Maya, it appears that 1.0 unit is typically assumed to be 1 meter. This is mainly because Maya is double-precision while Max is single-precision, so anything stored below 1.0 starts to lose precision fast, especially when far from the origin, and is a bad idea in Max.
When I merge a mesh (like the Buddha demo) from Max into Maya, my object is around 200 units high, and the low default Lighting/Final Pass Density multipliers works well.
In Krakatoa, each particle carries a Density value which is accumulated in the final rendering. If no value is defined, it is assumed to be 1.0. Imagine you have the above Buddha statue with 200 units height and a Spacing of 1.0 in the PRT Volume. This means that normally (without subdivisions), there is one particle in every cubic unit. Thus the resulting accumulated Density value the renderer would see in that region of space is 1.0/cubic unit. But if your object was only 2.0 units high and the spacing was 0.01 to capture all details and produce the same particle distribution as in the previous example, if each particle still carries 1.0 Density, you will get thousands of accumulated Density units per cubic spatial unit! This Density affects the attenuation of light, so if you leave the Lighting/Final Pass Density multipliers at the same settings (e.g. 5.0E-1 which is the default), the object will be VERY dark and a reduction of several orders of magnitude (e.g. 5.0E-6) might be necessary to produce a good looking volume that transmits enough light.
In other words, the smaller the objects, the lower the Density multipliers should be. If you are using very large objects, there will be a lot less particles per spatial unit, so the Density multipliers would have to go up.
This applies to all particle clouds, I used the PRT Volume for convenience just to explain the concept. Also, the same density principles apply to both Particle and Voxel rendering, but in the case of Voxel rendering it is more obvious since the particles accumulate their per-particle Density into a cubic volume (the voxel) to produce the final voxel Density that the renderer sees.
I will try to draw some graphics for the documentation to visualize this, in addition to posting example renders…
