Motion Blur
by Jacob Dankovchik · in Torque Game Engine Advanced · 03/25/2006 (9:49 am) · 10 replies
I've recently begun looking into motion blur and honestly, I think this may be promising! I've always really really wanted motion blur but had no clue how to do it. I recently read a paper written by ATI about motion blur done by distorting the mesh and shading it accordingly. I figured this sounded very doable and set out on it.
So far all I have is a horizontal distortion based on your player's velocity.
Next step is to get it to distortion in the proper direction and proper amount and then attack the shading aspect of it all.
Those shouldn't be too difficult to tackle. So far its slow to get goin on it, but I'm workin on it. It all seems quite possible to me. However one thing I don't know about is the velocity of each vertex. To do the motion blur properly, I'd need to input the velocity of the vertex and not the entire object like I'm doing. So right now, if the player was to say, swing his arm, it wouldn't blur. But if he was to take off running, his entire body would blur evenly. Does anyone know if finding the speed of each vertex can be done and how you could go about doing that?
So far all I have is a horizontal distortion based on your player's velocity.
Next step is to get it to distortion in the proper direction and proper amount and then attack the shading aspect of it all.
Those shouldn't be too difficult to tackle. So far its slow to get goin on it, but I'm workin on it. It all seems quite possible to me. However one thing I don't know about is the velocity of each vertex. To do the motion blur properly, I'd need to input the velocity of the vertex and not the entire object like I'm doing. So right now, if the player was to say, swing his arm, it wouldn't blur. But if he was to take off running, his entire body would blur evenly. Does anyone know if finding the speed of each vertex can be done and how you could go about doing that?
About the author
#2
not sure which would be best. also look at the dev shot of the day, looks like motion blur is in the top left shot so it may be in the pipe for release anyways.
as always, very interesting and good luck!
03/25/2006 (2:34 pm)
Interesting approach. have you considered something similar to the glow buffers, buffering the last few frames (possibly at a lower res) and blending them on top of the current frame? this approach would blur camera movement also, your current approach will only blur the objects you are applying it to.not sure which would be best. also look at the dev shot of the day, looks like motion blur is in the top left shot so it may be in the pipe for release anyways.
as always, very interesting and good luck!
#3
For advantages something I've seen thats very big is the lack of artifacts of any kind. Like the effect you mentioned Jameson, I know what GG did for that effect, I did the same thing in my peripheral vision thread. But if you look, you can see the layering of the same image. While it blurs, its noticable. It also causes a bit of a performance hit. With just stretching the model, theres no layering effect at all as all the shading will be smoothly calculated on each pixel across the deformed model. Should also be much easier for your speed. ;)
And also, I do indeed want to limit this to specific objects. I'm one to very strongly support specific control and I like the idea of being able to determine if something shouldn't blur.
03/25/2006 (8:13 pm)
Actually, Project Offset is indeed a bit of inspiration on this. After seeing that in action, I decided I MUST have motion blur. So, I've set out on the task.For advantages something I've seen thats very big is the lack of artifacts of any kind. Like the effect you mentioned Jameson, I know what GG did for that effect, I did the same thing in my peripheral vision thread. But if you look, you can see the layering of the same image. While it blurs, its noticable. It also causes a bit of a performance hit. With just stretching the model, theres no layering effect at all as all the shading will be smoothly calculated on each pixel across the deformed model. Should also be much easier for your speed. ;)
And also, I do indeed want to limit this to specific objects. I'm one to very strongly support specific control and I like the idea of being able to determine if something shouldn't blur.
#4
03/25/2006 (9:23 pm)
I've been looking over the PO "Crowd Test" video and, FYI, they are definetly using render-to-texture with a really good (velocity based?) blur shader. If you look at a still image, you can see the seperate images, however you don't really notice it at all in motion. 
#5
Now there are two issues to solve.
For sold objects the object velocity is all that is needed and all its pixels get this velocity. For skinned characters you need to add the velocity of the object with the velocity from the bones. Not sure if that velocity is kept or the right way to generate and pass it to the shader.
Second how to elegantly add this into TSE? Is adding another boolean to SceneRenderImage like is done for glow the best way? It seems to me that the glow boolean should be replaced with some sort of enum for pass type. This would allow for other specialized passes in the future, but really there seems a need for a cleaner way to add special effect passes without making changes all over the engine.
03/26/2006 (12:09 pm)
@Jacob - IMO you should implement the blur as the PixelMotionBlur in the latest DirectX SDK. Do a render to an offscreen buffer encoding per-pixel velocity instead of color... this should be a really fast to do. Then use that to blur the color buffer. This is what Project Offset does.Now there are two issues to solve.
For sold objects the object velocity is all that is needed and all its pixels get this velocity. For skinned characters you need to add the velocity of the object with the velocity from the bones. Not sure if that velocity is kept or the right way to generate and pass it to the shader.
Second how to elegantly add this into TSE? Is adding another boolean to SceneRenderImage like is done for glow the best way? It seems to me that the glow boolean should be replaced with some sort of enum for pass type. This would allow for other specialized passes in the future, but really there seems a need for a cleaner way to add special effect passes without making changes all over the engine.
#6
For now I'll keep going with this and see how it turns out because I think I'll be capable of managing this much. Hopefully I can get more done soon.
03/26/2006 (1:15 pm)
Hm, I'm hoestly very lost as to how to go about with what your describing, keep in mind I'm still very new with a lot of this. And anything that involves work in the engine, I'm even more lost.For now I'll keep going with this and see how it turns out because I think I'll be capable of managing this much. Hopefully I can get more done soon.
#7
@Tom: You're completely right, we definetly need a cleaner way to add special effects to TSE. Hopefully after the new SceneGraph is in the public version, someone will take a look at it.
03/26/2006 (5:46 pm)
Tom brings up a good point with skinned meshes: ThreeSpace bones/nodes don't have any velocity information, AFAIK. You would have to add this information to the TsShapeInstance and the relative code. It would actualy be better to create an inherited class of TsShapeInst for this, as most TS objects wouldn't use it.@Tom: You're completely right, we definetly need a cleaner way to add special effects to TSE. Hopefully after the new SceneGraph is in the public version, someone will take a look at it.
#8
03/26/2006 (6:23 pm)
@Jacob - Just look in your DirectX SDK example browser for the PixelMotionBlur sample. It explains the technique in detail and has source code with it.
#9
BTW, does the TSE HEAD uses vertex shaders to skin the mesh yet? That would make it easier to pass bone velocity to a shader.
And I agree on the new sceneGraph. I want it far more than fancy lighting and shadows, since a cleaner sceneGraph would make such things easier to implement by ourselves, without making ugly hacks like the water reflection rendering one (I almost fell off my chair when I saw findObject("PlayGui") in there).
04/01/2006 (2:28 pm)
Well, with a 'lil hacking, couldn't you get the bone's velocity by sampling all bone's transforms at two different thread times?BTW, does the TSE HEAD uses vertex shaders to skin the mesh yet? That would make it easier to pass bone velocity to a shader.
And I agree on the new sceneGraph. I want it far more than fancy lighting and shadows, since a cleaner sceneGraph would make such things easier to implement by ourselves, without making ugly hacks like the water reflection rendering one (I almost fell off my chair when I saw findObject("PlayGui") in there).
#10
And no, Torque does software skinning(for a few reasons, one being the bone limit, IIRC).
04/01/2006 (2:47 pm)
Adding velocity to the TS shape instance nodes wouldn't be that hard, but you'd still want it seperate as only a few classes would use it(only Player in stock TSE).And no, Torque does software skinning(for a few reasons, one being the bone limit, IIRC).
Associate Tom Spilman
Sickhead Games
I haven't read that ATI paper, but what advantages does it provide over a post processing effect?