Maybe someone has faced this before… Gmask tracer with the tracer key enabled works very well but when it has a camera track applied the output is completely black, I can see the key/matte when F8 Object Solo but the output is not correct, this only happens when there’s a camera track. The Tracer’s node output camera is set to the imported camera and the gmask as well
Does anyone know what’s the reason of this?
You might have tried these already, but the most likely simple reasons are:
a) Is your output set to Comp or Matte? If you want a matte out, by the sounds of it you do, make sure you have a Matte Out.
b) Is the camera setting on output set to the correct camera? If you have the default one in there as well as a tracked camera, you need to make sure you’re using the one you want to be using.
Yes, both settings are checked. Nothing works, its like the camera shifts when output
And it’s part of the selected objects to output?
Ah yes I’ve come accross this problem. Haven’t solved it though.
Maybe there’s a hiccup between the camera track data and the Gmask settings? Double-checking that alignment might help clear things up
I think this is a misfeature in the way the tracer works inside the node. The tracer goes bonkers when the camera is animated, this was first evident to me when I was using a tracked camera in the gmask tracer, but happens with a manually animated camera as well.
The tracer looks through the default camera position to define the tracer fg/bg when in object view mode, but the mask is drawn through the animated camera. Even if your default camera is animated it looks through the default position.
I tested this with an action and a gmask with the same camera animation. Check out the video. I’ll report this to support…
Confirming this is still an issue … just wasted an hour trying to figure out what’s going on.
@Sinan Do you have a case ID for this?
Turns out I forgot to report this. I should report it as a bug, right? @fredwarren
Yes, please.
Case 23834651 - Gmask tracer bug
This is from an automated response after I provided the info. I don’t know if there needs to be a follow-up.
You’ll get a response from support and then they will work with you to reproduce the issue, and if they can confirm it they’ll escalate it and give you a different number that’s passed along to the development team.
@fredwarren
This is what support told me:
Hi Sinan,
After being able to reproduce the behaviour you described and share it with our Development Team, they reported back that it should be considered a feature request.
You can create that feature request in the feedback site:
Is it a feature or a bug?
We treat this as a feature request because the behaviour is that the GMask Tracer does the key on the input media and not through the animated selected camera.
The “intended” behaviour was the former, therefore the application behaves as intended and it is not a defect.
This has been added as a feature request…
FI-03430
I’ve added a link to the feature request:
https://feedback.autodesk.com/project/feedback/view.html?cap=5afe6c84-5cb3-447a-b36c-cbd7f0688f84&uf=62c431e5-706f-4e02-8c9f-5bb08e644aaf&slsid=7b24c58d-54ff-4d59-a337-99b09287d18f
Although I will say that personally I disagree with the concept of how popular a feedback request is being a major reason to implement it “or not”.
Something ive often struggled with the intended behaviour of 3d tracking gmasks in tracer is that you can’t draw the shapes in 3d space. The vertices are all xy coordinates. This actually has made it difficult for me with certain 3d tracks to be accurate with my masks. I came to the conclusion that the intended mask behaviour is a fudge. Would you agree @fredwarren ?
Adding/Manipulating the vertices in 3D Space would be really hard because they wouldn’t follow the cursor or a very very small movement would be needed to make the vertex travel a long way.
Not impossible, but one of these things that I think you would realize may not be as great in practice.
That’s fair, but having some control or knowledge of where the drawing projection plane lands in depth would solve a lot of those issues.
In reality I’m not sure how that would work. Maybe a 2 stage creation process where you draw then have an orthogonal view to commit to the depth of the drawing plane maybe. It’s a strange problem.
How does flame decide right now?