Another way to look at it is this, let the projection camera move with the axis, but also have the geo being projected on move as well.
------ - camera input connected to axis (all offset transforms only on this axis, no change to camera at all) - place TransformGeo node under geo being projected upon (after your project3D shader and/or assign material node) - hook transformGeo's axis input to the Axis ( TransformGeo should be completely Zero'd out, inheriting all its transforms thru the axis input only) - now your proj camera & geo will move and rotate with the single axis and the projection will stay intact --------- I agree though, a "Maintain offset " function like in Maya would be better! Ari Blue Sky Sent from my iPhone > On Dec 12, 2013, at 2:08 AM, Ben Dickson <ben.dick...@rsp.com.au> wrote: > > Ahh, right.. I don't think it's easily doable in Nuke, but you can > achieve a similar result to that GIF in a few ways: > > Simplest way is to use the pivot control in the axis: Connect an axis > upstream of the camera, press ctrl+alt and shift it around where you > want to pivot, then you can rotate the axis etc > > More complicatedly, you can do this, which is kind of a pain to setup > (similar to what localaxis does, if not exactly): > https://gist.github.com/dbr/7924086 > > >> On 12/12/13 17:03, matt estela wrote: >> Hmm, more like this, explained through the magic of gifs and imgur: >> >> http://imgur.com/9Cv62j7 >> >> Basically, when you parent in Maya, Maya assumes you want the child to >> stay at its current location. Nuke doesn't. That's weird. >> >> >> >> >> On 12 December 2013 12:45, Ben Dickson <ben.dick...@rsp.com.au >> <mailto:ben.dick...@rsp.com.au>> wrote: >> >> Slightly hard to describe in writing, but I think this is what you are >> after, >> https://gist.github.com/dbr/7921735 >> >> You parent an axis under the "shot camera", then you parent a new camera >> under this transform.. allowing axis's transform controls to move the >> camera in "object-local" space >> >> The other way of doing it is >> http://www.nukepedia.com/python/3d/localaxis/ >> ..which essentially sets up an expression-linked version of the >> transform node with all the parameters negated ("-transform" and >> "1/scale" etc) and transform/rotation orders reversed. This puts the >> object at the origin, then you can do an object-local and reapply the >> original transform >> >> It's definitely not as intuitive as Maya in this respect, and tends to >> feel like all the steps have to be performed backwards.. but it's quite >> "simple", all 3D transforms nodes are just transform matrices, and they >> all concatenate together. It's true for Axis nodes, TransformGeo, the >> object's transform controls etc, and is also exactly how the 2D >> transforms nodes concatenate >> >> It would be nice if there was an additional axis input, "object local" >> which would be like the "local matrix" control.. but I'm not sure it'd >> quite remove the desire for a Maya-like parenting system.. I guess the >> other way would be a TransformGeo-like node which could apply to an Axis >> or Camera (or I could be getting entirely confused) >> >>> On 12/12/13 08:24, matt estela wrote: >>> In maya, if you parent one object to another, the default behaviour is >>> for the child object to keep its current position. There's an >> option to >>> turn this off, but its rarely used. >>> >>> In nuke, the default behaviour is to not main the current >> position, and >>> snap to a new location as if the parent is the world origin. Is >> there a >>> way to make it behave like maya? >>> >>> I know there's tricks for meshes, but last night I stumped a few >>> lighters in the department where I wanted to parent a camera to an >> axis, >>> but leave it in its current location, couldn't do it. >>> >>> We tried doing stuff like expressions that subtract the values of the >>> parent at frame 1 from the parent transforms, kind of worked, kind of >>> didn't. In the end I just went back to maya, baked keyframes, >> exported a >>> camera. >>> >>> I assume we're missing a trick... right? RIGHT??? >>> >>> >>> -matt >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> Nuke-users@support.thefoundry.co.uk >> <mailto:Nuke-users@support.thefoundry.co.uk>, >> http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> -- >> ben dickson >> 2D TD | ben.dick...@rsp.com.au <mailto:ben.dick...@rsp.com.au> >> rising sun pictures | www.rsp.com.au <http://www.rsp.com.au> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk >> <mailto:Nuke-users@support.thefoundry.co.uk>, >> http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > -- > ben dickson > 2D TD | ben.dick...@rsp.com.au > rising sun pictures | www.rsp.com.au > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users _______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
