What kinds of speed optimizations are in krakatoa atmospherics?
- Is lighting pre-cached or done at rendertime?
- Is there any ray termination?
- Is there mipmaping happening to help with larger step sizes?
B.
The lighting is calculated completely on the fly via a naive trace to each light. While this hurts performance it does allow us to offer very pretty lighting compared to the other render modes.
There is. The criteria is based on the accumulated alpha value and it isn’t tuned for any particular quality/performance so YMMV.
No.
The renderer more or less works by converting the particle data to a sparse 3D voxel structure, then taking steps with an upper bound of “Max Step” and adaptively refined util the result converges or the step goes below “Min Step”. Rays traced for shadowing information are not adaptive and always move by “Max Step” (at least in the current implementation).
Also, what about sampling jitter? We found that to help reduce banding. I believe jittering the ray march step size or offsetting the rays is enough to do the trick.
I would also like to have an option for reduced lighting traces. I’m not sure what the terminology is but it means that you find the centroid of the dense part along the ray and trace to the light from there. This is fine for smoke and clouds.
Is the grid sparse?
Is the grid in worldspace or cameraspace?
OK. I’ll add that to the list.
Have you seen any papers or in depth descriptions of this? Is it essentially caching the lighting information at the center of the closest “centroid”?
Worldspace, after the trouble that this caused for the plane marcher.
The lighting optimization is from my recollection from the “Production Volume Rendering, 1 and 2” from siggraph 2012. The idea is that not every ray-marched camera sample needs to ray march to the light. For many examples, a single ray at the center of the dense part of the ray can be used. I’m not sure but this might require a special shadow plugin to implement these types of optimizations.