# Motion-blur BVH heat map

Some more coding art.

In the past months, I have worked a lot in the new voxelization structure that Arion uses to speed-up ray-tracing of geometry. One of the most remarkable features of the new RandomControl Sliding Motion-blur BVH (or RCSMBVH, as I call it…) is support for hyper-efficient motion-blur.

Here’s a heat map of a cute deforming ape. Deformation affects all the body, but very specially the arm in this frame.

A cute deforming ape (BVH heat map) A heat map is a render where a color is output depending on how many voxels were traversed and how many hit-testing routines had to be evaluated in order to determine each pixel’s first ray-tracing hit. Black means that nothing was tested, blue means that few traversal/hit-testing operations were performed, and then green, yellow, or red mean that the ray traversed conflictive areas where many hit candidates had to be evaluated. In other words: black/blue are good (fast) and yellow/red are bad (slow).

See how the motion-blurred area is mostly blue (which is excellent news).

# New header images in the blog

From now on, the header of this blog sports some of Erwann Loison’s best Arion renders.

# Fourier Transform vs. Cosine Transform

Below, a grayscale (raw HDR luminance / no gamma) image, its Fourier Transform, and the image reconstructed from the Fourier Transform coefficients.

Discrete Fast Fourier Transform Below, a grayscale (raw HDR luminance / no gamma) image, its Cosine Transform, and the image reconstructed from the Cosine Transform coefficients.

Discrete Fast Cosine Transform The image (memorial.hdr by Paul Devebec) is 512×768. The ‘Fast’ Transform algorithm requires that the dimensions of the image are powers of 2. So the image is padded with zeroes to become 512×1024. Note how the transform has as many coefficients as there are pixels in the padded source image (i.e., 512×1024).

Despite the source of the transforms (spatial space) is a luminance field (one real number per pixel), the transforms (frequency space) are imaginary numbers (two real coefficients per slot). The visualized transforms are the magnitude of each of those complex numbers. The DFT magnitudes, in particular, have been offset to the center, log-scaled, and powered up for better visualization. The DCT magnitudes have been powered up, only.

Bonus remark: A favorite of mine. Note how the DCT clusters at the top-left corner of the transform space, containing near-zero coefficients everywhere else. The DFT, on the other hand, produces significant coefficients almost everywhere. This is the main reason why the DCT is preferred over the DFT for transform-based image compression algorithms (e.g., JPEG, MPEG, …).