Has anyone successfully found a way to render motion vectors to use to stabilise and track? When I’ve done it the results are different to the ones inside action. All 32bit.
This makes it a nightmare for me to close a batch and come back to it at a later date because I have to wait ages for the caching again.
All advice welcome.
Is this what you’re looking for?
An @andymilkis video of a John @Ashby technique, sent to me by Todd @Gut Gutridge! Team effort!
Hey @johnt
If you are happy with the results I have been rendering out a UV pass from action and using this rather than using the motion vectors.
Motion vectors are a bit of a “land mine” in setups so I have been asking artists to not have them live in the setup. Rather they pipe out a precomp or use a UV map
I’ve just got it to work. It was the 32bit button that was the secret. And in the action applying switch to forward motion vectors. Hoorah. Mrs Miggins Pie Shoppe here we come.
The motion vectors still require some calculations and a cache no @johnt ?
Not sure it does.
However warning
The track is off by a pixel here and there. For accuracy, probably better to stick with UVs.
I know I shouldn’t do this @johnt but in its first iteration, 2019 I think, it burnt me by subtlety changing the motion vectors calculation each time.
I now hold a grudge and treat it with caution.
Don’t get me wrong I still think it is amazing but I just can’t stand the re-caching it can do a couple of days later when you are all the way down the other end of the setup.
Yep. Had the same. But they are great. When they work.
Go @gut !
Are you guys SURE this is working? I cant get pre rendered Motion Vectors to work on 2021.2.
Ugh.
Pre rendered how? Like from an analysis node upstream in batch or a UV pass out of an upstream action?
I have dozens of stills that need to be Motion Vectored… pre-rendered UVs aren’t an option with these frame ranges.
So, upstream motion analysis mode. You’ve set the mode in action to forward/backward? It still has to do come calculating but it should be faster than caching the MVs in action.
That what it is. Its like a bad gps…
“Recalculating…”
Argh. why does it need to recache a prerendered thing? I think I know why but I will have to care and understand a different time. 
it was my understanding that even with the motion vectors it still needed to do some caculations under the hood. Hence my love of locking it off and rendering UV maps
totally. I just have too many frames and too many passes to prerender UVs.
Arrgh! I bet @MikeV has a python script that does all of this cache rendering for you.
Or it is in here:
/opt/Autodesk/flame_2020.3.1/python_examples/cache_motion_vectors.py
UPDATE
Actually no:
This script adds a Create Motion Vectors Maps to a Clip node located in the
Batch Schematic.
An Action node is connected to the clip and the Motion Vectors map is
created and cached.
The same can be done from the Desktop object in the Media Panel.
This version opens a Qt file dialog allowing you to select a clip.
A new Batch Group is created for the clip & the same recipe as the Batch version
above is applied.Unless I misunderstand what’s going on, even if you pre-render the motion vectors the second you set a reference frame to track from, the box is running a legit pixel sim, where the output of every pixel on each frame is pushed along along the vector at the magnitude of it’s corresponding motion vector from from the current frame. At the end, the previous output is looped through again until its complete. There’s no pre-rendering that process… it’s the Touring problem—it’s done when it’s done.
Sorry if I’m explaining something you already know…
Yup. That makes sense. I wish it happened in the background. It’s easy to forget all the wizardly math happening under the hood when your shot is forever long with all the patches.