Motion blur: blocky tiles and colour bleeding around moving objects over emissive surfaces #836

Closed
opened 2026-10-18 02:03:17 +00:00 by sky_line · 2 comments
Owner

With motion blur on, fast camera rotation over a bright emissive surface produces two artifacts around moving / foreground objects:

  • Blockiness: square, tile-sized blocks around the silhouette, where a tile is either blurred or left sharp. The blocks line up with the blur's 16 px tile grid.
  • Bleeding: the emissive surface's colour smears into the foreground object (here a brown prim and an avatar standing on it, over a bright rainbow emissive floor).

Seen on the 1.3 development build (1fe80328d5, the beta 13 code + fixes) while rotating the camera hard. Screenshot below.

Where to look (clean_mblur_tile.comp -> clean_mblur_neighbor.comp -> clean_mblur_recon.comp -> clean_mblur_writeback.frag, #118)

  • Tile boundaries: reconstruction skips tiles whose NeighborMax is under the active threshold (~0.5 px) and the write-back skips them too. A skipped tile next to a blurred one leaves a hard edge, especially where a large NeighborMax reach blurs one tile but not its neighbour. Check the threshold / reach and whether skipped tiles border blurred ones.
  • Bleed: the reconstruction weights taps by depth (cone / cylinder) and velocity. A still foreground over a moving background should keep a crisp silhouette. Check whether the emissive surface writes correct motion vectors and depth, or whether bright HDR samples dominate the weighted average (blur in HDR before tonemap, no luminance clamp). If the surface is fullbright / emissive / alpha and skips the motion pre-pass, its velocity or depth would be wrong.

Repro

Stand on or near a large bright emissive surface, turn motion blur on, and rotate the camera quickly. Compare with motion blur off.

motion blur over emissive

With motion blur on, fast camera rotation over a bright **emissive** surface produces two artifacts around moving / foreground objects: - **Blockiness:** square, tile-sized blocks around the silhouette, where a tile is either blurred or left sharp. The blocks line up with the blur's 16 px tile grid. - **Bleeding:** the emissive surface's colour smears into the foreground object (here a brown prim and an avatar standing on it, over a bright rainbow emissive floor). Seen on the 1.3 development build (1fe80328d5, the beta 13 code + fixes) while rotating the camera hard. Screenshot below. ### Where to look (`clean_mblur_tile.comp` -> `clean_mblur_neighbor.comp` -> `clean_mblur_recon.comp` -> `clean_mblur_writeback.frag`, #118) - **Tile boundaries:** reconstruction skips tiles whose NeighborMax is under the active threshold (~0.5 px) and the write-back skips them too. A skipped tile next to a blurred one leaves a hard edge, especially where a large NeighborMax reach blurs one tile but not its neighbour. Check the threshold / reach and whether skipped tiles border blurred ones. - **Bleed:** the reconstruction weights taps by depth (cone / cylinder) and velocity. A still foreground over a moving background should keep a crisp silhouette. Check whether the emissive surface writes correct motion vectors and depth, or whether bright HDR samples dominate the weighted average (blur in HDR before tonemap, no luminance clamp). If the surface is fullbright / emissive / alpha and skips the motion pre-pass, its velocity or depth would be wrong. ### Repro Stand on or near a large bright emissive surface, turn motion blur on, and rotate the camera quickly. Compare with motion blur off. ![motion blur over emissive](https://git.slipstreamviewer.org/attachments/6f27ac0f-e98e-4ee9-bb3b-c63bbf7c7336)
sky_line added this to the Slipstream project 2026-10-18 02:03:18 +00:00
Author
Owner

Fixed on release/1.3 (6350211dbb + SPIR-V regen c6a53bf36a), also on the dev branch. Root causes: (1) the uniform-motion fast path box-blurred into tiles whose motion it never checked (the slowest-pixel test covered only the 3x3 tiles while the blur reaches up to reach x 16 px), smearing still silhouettes and stopping hard at tile edges; the check now covers the full (2*reach+1)^2 square (RenderVKMotionBlurWideUniformCheck). (2) Bright HDR samples swamped the blur average; samples are now weighted by 1/(1 + luma * exposure) (RenderVKMotionBlurHdrWeight). Owner verified: the blockiness is gone; a little bleed at feet / prim bases remains, accepted.

Fixed on release/1.3 (6350211dbb + SPIR-V regen c6a53bf36a), also on the dev branch. Root causes: (1) the uniform-motion fast path box-blurred into tiles whose motion it never checked (the slowest-pixel test covered only the 3x3 tiles while the blur reaches up to reach x 16 px), smearing still silhouettes and stopping hard at tile edges; the check now covers the full (2*reach+1)^2 square (RenderVKMotionBlurWideUniformCheck). (2) Bright HDR samples swamped the blur average; samples are now weighted by 1/(1 + luma * exposure) (RenderVKMotionBlurHdrWeight). Owner verified: the blockiness is gone; a little bleed at feet / prim bases remains, accepted.
Author
Owner

Fixed in Slipstream 1.3.0 (stable): https://git.slipstreamviewer.org/sky_line/Slipstream/releases/tag/v1.3.0

If you still see this on 1.3.0, reply here and we'll reopen it.

Fixed in **Slipstream 1.3.0** (stable): https://git.slipstreamviewer.org/sky_line/Slipstream/releases/tag/v1.3.0 If you still see this on 1.3.0, reply here and we'll reopen it.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
sky_line/Slipstream#836
No description provided.