Motion vectors are coming in beta 16

I hope Tim C doesn’t mind me posting about this now but since his messages on the subject (and its use to make a TAA effect) are in the Unity Cinematic Effects thread I thought some people may not have heard the news…

Tim’s post about this

Exciting times :slight_smile:

1 Like

I realise that some people are going to be excited about this. But I for one would rather they fixed the existing stuff and made it useful again, before adding more stuff into it.

Fix the current bug list, then add some more features. It a tried and proven way to build solid code.

I think they already did enough to respond to that by changing the release schedule, opening up the beta and concentrating on stability in 5.3.4.

I know it won’t satisfy people who are badly bitten by particular bugs right now, but they have to balance these two different things, and plenty of people would moan if they added no new stuff at all. Motion vectors enable some much-needed functionality and I applaud their inclusion at this stage.

can the unity dev implement something like this Sharp lightmap ? - Unity Engine - Unity Discussions

Yay, here we see the motion vector stuff in the beta 16 release notes:

  • Graphics: Added motion vector support to Unity:

  • Requires RG16 texture support.

  • Motion vectors track the screen space position of an object from one frame to the next and can be used for post process effects.

  • See the API docs for: Renderer.motionVectors, Camera.depthTextureMode, SkinnedMeshRenderer.skinnedMotionVectors, PassType.MotionVectors, and DepthTextureMode.MotionVector.

I do find it a bit disconcerting or odd that sometimes great new features like this end up in the fixes section of the release notes!

It’s fixing unity’s erm… features!

Thanks for catching that. Will be fixed in final release notes rollup…
Item was added to the wrong section of our tracking sheet.

1 Like

can we have a vertex color painter integrated in the engine?

Sorry, beta isn’t about requests but testing the features and changes in the offering. If you want to make a request - head towards feedback.unity3d.com

Hm, I tried making a motion blur effect use the motion vectors. When I just dump the motion vector’s R and G channels to the screen in the form float4( vec.r, vec.g, 0, 1 ) it’s just pure black. Are the values negative I wonder?

EDIT: Scratch that. Seems to be related to a separate issue where moving objects via the transform inspector causes hiccups/lag (reported as a bug). If I move via the transform handles with the game and scene view side by side, it seems to work.

EDIT2: OK, so I’ve got a simple motion blur effect implemented. Definitely needs work, however it was really easy to set up now that we have native motion vectors XD

2 Likes

You are going to have to post a picture :slight_smile:

To test out new motion vectors, I made a small update for motion blur made by Keijiro Takahashi.

So, here’s attachment of updated package, if someone interested.

2614328–183397–Kineblur.unitypackage (6.48 KB)

2 Likes

Well looks like someone beat me to the pictures XD so I’ll post a video instead, from one of the projects I’m working on.
If you pause the video especially at the part where I’m strafe jumping across the large empty space, you can really see the blur effect on the ground.

Oh cool :slight_smile:

I really miss quake style physics in games :frowning:

2 Likes

Heh, thanks. Thinking about making it an asset for the store. Really kind of a niche asset, but w/e maybe somebody will want it.
Also, the motion vector buffer relies on RGHalf, right? I notice it doesn’t work on WebGL. So in my image effect would this work to check for support?

if (!SystemInfo.SupportsRenderTextureFormat(RenderTextureFormat.RGHalf))
{
    enabled = false;
    Debug.LogWarning("Platform does not support motion vector buffers");
}

EDIT: Nevermind. Answered it myself. The answer is yes - I tested using this code on a WebGL build and it does disable the effect as expected.
Be nice if motion vectors did work on WebGL, but oh well. Guess we’ll have to wait until WebGL 2.0 becomes standard…

They could theoretically be stuffed into an 8 bit texture but it’s not desirable because of the LDR range and lack of precision. If anything I think the resulting effect could be worse than the old motion blur. Just hypothetical thinking…I’d gladly like to be proved wrong :slight_smile:

Hm, makes me wonder what the actual range of values are on motion vectors. I get the feeling they used RGHalf because it’s a floating point format which makes storing non-unit values a lot easier. I bet you could still pack the values into an RGBA32 with some effort, but at the cost of shader complexity (use pairs of 8-bit channels for encoding a value, so X might be encoded in RG and Y encoded in BA, giving 16 bits for each, but could prove to be more trouble than it’s worth? not sure)

Packing would be slower though?

Seems very likely. Just some idle thoughts I wanted to throw out there.

Come to think of it, they won’t normally go above 1. So I reckon it is about properly storing fractions and signed values.

It would indeed, but not massively. The real issue is that packing can leave you with an approximation of the original vector. And an approximation of a fraction can be wildly inaccurate. Not really worth it for me :wink: