Hello,is there a way to pass the bone matrixes of skinned character into vertex shader?
I need to calculate differences between last and current frame’s bone matrixes for velocity buffer based motion blur.
Or is someone here maybe more knowledgeable about this motion blur technique and knows of a better way?The papers don’t really go into much detail at all.
You can pass matrices into a shader using the material’s SetMatrix function.
I’ve thought about this a bit and I don’t think it’s feasible. Unity does its skinning on the CPU, so shaders never see bones. I can’t think of a way to provide that much data to a shader in Unity.
Sorry about that! I probably wrote one of the papers you are complaining about! :lol: In my paper, I only talk about solid objects that do not deform.
It is very feasible to extend the idea to deformable objects. You don’t need to compute the differences between last and current frame’s bone matrixes, JUST THE DIFFERENCE OF THE VERTEX POSITIONS. To get the necessary info to the shader you will need to implement your own skinning routine because the Unity skinning routine is not flexible enough.
To get on the same page, here is the offending paper/video:
Hardware Accelerated Motion Blur Generation:
http://www.clementshimizu.com/0018-Hardware-Accelerated-Motion-Blur-Generation/ClementShimizuMotionBlur.pdf
http://www.clementshimizu.com/0018-Hardware-Accelerated-Motion-Blur-Generation/motionblur.avi
I will outline my suggestion here.
Hardware-Accelerated-Motion-Blur Extension for Skinned Objects Appendix
Normally the skinning routine takes the mesh and the bones and computes a new mesh (vertex position and normals) that are deformed by the bones.
HOWEVER, in addition to position and normal each vertex can also have many other varying data elements like color, tangent, uv, uv2, coordinates, etc. Normally these are not affected by the bones, but they COULD be.
So you need to make a skinning routine that additionally computes the vertex position for the previous frame and places it in any of those additional vertex data elements. I would suggest UV2 because it probabbly won’t interfere with other shaders.
THEN in your motion vector shader, you use UV2 as your vertex position for the previous frame.
PositionNew = ModelViewProjection*In.Position // compute the screen space coordinate of the current vertex position
PositionOld = ModelViewProjection*In.UV2 // compute the screen space coordinate of the previous vertex position using the old position encoded in the UV2
MotionVector = PositionNew-PositionOld
The second pass (line integral convolution) would be identical to the method in the paper.
Dr. Clement Shimizu
Hi Clement,
It’s very cool to see you posting here. You’re right that you can’t get at Unity’s skinning routine in order to pass arbitrary vertex data to a shader. Unfortunately Unity’s skinning is implemented in native code with SSE optimizations, and re-implementing it in Mono would make it a lot slower.
I’m not actually interested in handling skinned meshes myself, but I did implement a basic motion blur from the D3D book. I read your paper but stopped short of trying to implement your LIC.
I might take another look at it now that I have a little more experience with postprocessing in Unity.
I looked at the paper again to re-familiarize myself with my confusion:
With the motion blur I implemented, I rendered colours to the frame buffer, and screen space velocities to an off-screen buffer. Objects in the velocity buffer are rendered with vertices either in their current or previous positions depending on the value of dot(normal, velocity). I then blurred the frame buffer by the velocity buffer by taking ten samples for each pixel, offset along the velocity for that pixel…
Figure 2 in your paper makes your approach look quite similar, except that instead of simply sampling and averaging colours along each pixel’s velocity, you perform multiple convolutions and blend them iteratively.
Where I get confused is that the paper refers to a DSDT texture being generated on the CPU. It makes it sound like you’re doing some sort of offset in texture space, which I don’t understand. How does the texture warping fit in?