Dev:Ref/Proposals/Compositor2014 p1.4 TD

提供: wiki
< Dev:Ref‎ | Proposals
2018年6月29日 (金) 06:08時点におけるYamyam (トーク | 投稿記録)による版 (1版 をインポートしました)
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
移動先: 案内検索

Compositor 2014 p1.4 Vector Blur technical design

IST (current situation)

The current VectorBlur Node has been implemented and optimized for a single core and a serial process. The node itself calls an internal function of the Blender Internal renderer. This function does the whole trick. The current implementation does the next steps

step 1: clean up speed pass

The speedpass contains values of the screenmovement between the last frame and the frame rendered and with the next frame. This is used as motion. This speedpass needs to be cleaned up (All values equal to PASS_VECTOR_MAX are set to zero)

step 2: minimum speed

When the min speed option is used (min_speed larger than zero) the speedpass is adjusted (the next is done for the previous frame (R, G) and the next frame (B, A). When screen vector is zero, the new screen vector is zero If speed less than min_speed, also use zero else speed is mixed with the minspeed (speed *= (1.0f - minspeed/speed))

step 3: calculate average speed and average depth

calculate average speed and the average depth. If maxspeed option is used, adjust accordingly also reset the speeds on the border

step 4: tag pixels that have a motion

This step makes a mask of the pixels that have speed. other pixels can be ignores

step 5: blur

for each sample? TDB

=== step 6:

blend original image with accumilated image based on


Issues

As the current implementation is serial and only uses a single thread it blocks the whole compositor workflow. When artists complain about the speed of the compositor it is mainly when they use this node.

SOLL (target situation)

solution seems very alike the camera blurs as they also a stepped approach. the accumilated image is something that we need to address, but should still be valid when using the CPU. On GPU this might be an issue.