Hey everyone,
A little while back while I realized that perspective grids are animated more like a corner pin than a normal axis (ie. you position it with each corner’s x,y positions rather than with transform, scale, rotate shear), which made me think it should be possible to import a corner pin from Mocha into one. Found that if I created 4 axes an imported each .ascii tracker file from Mocha into each one I could then copy the animation of each axis into the corresponding animation channel of a perspective grid. While it worked, it was somehow even more tedious than the traditional way of importing them into the UVs of a bilinear.
Seemed like a good use case for a script and since I’ve been on a bit of a mission to learn python as well I figured I’d try writing it myself. After a lot of trial and error and grumbling at the API I have something that works! It will import a mocha track from an action/tracer contextual menu as either a perspective grid or the UVs of a bilinear. On my machine at least 
Don’t currently have access to any flames running anything earlier than 2023.1 so I wasn’t able to test it on older versions.
To use it you need to set the s-box of your track in Mocha to where you want your corners to live.
-Export it as ‘Autodesk IFFFSE Point Tracker Data (*.ascii)’
-In Flame, right click on the background of an Action/GMask Tracer schematic and select ‘Import Mocha Track’ and select the type of import you’d like.
-In the file browser pop up select the four .ascii {trackname}_Tracker1-4 files
Be aware that this will modify the setup file of whatever node you import it into. It is designed such that it should preserve any work/other nodes you’ve done in the action/tracer setup you’re importing into, but if you have a lot of fragile work in one I’d probably make a fresh action/tracer to import into.
This was my first somewhat significant python project so please don’t hesitate to let me know of any bugs or issues or suggestions. Big thank you to @MikeV also for the pyflame_lib and the many other python resources you’ve contributed to the community, could not have figured out how to make this work without them.
To install place unzipped folder in /opt/Autodesk/shared/python
Enjoy!
import_mocha_track.zip (28.7 KB)
3 Likes
But… and I’m sorry if I’m missing something, you can toggle between verts and uvs of a perspective surface/bilinear, enter the tracker with 4 points selected and import mocha data directly once you export it as Flame tracking data.
Is that what your script does?
Yeah if you want to use the mocha track in a surface it basically just turns that process into an action menu item. the feature I was really after was getting mocha tracks imported as a perspective grid rather than as a perspective/bilinear surface, for which there wasn’t a native option that I’m aware of.
1 Like
AHA–got it. That makes sense.
Edit: Works pretty well other than coming in with an incorrect time offset. The data came in 1000 frames late. Otherwise pretty rad. Thanks for making this!
The data came in 1000 frames late.
ahh darn I thought I had accounted for this. I’ll do some digging. was your batch start frame 1?
1 Like
Wow, thanks @dazedinheaven, this script is great!
We use a start frame of 1001 too, but I’m not seeing the 1000 frame offset so I’m wondering of the script has been updated recently.
2 Likes
I’m glad it’s working for you! I have not had time to update the script yet, been away from the box for a little bit, but I have a hunch as to what’s going on. I wrote the script assuming that Mocha always writes these .ascii files with a start frame of 1 as that is always how its been when exporting them for me, no matter what start frame I fed in, but it turns out that is not the case!
I think what’s happening is that if you use OFX Mocha in Flame, Flame always passes start frame 1 to the OFX node. Seems to be the case through 2023.3.1, might be fixed in 2024 with the start frame updates but my studio hasn’t made the Rocky Linux switch yet. However, if you use Mocha as a standalone or in a host that will pass your shot’s proper start frame to Mocha, it seems that the resulting .ascii files write out with the actual frame number you see in the GUI. @cnoellert sent me a track that was coming in off by 1000 and it did indeed have the first frame written as 1001, which of course didn’t require the start frame offsetting that the script assumes it does.
@john-geehreng I’m guessing your Flame/Mocha combination is similar to mine with regard to the start frame issues, which is why the script works as-is. I’m not quite sure how to check for which kind of Mocha wrote out the .ascii’s with python. I think the best fix might be to just add a settings panel with an option to bypass the frame offsetting functionality if Mocha is already exporting your tracker files with the correct frame numbers. Later this week hopefully 
1 Like