As mentioned in the manual, Krakatoa uses “a cubic unit of 3D space” to calculate densities.
C4D has a “real” unit system. What shall we consider the base unit?
Please keep in mind that the Density needs to stay the same if we switch unit system.
Most 3D applications have “real” unit systems, or at least assumptions what the unit means. But there is a thing called a Generic Unit which is what the application stores as 1.0. You can interpret that as whatever you want, but mathematically it is THE unit of 1.0 and that’s what we mean. In Maya, a system unit is normally interpreted as 1 cm. In 3ds Max, it depends on the System Units settings - in North America it defaults to 1 Generic Unit = 1 inch, in Europe it is 1 Generic Unit = 1 cm. But then you can also remap what the System Units are displayed as in the User Interface. So you can have your Max set to 1 GU = 1 meter, but the UI set to Centimeters and a Cube with a size of 1.0 Generic Units which is interpreted as 1 Meter is listed in the UI as 100 Centimeters.
Since R12, the same concept applies in Cinema 4D. The Project Scale controls the mapping of the file’s Generic Unit to System Units, and the Display Units control how that value should be represented in the UI. Both default to Centimeters in my install.
It is up to both the 3D application and the Krakatoa connection to do the interpretation when talking to the renderer. In the end, if Krakatoa gets a Position value of 1.0,0.0,0.0, it will render the particles at one unit away from the world origin and has no knowledge of whether that was meant to be 1 cm, 1 meter or 1 light year. It is the RELATIONSHIP between units that matters. If a camera is 100 units away, once again it does not matter what the distance was meant to represent in the “real world”.
But there ARE problems in the current Krakatoa C4D bridge when dealing with units. We haven’t looked at those yet since we just recently acquired the code. So there will be some work needed to make sure the C4D units are respected everywhere.
For example:
*Create a Cube and set it to 100x100x100 cm size.
*Create a Krakatoa Mesh Source and pick the Cube.
*Set the Voxel Spacing to 1.0
*In Render Settings, enable Override Emission, enable Use Emission and render.
INCORRECT RESULT: Only one particle will be generated. A value of 1.0 should mean 1 cm in this case, but for whatever reason it is interpreted as 1 meter.
*Enter 0.01 for Voxel Subdivision and render again to get 100x100x100 voxels, or about 1,000,000 in total (there might be more or less since the Level Set of a Box has some curved edges).
*Now check Enable Shell and set Shell Start to 0 and Shell Thickness to 1.0.
*Render again:
INCORRECT RESULT: The same 1,000,000 particles will render. I would expect only those particles within 1 cm of the surface inside the volume to render.
*Change Thickness to 0.01 and render again - now you will get only the particles close to the sides of the Cube, or about 97K in total.
So for some reason, the UI settings of the Mesh Source are passed to the renderer as Meters, although the system settings are obviously Centimeters. And the spinners are not set to show the real units, so you don’t see “cm” next to the value.
It is even worse when it comes to Depth Of Field. I would recommend not even trying to use it at this point, as it is totally busted and takes forever due to unrealistic unit settings being passed to Krakatoa.
We will look into this as the code you got and I am looking at is mostly as we got it from Uglykids and I don’t know enough about it yet…
I have logged a bug against the units problem and I will talk to our in-house programmers to look at the code and figure out why it behaves the way it shouldn’t.
This has been addressed in Beta 2.
We found out that the original code we received used a factor of 1/100 when exporting to Krakatoa SR. This messed up things like Voxel sizes, and especially Depth Of Field. As I explained earlier, Krakatoa SR does not dictate a specific real world size unit, it just expects all the data to be consistently in the same scale and space. Since the internal factor mentioned above wasn’t being applied consistently to everything that could affect the final result, things were off.
In Beta 2, Depth Of Field works as it should, most spinners that should be in world units now show the C4D units (except for Voxel Size in the Render Settings which was changed after the build was made so it will have to wait for Beta 3).
Due to this change, you can expect existing scenes to render differently when it comes to density - quite possibly the Final and Lighting Pass Densities will have to be increased a few orders of magnitude. Also note that the Lighting Pass and Final Pass Density are now coupled by default and require a checkbox to be checked for the Lighting Pass Density settings to be applied separately - this could also affect existing scenes. Same applies to the Emission Strength which is now set to the Final Pass Density and can be decoupled explicitly via a checkbox. The respective Lighting Pass and Emission controls are not being grayed out yet, but this is already in the works for Beta 3.