krakmos optimization

[hdarren]

@benyaboy

Is lighting pre-cached or done at rendertime?

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.

@benyaboy

Is there any ray termination?

There is. The criteria is based on the accumulated alpha value and it isn’t tuned for any particular quality/performance so YMMV.

@benyaboy

Is there mipmaping happening to help with larger step sizes?

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).

[hdarren]

@benyaboy

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.

OK. I’ll add that to the list.

@benyaboy

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.

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”?

@benyaboy

Is the grid sparse?

@Darcy

converting the particle data to a sparse 3D voxel structure

@benyaboy

Is the grid in worldspace or cameraspace?

Worldspace, after the trouble that this caused for the plane marcher.