• Advertisement
Sign in to follow this  

Motion vector calculation problem

This topic is 1418 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello.

 

I'm having problems with my motion vector calculations. 

 

jFx9Yii.jpg

 

The camera is only very barely moving, but as you can see the motion vectors of the bottom left tile are calculated incorrectly when the camera gets too close. I believe the problem happens due to the projection ending up behind the camera (at least one vertex is behind the camera).

 

I calculate my motion vectors for each vertex like this:

gl_Position = projectionMatrix * viewMatrix * modelMatrix * vec4(position, 1.0);
vec4 previousPosition = previousViewProjectionMatrix * previousModelMatrix * vec4(position, 1.0);
motionVector = gl_Position.xy / gl_Position.w - previousPosition.xy / previousPosition.w;

I am unsure how to fix this. The problem seems to come from the motion vectors becoming extremely large, large enough to cause the whole triangle to receive motion blur after interpolation. Any help would be appreciated!

Edited by theagentd

Share this post


Link to post
Share on other sites
Advertisement

Thank you! Your solution worked flawlessly! Since I'm only targeting PC and the additional pixel shader math did not cause a measurable decrease in performance (both run at 140 FPS) I've decided to simply go with accurate motion vectors.

Share this post


Link to post
Share on other sites

@osmanb

you might reduce the issue by dividing by abs(w), as most of the problem arises due to the flip of x and y when you divide by something negative. it's still not correct, but far less noticeable and you get away with per-vertex cost.

Interesting. Never thought to try that, but I might give it a whirl. Thanks.

Share this post


Link to post
Share on other sites

@osmanb

you might reduce the issue by dividing by abs(w), as most of the problem arises due to the flip of x and y when you divide by something negative. it's still not correct, but far less noticeable and you get away with per-vertex cost.

I tried that after I posted my first post, but it didn't help. I also tried with -abs(w). It seems like the problem is that the motion vector becomes extremely large when a vertex lies very close to (linear) Z=0. Direction isn't really the main problem; it's the length of the vector. I clamp my motion vectors so my motion blur doesn't explode, but the motion vectors are several magnitudes too large even for unnoticable movement.

Share this post


Link to post
Share on other sites

theagentd, you're right, division by zero (or close to zero) will in most cases lead to bad results. maybe clamping to the near plane might give a reasonable result? something like

xy/max(near_plane,abs(w))

?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement