Gaffer Motion Blur vs MtoA Motion Blur

[Sachin Shrestha]

Hi John and gaffer devs,

Our TDs are reporting some issues with motion blur in gaffer. There seem to be couple of problems from what I have gathered from them so far.

1. In Maya, when we set 3 motion keys in the render globals, we get 3 motion keys for each object in the ass file. However, if we set 3 segments on the StandardAttributes in gaffer we seem to be getting 4 keys on the object instead. Unless we are misinterpreting the nomenclature in mtoa vs gaffer, we would expect the same number of motion blocks in either packages. Also, the motion blur results for the same settings do not seem to match between MtoA and gaffer.
2. Arnold generally expects frame relative motion_start and motion_end whereas gaffer seems to be exporting absolute frames for those attributes. Not sure if that's by design or its leftovers from a prior version or if this should have no bearing on the final output.
3. We need to output motion vectors in some cases and as per the gaffer workflow we are turning off the sample motion option on the StandardOptions node. However, with this approach we don't seem to get the correct motion data on our custom fur procedurals in the scene. It only gets fixed once we override the camera shutter to an instantaneous shutter (as per the workflow in arnold docs). Also when providing instantaneous shutter values, for a center blur shutter length 0.5, the MtoA camera shutter values should be (0.5, 0.5) but in gaffer our TD had to set it to (0.25, 0.25). I have not debugged this at my end yet and since I can't share our fur procedural example, we are trying to check this problem in xgen procedural to determine if its a problem there as well.

I have attached a simple repro for #1 which demonstrates the difference in the motion blur results in MtoA vs gaffer. I have animated a simple cube to rule out any alembic motion interpolation issues and I see the difference in the mtoa and gaffer renders even in this simple scene. I will debug #3 further at my end and build some repro cases but in the meanwhile, it would be good to know your thoughts on this issue.

Cheers,

Sachin

[Sachin Shrestha]

Forgot to attach the simple repro.

[Andrew Kaufman]

Hi Sachin,

I think for #1 at least, we just have a nomenclature issue. MtoA seems to be dealing with motion keys, whereas Gaffer is dealing with motion segments (ie. the lines between the keys: X-X-X). So I would expect a render with 3 MtoA keys to match a render with 2 Gaffer segments. This seems like something worth clarifying in the Gaffer docs.

I suspect its probably a similar issue with shutter length. For me, (-0.25,0.25) seem like the right values for a single segment blur with 0.5 shutter length. I’m not sure how to make sense of (-0.5,0.5) to be honest... for me, that equates to a 1.0 shutter length. It’s almost as if MtoA is expecting a per-segment length rather than total shutter length? Maybe that’s standard practice on Maya?

Regarding the absolute sample times, this is definitely an issue that has been pointed out in the past... I know the Yeti and Golaem procedurals have the same issues in Gaffer. I don’t recall if there is a strict reason Gaffer uses absolute times or if we could support both. John will have to jog my memory here.

Hope that all makes sense.

Cheers,

Andrew

On Friday, 12 April 2019, Sachin Shrestha <noizf...@gmail.com> wrote:

Forgot to attach the simple repro.

--
You received this message because you are subscribed to the Google Groups "gaffer-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gaffer-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Andrew Kaufman - R&D Lead

Image Engine

studio: +1 (604) 874-5634 | and...@image-engine.com | www.image-engine.com



15 West 5th Avenue, Vancouver, BC, V5Y 1H4, Canada

If you are not the intended recipient, disclosure, copying, distribution and use of this email is prohibited. Please notify us immediately and delete this email from your systems. You may contact us at in...@image-engine.com if you do not wish to receive further commercial electronic messages. We may still send you messages for which we do not require consent.

[Sachin Shrestha]

Hi Andrew,

Thanks for chiming in here. Yes, for #1, we figured that it was perhaps a nomenclature issue and we just need to do (mtoa_motion_keys - 1) in gaffer. However, would you know why the motion blur result itself is different? Even my simple repro scene with a cube looks different in gaffer. It almost looks like the actual shutter lengths don't match in the arnold scene created by gaffer vs the one created by mtoa.

Re shutter length, mtoa interprets 0.5 shutter length as 180 shutter so that would be (-0.25, 0.25) for shutter open and close. So a 360 shutter would be (-0.5, 0.5) i.e. a shutter length of 1.

For motion vector with external procedurals, it seems like we have to use a combination of turning off sample motion for the alembic geo in gaffer (I believe the sample motion terminology and workflow is coming from prman days?) and also turning the camera shutter to instantaneous shutter (which is the suggested workflow as per the official arnold docs).

Cheers,

Sachin

[Daniel Dresser]

Gaffer's absolute times causing problems with external procedurals is a known issue, because everything else in the Arnold ecosystem uses relative shutters.  I've argued with John about it before, but maybe hearing that there are people encountering this problem in the wild will help persuade him :P

As for shutter alignment, something seems weird here.

From your second email:

> mtoa interprets 0.5 shutter length as 180 shutter so that would be (-0.25, 0.25)

That sounds correct to me, Gaffer should do the same.

From your first email about instantaneous shutter:

> for a center blur shutter length 0.5, the MtoA camera shutter values should be (0.5, 0.5) but in gaffer our TD had to set it to (0.25, 0.25).

If you agree that center blur shutter length 0.5 means a shutter of (-0.25, 0.25 ), why would MtoA choose an instantaneous sample at 0.5, which is completely outside the actual shutter?  That sounds wrong.

Your issue with needing to both set an instantaneous shutter and turn off sample motion when rendering with Arnold procedurals makes sense - we try to present a standardised interface across renderers, with things like a generic sample motion that affects any renderer the same way.  But we don't control how the procedural reacts, so you still need to set an instantaneous shutter for it.  I'll think about whether there's anything we can do to improve this.

-Daniel

[noizf...@gmail.com]

Hi Daniel,

Apologies for the delayed response.

Gaffer's absolute times causing problems with external procedurals is a known issue, because everything else in the Arnold ecosystem uses relative shutters.  I've argued with John about it before, but maybe hearing that there are people encountering this problem in the wild will help persuade him :P

This is becoming a major problem for us as the motion blur does not match for our fur/hair assets in gaffer since the motion_start/end are not frame relative. While debugging if I change the gaffer generated .ass file's motion statements to frame relative then the renders match what we expect. I'm ok with resolving this problem at our end with an internal gaffer build (although I think this should be helpful to everyone in general) if you can point me to the relevant modules in the gaffer source that I can modify. 

 

From your first email about instantaneous shutter:

> for a center blur shutter length 0.5, the MtoA camera shutter values should be (0.5, 0.5) but in gaffer our TD had to set it to (0.25, 0.25).

If you agree that center blur shutter length 0.5 means a shutter of (-0.25, 0.25 ), why would MtoA choose an instantaneous sample at 0.5, which is completely outside the actual shutter?  That sounds wrong.

I've never quite investigated why MtoA requires users to set instantaneous shutter like this but interestingly it seems that the latest MtoA versions now have an "Instantaneous Shutter" option in the motion blur section which seems the new recommended way of working with motion vectors. I'm yet to test it out and check what actual shutter values it exports. It looks like the arnold documentation has also been updated recently to reflect this change in the new versions but the autodesk site still refers to the old techniaues (which does explicitly state that we need to use shutter start/end as 0.5 for center blur).

Cheers,

Sachin

[noizf...@gmail.com]

Also, forgot to add another question. Currently context.get("frame") seems to take motion blur export into consideration and returns me the post motion blur translation frame. So, in case of shutter -0.25, 0.25 it returns me (actual frame - 0.25). Is there a way to return the actual frame instead?

Cheers,

Sachin