Thanks for the nice example, Nathan. Another idea that Ivan had (I hope you don't mind me mentioning, Ivan) was to define a function inside an onCreate() python callback embedded in a gizmo that for example tells the input to ignore a Dot class.
Basically these options we've mentioned are portable which I think is good for Nukepedia etc, rather than relying on a pipeline setup. On 11 August 2011 21:38, Nathan Rusch <[email protected]> wrote: > Throwing in one more possible alternative here. It’s a TCL function that > just walks up until it finds a knob named "focal" on any node hooked to any > primary input and returns the value of that. It’s a bit longer than your > average expression, but if you use multi-line expression mode, it’s easy to > keep it formatted nicely. > > > [proc camFocal node { > > if {[value $node.input0.focal 0]} { > > return [value $node.input0.focal] > > } else { > > return [camFocal [node $node.input0]] } > > }] > > [camFocal this] > > > > If you need something more generic (like finding the first camera node), > you could replace the [value ...] tests with [class $node] == "Camera2" or > something. Of course, at a certain point, a Python expression is probably > going to become easier to maintain, but if you’re a die-hard TCL user for > expressions, it might be worth a shot. > > > > Anyway, just another idea... > > -Nathan > > > *From:* Erik Winquist <[email protected]> > *Sent:* Thursday, August 11, 2011 6:50 PM > *To:* Nuke user discussion <[email protected]> > *Subject:* Re: [Nuke-users] reference camera data with expressions > > > pretty slick workaround, michael. > > nice one. > > erik > > > Michael Garrett wrote: I got something working that seems to enable > metadata in the camera pipe. So you could add this right after the camera, > where you don't need a Dot to keep things clean, then access camera values > via metadata. Not ideal, but it could be helpful: > > set cut_paste_input [stack 0] > version 6.2 v1 > push $cut_paste_input > Group { > name AddCamMetaData > selected true > xpos -152 > ypos -129 > addUserKnob {20 User} > addUserKnob {41 shownmetadata l "" -STARTLINE T > ViewMetaData2.shownmetadata} > } > Input { > inputs 0 > name Input1 > xpos 61 > ypos -238 > } > ModifyMetaData { > metadata { > {set focal "\[value parent.input0.focal]"} > } > name ModifyMetaData1 > selected true > xpos 61 > ypos -176 > } > ViewMetaData { > name ViewMetaData2 > xpos 61 > ypos -150 > } > Output { > name Output1 > xpos 61 > ypos -40 > } > end_group > Blur { > size {{"\[metadata focal]"}} > name Blur3 > selected true > xpos -152 > ypos -103 > } > > > > > On 11 August 2011 14:59, Michael Garrett <[email protected]> wrote: > Hi Ivan, great, thanks! I was just trying Camera1.focal > > > > > On 11 August 2011 14:47, Ivan Busquets <[email protected]> wrote: > Hi Michael, > > You can use tcl expressions in the "value" field of a ModifyMetadata node. > > ex: > [value Camera1.focal] > > On Thu, Aug 11, 2011 at 2:40 PM, Michael Garrett <[email protected]> > wrote: > > Do you mean expression link to the modifymetadata "value" field? How > > exactly do you do this? > > > > On 11 August 2011 14:36, Frank Rueter <[email protected]> wrote: > >> > >> You can expression link a camera's parameter to generically create meta > >> data. But of course this creates the same problem. It would be good to > have > >> multiple inputs for the ModifyMetadata node that allows any type of > input > >> type to do this sort of thing (I guess input 0 would be the type being > >> passes through like a copy node) > >> > >> > >> On Aug 11, 2011, at 1:20 PM, Paul Raeburn < > [email protected]> > >> wrote: > >> > >> I wondered about that, but metadata node dont work in camera pipes, so I > >> ran into a dead end. Getting the name of the camera node node world be > >> great (as per Ivans recommendation). Ideally it would be great to et > the > >> data from the camera pipe directly, so it can be modified by downstream > axis > >> etc, but I assume that a foundry question. > >> Any suggestions on how to access the metadata of the camera pipe? > >> > >> On 12 August 2011 05:51, Frank Rueter <[email protected]> wrote: > >>> > >>> Try "[topnode]" which will give you the top most node of a stream. > >>> Obviously it won't work if the camera's parent pipe is connected. In > that > >>> case you will need a script that walks upstream and returns the first > camera > >>> node, then use that in your expression. Or use meta Data to make the > camera > >>> info flow in the stream which is more elegant and probably faster. > >>> > >>> > >>> > >>> On Aug 10, 2011, at 8:24 PM, Paul Raeburn < > [email protected]> > >>> wrote: > >>> > >>> > > >>> > We have been using references tot he input node and then values to > get > >>> > values from a camera node. ie. NoOp1.input.focal > >>> > > >>> > This works fine but breaks if there is anything in between the NoOp > and > >>> > the camera, so you can tidy up the script with Dots or end up with > multiple > >>> > cameras just to be tidy. > >>> > > >>> > Is there a way to get camera stream directly, or even the name of the > >>> > camera node from the stream? > >>> > > >>> > thanks > >>> > > >>> > Paul Raeburn > >>> > _______________________________________________ > >>> > 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 > >> > >> _______________________________________________ > >> 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 > > > > > > _______________________________________________ > > 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 > > > ------------------------------ > > _______________________________________________ > Nuke-users mailing [email protected], > http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > -- > erik winquist > weta digital > > ------------------------------ > _______________________________________________ > 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 >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
