Yeah, plenty of opportunity for tweaks until we have something that looks and performs the best the technique can manage (for example, to avoid the car's silhouette trailing, try MotionBlur2 function?). This is after all the first release where it is functional. Wheel blur models might be necessary to fill in for some of the issues, once we have a stable well-performing target, the content will adapt to match it.
@ n.z always being positive, the only time that's observably an issue is with cull=none polygons, every other polygon is facing the camera and should have normals also (approximately) facing the camera. I'm not sure if anything can be done about the no-cull polies but to not use them much.
On default content, motion blur looks like this:
![[IMG]](http://i.imgur.com/Qw2vQ.jpg)
One obvious tweak (in motion_blur.cg, MotionBlur3) to make it a slightly less sudden cut-off is to base the 'zero cut-off' speed on the number of samples, like
Code:
if(abs(vel.x)+abs(vel.y)<(0.001*i))
(instead of a single 0.015 value)
This way there isn't a single cutoff point where sampling stops, there's a series of them peeling away samples making the transition non-obvious.
![[IMG]](http://i.imgur.com/wKC4K.jpg)
Another one I did, cutting out some of the ghosting, is setting up the calculation order differently.
Code:
tc=saturate(tc+vel*oneOverSamples);
This line moved to above vel=MB_GetVelocity, and also, earlier on,
Code:
float2 vel;
=>
float2 vel=MB_GetVelocity_SingleChannel(velocityMap,tc0,texWidth,texHeight);
since speed now needs to be known during the first loop to get a tc update...
