Mocha Pro 5.0.1 Masks imported into Flame are wildly the wrong size

I was working on a roto in Mocha v4 on a shot that is 5568x3132. I brought some of the roto’s into Flame on the same shot. Everything lined up fine. Now that I’ve upgraded to Mocha v5, I’m trying to bring the masks in an they are like 5x bigger than they should be.

I’ve tried bringing in the masks with the Mocha resolution set to both 1:1 and 1:2 and it’s the same result.

Any ideas? Because now that it converted my project and I’ve done a bunch more work I’m a bit screwed.

Let me confer with my dev team, I don’t know that we have seen this error before, but I’d like to check.

Roto’ing on another shot of a different size than the last, the resolution is 2144x1206 and the masks are coming in at the wrong size into Flame again. I had to scale them down to 89% to get them to be the same size as they were in Mocha.

OK, we are going to have to work with the Flame folks and try to get to the bottom of this issue. Thank you for letting us know. Can you email me at maryp@imagineersystems.com and I can track this issue and update you on our progress?

I run into this a lot and the only way I’ve found is a bit of a pain but it has always worked. When you load anything from mocha into flame that file is conforming to the project size not the image size that you tracked. (Which I think is the wrong behavior.) So what I do is make a new project called MochaTrash that is the size of the image I want. Then load the track and/or roto into there and immediately save it back out. Delete the project and switch to the real project and it should work. I am on a project now where I am stabilizing my plate using auto-scale before I go to mocha so every single plate is a different size. So I have had to make and delete many dummy setups in flame but it has always worked.

I tried editing the headers of the setup files mocha outputs to make them the right size but it doesn’t seem to help. It seems like I’m just missing a step because it seems like that should be a way to do it.

 

Brian

Getting the same issue here. Mocha Pro Plugin for Adobe. Exporting to Flame 2018.3 on OSX. Has there been headway made here?

I thought this was addressed, let me confirm with our product manager. I could be wrong! Make sure your versions are up to date in the meantime.

Cheers,
Mary

Thanks for looking into this Mary, I’m running MochaPro Plugin ver. 5.6.0

Steve

How are you applying the Gmask in flame? Can you provide a step by step reproduction procedure?

Hi Martin,
My process is as follows:

  1. Select root layers in Mocha Pro (Plug-In for Adobe)
  2. Export Shape Date as Flame GMask Script - this is saved on a directory on my framestore
  3. In Flame, I create a new Batch reel, then grab a GMask node and load my shape export from Mocha as a gmask. As battles_cb8d9-2-2 said, the only way to get the mask to scale properly is to save it in a dummy project, then re-save it back.
  4. Does motion blur which has been applied in Mocha not translate to Flame? I could not get it to work, quite frustrating. Not ruling out operator error.
    I’d be happy to supply you with the project in question - Mocha and/or Flame setups.
    Thanks!
    Steve

Hi Steve,

Is the proxy in After Effects set to Full?

In answer to your question on Motion Blur, no, the current Gmasks we save are the collapsed shape and track data, so you would only be able to get manual feathering work exported.

We have had some requests to split out the track and shape data into two separate nodes for Gmask/tracer so the motion blur can remain intact. We are looking into supporting this in a later version.

To get mocha and flame to work together the flame project has to be the exact same size as the image you are tracking in mocha. If you have a 3k plate in a 2k project it won’t work. The only work around I have found is to make a new project that is the size of the plate, import the mocha mask to the GMask, export it, go back to your original project, and import your intermediate GMask.

Brian

Thanks for clearing this up Martin.

Steve

Thanks Brian,

It’s certainly not ideal, but it works.

Steve