Hi Ivan,
yep we dont want to touch the cameras in nuke in anyway so it is fine
they are not animatable anymore.
We just had some cases where the interchange format using euler values,
created strange artefacts when using motionblur, when using the data
directly in the matrix it was all fine...
The data was coming from renderman in that case...
Most recently I had a cam coming from vray and the data in euler values
was "jittering" whereas the matrix data stayed steady as it was supposed
to...
But that might be due to the math behind the euler extraction...
thanks for the input!
-johannes
Am 10/1/12 10:15 AM, schrieb Ivan Busquets:
Hi Johannes,
That's a different monster, in my opinion, which is to try and match
the camera (and motionblur) from an existing set of renders. In this
case, matching your renders is probably more important than a) keeping
the camera animatable, and b) having accurate motionblur.
If I had to guess, I'd say there's 2 possible reasons why you're
getting a better match by setting the local_matrix directly to the one
in the exr's metadata, instead of converting that back to Euler rotations:
1. No way to know the original rotation order from a transformation
matrix alone. So, if you're converting to Euler, you'd have to choose
an arbitrary rotation order, which may or may not match the one of the
original camera. Of course, you could have known the correct rotation
order beforehand, in which case this shouldn't be an issue.
2. How is your renderer (the one that produced the exrs) handling
motionblur? Assuming you're using Renderman, is subframe MotionBlur
turned on? Otherwise the renderer might just be doing a linear
interpolation between the camera position/rotation at each integer
frame, which is the same you'll get in Nuke when explicitly setting a
"local_matrix".
I'm not an expert in Renderman, though, so someone with more insight
might be able to confirm or deny this.
Having said that, I've used both approaches to re-create a camera from
Renderman metadata, and I've rarely had motionblur issues with one or
the other. The few occasions where I have found differences has always
been due a different rotation order.
Hope this helps.
Cheers,
Ivan
On Mon, Oct 1, 2012 at 12:14 AM, Johannes Hezer
<[email protected] <mailto:[email protected]>> wrote:
Hi Ivan,
that is interesting with the motionblur.
In my experience sofar, when getting cameras into nuke via exrs it
was always best to use the matrix on the camera instead of
converting all back to euler values in the rotation knobs ?!
It was more accurate and motionblur issues were gone ?
I know that is not exactly what you stated but I would be
interested if you expierenced the same thing with the cam data
from exrs?
cheers
Am 10/1/12 2:22 AM, schrieb Ivan Busquets:
Might be splitting hairs, but since this comes up every now and
then, I think it's worth noting that there are some important
caveats to using the local_matrix knob to do that for animated
cameras:
- You lose the ability to tweak the animation afterwards.
- Inaccurate motionblur. If you bake animated transform knobs
into a single animated matrix, you're effectively losing the
ability to interpolate "curved" paths correctly. The matrix
values will interpolate between frames, but there's no guarantee
that the result of that interpolation will match the
transformation you'd get by interpolating the original
rotation/translation/scale values.
Getting back to the use case of the original post, I would
recommend keeping the two separate transforms when exporting out
to Maya.
For one, if you use the "forced local matrix" approach you'll
have no easy way to transfer that to Maya (as in, it won't export
correctly when writing an FBX file, for example).
But also, if you're planning to refine animation later on, it
might be easier to do so on the original transformations.
On Sun, Sep 30, 2012 at 2:18 PM, Marten Blumen <[email protected]
<mailto:[email protected]>> wrote:
Stoked, solved it. Very easy thanks to the exposed World and
Local Matrix's.
Attached is a verbose tutorial nuke script; all instructions
included in stickies. Hit me up if it needs more work. thanks!
On 29 September 2012 16:08, Marten Blumen <[email protected]
<mailto:[email protected]>> wrote:
I just retested my test and it only worked on simple
setups. Probably need expert equations to make it work
properly!
On 29 September 2012 15:39, C_Sander
<[email protected]
<mailto:[email protected]>> wrote:
I guess now would be a good time to learn
expressions. I'll check that out, thanks!
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
