RE: Car wheel motion blur
One way I have found to do really good motion blur on wings and other stuff that needs big MB (did not test this case with it as the scene that was posted was 2012 or 2013 and I am running 2011 here) is to create the animation cycle over a number of frames - say wing flap - up fr1 - full down fr 5 - up again fr 10 - then I make this a clip. I then scale this clip really small and cycle it - you get really nice (more than 25/24fps able) MB like this - I guess you can adjust the scale of the clip to get the MB level you want. This works superb for props on planes and heli blades too - works 100% in MR and Arnold. Not sure it I am missing the problem as I am bouncing between problems here and skipped over the mails - just thought I would mail my MB solution here - might be worth a try. S. _ Sandy Sutherland Technical Supervisor sandy.sutherl...@triggerfish.co.za _ From: softimage-boun...@listproc.autodesk.com [softimage-boun...@listproc.autodesk.com] on behalf of Arvid Björn [arvidbj...@gmail.com] Sent: 19 July 2012 10:17 To: softimage@listproc.autodesk.com Subject: Re: Car wheel motion blur Thanks everyone for your insight and suggestions! Raffaele: In this particular case I wasn't so bothered with the aesthetics of the blur, but the wheels seemed to flicker in and out of existence, some frames the car would appear to hover, others the wheel looked extremely stretched in one axis, sometimes I get the arc, and in other shots it would work just fine. Enveloping the wheel always produce the correct result, even with silly speeds, so the whole thing would go away if MR could just be forced to evaluate motion per-point instead of using object transformations, as an option. It's not even slow actually, so this particular optimization just creates more problems than in solves. Is this something that could be controlled by the host application, or is it strictly a Mental Ray issue? Seems like Soft should be able to send vectors per-point to MR? On Thu, Jul 19, 2012 at 2:29 AM, Raffaele Fragapane raffsxsil...@googlemail.commailto:raffsxsil...@googlemail.com wrote: It's not an uncommon problem in rendering in general. When we do things like wheels and propellers we normally render wedges of various settings at different incident angles, speeds and so on to make sure the blur looks correct. In these cases the physical accuracy of the motion is absolutely irrelevant (IE: the wheel is theoretically slipping on the ground all the time or the propellers is at a fraction of the RPMs required for the plane to move at that speed), the quality of the blur is everything to sell those things off. The B52 in Sucker Punch took a full two days of testing and rendering wedges and an operator that would modulate the RPMs based on aesthetic choices to produce usable frames. Another classic issue is emulating the forward + rewind + stable blur seen in footage of car wheels accelerating past a camera, which we had to implement controls for so that people could animate parameters based on the actual aesthetics of the blur and motion they wanted instead of animating rotations and shooting in the dark. This was the case with PRMan and Mantra and was run with all kind of data, from straight point caches with a stupid amount of subframes to straight transforms to deformation with additional data coming from a monitored transform. Not that it's not an issue or that it shouldn't be looked at, just saying that if you want to do spinning objects and you want that cinematic blur people are used to you'll have to bite the bullet and NOT go for temporally or physically accurate. Even shooting these things for real on a set often requires tests and wedges for the rigs to be timed and controlled so the DoP gets what he wants. On Thu, Jul 19, 2012 at 9:44 AM, Jack Kao jack@grapecity.commailto:jack@grapecity.com wrote: I wonder if it's something to do with Mental Ray specific? -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
RE: Car wheel motion blur
Is this something that could be controlled by the host application, or is it strictly a Mental Ray issue? Seems like Soft should be able to send vectors per-point to MR? Yes, using UserMotion properties or PointUserMotion attributes. However, you need to calculate and set the vectors you want. See: http://download.autodesk.com/global/docs/softimage2013/en_us/userguide/index.html?url=files/GUID-1E30919E-2C57-442B-8FE8-E522B0E2342C.htm,topicNumber=d30e379979 gray From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Sandy Sutherland Sent: Thursday, July 19, 2012 04:40 AM To: softimage@listproc.autodesk.com Subject: RE: Car wheel motion blur One way I have found to do really good motion blur on wings and other stuff that needs big MB (did not test this case with it as the scene that was posted was 2012 or 2013 and I am running 2011 here) is to create the animation cycle over a number of frames - say wing flap - up fr1 - full down fr 5 - up again fr 10 - then I make this a clip. I then scale this clip really small and cycle it - you get really nice (more than 25/24fps able) MB like this - I guess you can adjust the scale of the clip to get the MB level you want. This works superb for props on planes and heli blades too - works 100% in MR and Arnold. Not sure it I am missing the problem as I am bouncing between problems here and skipped over the mails - just thought I would mail my MB solution here - might be worth a try. S. _ Sandy Sutherland Technical Supervisor sandy.sutherl...@triggerfish.co.zamailto:sandy.sutherl...@triggerfish.co.za _ From: softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com [softimage-boun...@listproc.autodesk.com] on behalf of Arvid Björn [arvidbj...@gmail.com] Sent: 19 July 2012 10:17 To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Car wheel motion blur Thanks everyone for your insight and suggestions! Raffaele: In this particular case I wasn't so bothered with the aesthetics of the blur, but the wheels seemed to flicker in and out of existence, some frames the car would appear to hover, others the wheel looked extremely stretched in one axis, sometimes I get the arc, and in other shots it would work just fine. Enveloping the wheel always produce the correct result, even with silly speeds, so the whole thing would go away if MR could just be forced to evaluate motion per-point instead of using object transformations, as an option. It's not even slow actually, so this particular optimization just creates more problems than in solves. Is this something that could be controlled by the host application, or is it strictly a Mental Ray issue? Seems like Soft should be able to send vectors per-point to MR? On Thu, Jul 19, 2012 at 2:29 AM, Raffaele Fragapane raffsxsil...@googlemail.commailto:raffsxsil...@googlemail.com wrote: It's not an uncommon problem in rendering in general. When we do things like wheels and propellers we normally render wedges of various settings at different incident angles, speeds and so on to make sure the blur looks correct. In these cases the physical accuracy of the motion is absolutely irrelevant (IE: the wheel is theoretically slipping on the ground all the time or the propellers is at a fraction of the RPMs required for the plane to move at that speed), the quality of the blur is everything to sell those things off. The B52 in Sucker Punch took a full two days of testing and rendering wedges and an operator that would modulate the RPMs based on aesthetic choices to produce usable frames. Another classic issue is emulating the forward + rewind + stable blur seen in footage of car wheels accelerating past a camera, which we had to implement controls for so that people could animate parameters based on the actual aesthetics of the blur and motion they wanted instead of animating rotations and shooting in the dark. This was the case with PRMan and Mantra and was run with all kind of data, from straight point caches with a stupid amount of subframes to straight transforms to deformation with additional data coming from a monitored transform. Not that it's not an issue or that it shouldn't be looked at, just saying that if you want to do spinning objects and you want that cinematic blur people are used to you'll have to bite the bullet and NOT go for temporally or physically accurate. Even shooting these things for real on a set often requires tests and wedges for the rigs to be timed and controlled so the DoP gets what he wants. On Thu, Jul 19, 2012 at 9:44 AM, Jack Kao jack@grapecity.commailto:jack@grapecity.com wrote: I wonder if it's something to do with Mental Ray specific? -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee
Re: Car wheel motion blur
Here, I've recreated the problem in the simplest possible setup, no weird rotation order and it's centered on the null, just draw a region to see the problem. File: http://www.stopp.se/arvid/motionblurbug.scn Different rotation speeds of the ball yield different arcs though, so sometimes you'd get lucky to hit a number that doesn't show the problem, which is why the problem appear at random for us. The problem was solved by skinning the geo to the null instead of parenting it, which invokes deformation motion blur, but the scene gets more complex and the rig gets heavier. Please see if I've missed something in my settings, I'd love to solve the problem without skinning! Cheers On Tue, Jul 17, 2012 at 6:09 PM, Manny Papamanos manny.papama...@autodesk.com wrote: I did a quick test and the blur seemed to look good in MR on a simple cube spinning on a moving cube hierarchy. Be sure you don't use 'offset' in the MB settings or the wheels or they may look like they are coming out of the wheel wells. Check the transforms on your 'centers' on the wheels and all the parents for weirdness. If something weird is based on the parents, one way out of this is to plot and then use that motion on the wheels. Also, perhaps playing with the 'rotation order' may help, I would make sure that the spinning axis is first on the list. -manny|SI support From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Arvid Björn Sent: Tuesday, July 17, 2012 10:20 AM To: softimage@listproc.autodesk.com Subject: Re: Car wheel motion blur Thanks, I tried your suggestion, but there's nothing wrong with the parenting. It is related to parenting, but that's not where the problem lies. It works fine with deformation motion blur with the exact same center of rotation, so that proves that the problem is in how transformation motion blur is being evaluated. When evaluated per point with a global vector, everything's fine. I wish I could force MR to do that even though I'm not actually deforming anything. On Tue, Jul 17, 2012 at 1:56 PM, Alok Gandhi alok.gandhi2...@gmail.com mailto:alok.gandhi2...@gmail.com wrote: Most probably the motion samples are creating an arc due to parenting. What you need to do is to check this is take the fcurves and scale them quite a bit. This will allows you to see in slo-mo the trajectory of the wheel as it moves along. If you see the undesired arcing then I would suggest changing the parenting so the center of motion is at the center of the wheels.
RE: Car wheel motion blur
Have you played with adjusting the motion steps in the renderer options?
Re: Car wheel motion blur
Yep, more steps only produce a smoother error :-) On Wed, Jul 18, 2012 at 11:03 AM, Jack Kao jack@grapecity.com wrote: Have you played with adjusting the motion steps in the renderer options?
Re: Car wheel motion blur
I have reproduced this behavior. 2013 SP1. various types of objects as parent and child. Even with both rotation and translation on one object. Manny -- try using a fairly large translation amount per frame. At low speeds it's not really noticeable. At high speeds it's glaringly evident. At higher speeds still, it's hard to see again. Looks like a real bug to me. On Wed, Jul 18, 2012 at 5:21 AM, Arvid Björn arvidbj...@gmail.com wrote: Yep, more steps only produce a smoother error :-) On Wed, Jul 18, 2012 at 11:03 AM, Jack Kao jack@grapecity.com wrote: Have you played with adjusting the motion steps in the renderer options?
RE: Car wheel motion blur
You're right. If you paste the parent's translation to the spinning element, it still reproes as well, so hierarchy is not important here. From what I can see, despite the linear motion, the ark you're getting is because although the object is moving in a linear way, it has to evaluate the spinning motion also for the motion vectors. I have a feeling it's always been like this. Setting the wheels to 'deformation blur' may seem ok but are your 'deform' 'motion steps' set to 1? I made a quick video here: http://www.screencast.com/t/gHNvdMW0X2JC As you can see, it seems ok when you set the transform steps to 1 (Perhaps your deform steps were set to 1?) I'd have to check in previous versions if it's the same. I should have some time later and I'll let u know before eod. -manny|SI support From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ed Manning Sent: Wednesday, July 18, 2012 12:48 PM To: softimage@listproc.autodesk.com Subject: Re: Car wheel motion blur I have reproduced this behavior. 2013 SP1. various types of objects as parent and child. Even with both rotation and translation on one object. Manny -- try using a fairly large translation amount per frame. At low speeds it's not really noticeable. At high speeds it's glaringly evident. At higher speeds still, it's hard to see again. Looks like a real bug to me. On Wed, Jul 18, 2012 at 5:21 AM, Arvid Björn arvidbj...@gmail.commailto:arvidbj...@gmail.com wrote: Yep, more steps only produce a smoother error :-) On Wed, Jul 18, 2012 at 11:03 AM, Jack Kao jack@grapecity.commailto:jack@grapecity.com wrote: Have you played with adjusting the motion steps in the renderer options? attachment: winmail.dat
RE: Car wheel motion blur
Same thing in 2010. Although it seems weird, I don't think it's a bug. It seems related to the way it evaluates the blur without calculating subframes. One way out of this is to double or triple the anim length (animationsequence animationscene) and then step render. -manny|SI support From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Manny Papamanos Sent: Wednesday, July 18, 2012 1:33 PM To: softimage@listproc.autodesk.com Subject: RE: Car wheel motion blur You're right. If you paste the parent's translation to the spinning element, it still reproes as well, so hierarchy is not important here. From what I can see, despite the linear motion, the ark you're getting is because although the object is moving in a linear way, it has to evaluate the spinning motion also for the motion vectors. I have a feeling it's always been like this. Setting the wheels to 'deformation blur' may seem ok but are your 'deform' 'motion steps' set to 1? I made a quick video here: http://www.screencast.com/t/gHNvdMW0X2JC As you can see, it seems ok when you set the transform steps to 1 (Perhaps your deform steps were set to 1?) I'd have to check in previous versions if it's the same. I should have some time later and I'll let u know before eod. -manny|SI support From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ed Manning Sent: Wednesday, July 18, 2012 12:48 PM To: softimage@listproc.autodesk.com Subject: Re: Car wheel motion blur I have reproduced this behavior. 2013 SP1. various types of objects as parent and child. Even with both rotation and translation on one object. Manny -- try using a fairly large translation amount per frame. At low speeds it's not really noticeable. At high speeds it's glaringly evident. At higher speeds still, it's hard to see again. Looks like a real bug to me. On Wed, Jul 18, 2012 at 5:21 AM, Arvid Björn arvidbj...@gmail.commailto:arvidbj...@gmail.com wrote: Yep, more steps only produce a smoother error :-) On Wed, Jul 18, 2012 at 11:03 AM, Jack Kao jack@grapecity.commailto:jack@grapecity.com wrote: Have you played with adjusting the motion steps in the renderer options? attachment: winmail.dat
Re: Car wheel motion blur
it might not be a bug, but I wouldn't call it a feature. ;-) On Wed, Jul 18, 2012 at 1:59 PM, Manny Papamanos manny.papama...@autodesk.com wrote: Same thing in 2010. Although it seems weird, I don't think it's a bug. It seems related to the way it evaluates the blur without calculating subframes. One way out of this is to double or triple the anim length (animationsequence animationscene) and then step render. -manny|SI support
RE: Car wheel motion blur
Hi Matt. You're right, however, if you look here: http://www.screencast.com/t/gHNvdMW0X2JC this happens even with a short rotation shift per frame. I'll try to ask a Maya or Max guy to repro. -manny From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Wednesday, July 18, 2012 2:55 PM To: softimage@listproc.autodesk.com Subject: RE: Car wheel motion blur The issue is caused by extreme rotation values. Motion blur typically solves rotations along the shortest arc between frames. Which implies the maximum rotation you can have between frames which solves correctly is 179.9 degrees or else you'll get the 'rewind' effect. Mental ray does have some built-in logic to solve on a window a little larger than 179.9, but probably not beyond 360 degrees. Mental ray is largely dependent on information coming from the host application to resolve these kinds of things In your case, the difference between frames is 421,039.2 degrees which is way beyond that solvable range. The motion blur arc is so stretched out it's wrapping around itself hundreds of times like thread wrapped around a spool. Your shutter open/close times are so close together it reveals only a very tiny portion of that path which results in the strange arc you see. The solution is to reduce the number of rotations by a multiple which retains the persistence-of-vision of the wheels appear to rotate correctly, but where the delta between frames is less than 360 degrees. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Arvid Björn Sent: Wednesday, July 18, 2012 12:58 AM To: softimage@listproc.autodesk.com Subject: Re: Car wheel motion blur Here, I've recreated the problem in the simplest possible setup, no weird rotation order and it's centered on the null, just draw a region to see the problem. File: http://www.stopp.se/arvid/motionblurbug.scn Different rotation speeds of the ball yield different arcs though, so sometimes you'd get lucky to hit a number that doesn't show the problem, which is why the problem appear at random for us. The problem was solved by skinning the geo to the null instead of parenting it, which invokes deformation motion blur, but the scene gets more complex and the rig gets heavier. Please see if I've missed something in my settings, I'd love to solve the problem without skinning! Cheers On Tue, Jul 17, 2012 at 6:09 PM, Manny Papamanos manny.papama...@autodesk.commailto:manny.papama...@autodesk.com wrote: I did a quick test and the blur seemed to look good in MR on a simple cube spinning on a moving cube hierarchy. Be sure you don't use 'offset' in the MB settings or the wheels or they may look like they are coming out of the wheel wells. Check the transforms on your 'centers' on the wheels and all the parents for weirdness. If something weird is based on the parents, one way out of this is to plot and then use that motion on the wheels. Also, perhaps playing with the 'rotation order' may help, I would make sure that the spinning axis is first on the list. -manny|SI support From: softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Arvid Björn Sent: Tuesday, July 17, 2012 10:20 AM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Car wheel motion blur Thanks, I tried your suggestion, but there's nothing wrong with the parenting. It is related to parenting, but that's not where the problem lies. It works fine with deformation motion blur with the exact same center of rotation, so that proves that the problem is in how transformation motion blur is being evaluated. When evaluated per point with a global vector, everything's fine. I wish I could force MR to do that even though I'm not actually deforming anything. On Tue, Jul 17, 2012 at 1:56 PM, Alok Gandhi alok.gandhi2...@gmail.commailto:alok.gandhi2...@gmail.commailto:alok.gandhi2...@gmail.commailto:alok.gandhi2...@gmail.com wrote: Most probably the motion samples are creating an arc due to parenting. What you need to do is to check this is take the fcurves and scale them quite a bit. This will allows you to see in slo-mo the trajectory of the wheel as it moves along. If you see the undesired arcing then I would suggest changing the parenting so the center of motion is at the center of the wheels. attachment: winmail.dat
Re: Car wheel motion blur
Most probably the motion samples are creating an arc due to parenting. What you need to do is to check this is take the fcurves and scale them quite a bit. This will allows you to see in slo-mo the trajectory of the wheel as it moves along. If you see the undesired arcing then I would suggest changing the parenting so the center of motion is at the center of the wheels.
Re: Car wheel motion blur
Thanks, I tried your suggestion, but there's nothing wrong with the parenting. It is related to parenting, but that's not where the problem lies. It works fine with *deformation* motion blur with the exact same center of rotation, so that proves that the problem is in how *transformation *motion blur is being evaluated. When evaluated per point with a global vector, everything's fine. I wish I could force MR to do that even though I'm not actually deforming anything. On Tue, Jul 17, 2012 at 1:56 PM, Alok Gandhi alok.gandhi2...@gmail.comwrote: Most probably the motion samples are creating an arc due to parenting. What you need to do is to check this is take the fcurves and scale them quite a bit. This will allows you to see in slo-mo the trajectory of the wheel as it moves along. If you see the undesired arcing then I would suggest changing the parenting so the center of motion is at the center of the wheels.
RE: Car wheel motion blur
I did a quick test and the blur seemed to look good in MR on a simple cube spinning on a moving cube hierarchy. Be sure you don't use 'offset' in the MB settings or the wheels or they may look like they are coming out of the wheel wells. Check the transforms on your 'centers' on the wheels and all the parents for weirdness. If something weird is based on the parents, one way out of this is to plot and then use that motion on the wheels. Also, perhaps playing with the 'rotation order' may help, I would make sure that the spinning axis is first on the list. -manny|SI support From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Arvid Björn Sent: Tuesday, July 17, 2012 10:20 AM To: softimage@listproc.autodesk.com Subject: Re: Car wheel motion blur Thanks, I tried your suggestion, but there's nothing wrong with the parenting. It is related to parenting, but that's not where the problem lies. It works fine with deformation motion blur with the exact same center of rotation, so that proves that the problem is in how transformation motion blur is being evaluated. When evaluated per point with a global vector, everything's fine. I wish I could force MR to do that even though I'm not actually deforming anything. On Tue, Jul 17, 2012 at 1:56 PM, Alok Gandhi alok.gandhi2...@gmail.commailto:alok.gandhi2...@gmail.com wrote: Most probably the motion samples are creating an arc due to parenting. What you need to do is to check this is take the fcurves and scale them quite a bit. This will allows you to see in slo-mo the trajectory of the wheel as it moves along. If you see the undesired arcing then I would suggest changing the parenting so the center of motion is at the center of the wheels. attachment: winmail.dat
