Previous Topic (Motion Blur) Up (Contents) Next Topic (Cameras and Lights)

Depth of Field

Krakatoa Depth Of Field Effect

  • Krakatoa supports both the 3ds max Multi-Pass Depth Of Field effect and provides its own implementation which is based on real-world camera physics using the camera target distance, the camera field of view and f-stop value.
  • The 3ds Max Multi-Pass Depth Of Field effect is generally slower and provides inferior quality compared to the built-in Krakatoa Depth Of Field effect. It can be used for compatibility when compositing with elements rendered in other renderers using the 3ds Max DOF effect. In most other cases, the built-in method should be preferred.
  • Since the 3ds Max standard Camera does not provide an f-stop value, it is necessary to add a Krakatoa Camera modifier to the Camera. You can add the modifier to Spot Lights too if you want to render a light view instead of a camera view.
    • Note that in Krakatoa 1.0.x, the user had to use the "Depth Of Field - mental ray" Multi-Pass Effect to provide an f-stop value.
    • Brazil r/s and V-Ray cameras have an f-stop value and are supported directly.
  • The Krakatoa Depth Of Field calculates the disk area a single particle would occupy based on the current camera settings and then draws this particle multiple times (depending on the settings dozens or even hundreds of times) at random positions within that area. This means that if Krakatoa had to render one million particles and the Depth Of Field settings require each particle to be drawn on the average 10 times (some more, some less, depending on their distance to the camera), the renderer would have to draw 10 million particles. Thus, while drawing points is relatively inexpensive, using Depth of Field with high quality settings or extreme lens settings could cause significant slow down.

Depth Of Field Quality

The quality of the Depth of Field effect depends mainly on the Depth of Field Sample Rate value found in the Main Controls rollout. This value scales the amount of samples used per particle. The default value of 0.1 is very low quality but usually adequate for testing. A value of 1.0 is relatively high quality and can take a bit longer to calculate (especially with millions of particles). A value of 0.0 practically disables the effect. Values close to 0.0 like 0.001 will jitter the actual particles around without doing coverage of the area and could be used for very quick previews.

This is a scene with 3 teapots, 20 segments each.
Filtering is set to Bicubic.
Depth Of Field is disabled.
(Enabling DOF and setting the Sample Rate to 0.0 results in the SAME image).
Render time is 0.484 sec.

This is the same scene rendered with DOF on and Sample Rate of 0.001.
The particles do not get drawn multiple times because the resulting sample count is too low and mostly clamped to 1 sample, but each particle is drawn at a random position within the calculated disk area.
Render time is 0.515 sec.

This time the Sample Rate of 0.01.
The result is similar, but the pattern is different and the farthest teapot is slightly more smoothed.
Render time is 0.515 sec.

This is the default Sample Rate of 0.1.
It is still rather rough, but gives a better idea of the final result without taking much longer to render.
Render time is 0.594 sec.

This is the result from Sample Rate of 1.0
It is relatively high quality, but is already taking longer than a second to render.
Render time is 1.422 sec.

This is the result from Sample Rate of 2.0
Looks better than the previous version, but also takes twice as long to render.
Render time is 2.344 sec.

This is the result from Sample Rate of 3.0
We start to see a pattern here - adding one to the Sample Rate adds one second to the render time.
Render time is 3.234 sec.

This is the result from Sample Rate of 5.0
This confirms the pattern - a sample rate of 5.0 results in a render time of 5 seconds.
This is of course specific to this scene, but in general increasing the Sample Rate affects the render time in a linear fashion.
Render time is 5.078 sec.