> Nuke's appears to be not be an integer, but the values in your tree appear > to either be 0.0 or 0.5, which is slightly odd >
Bbox boundaries in Nuke are also integers (just like Shake's DOD). The output value is always n.0 or n.5 because I'm averaging the center of the bbox. Of course this is by no means an accurate way of getting the transformation of a given point, but more an idea of something he could do without resorting to the NDK. Ideally, you'd want to write a plugin for that, I agree. Either one that exposes the concatenated matrix, or one where you could plug a stack of transforms and directly apply the result to one or more points. A "Reconcile2D" ? :) On Tue, Sep 6, 2011 at 8:47 PM, Ben Dickson <ben.dick...@rsp.com.au> wrote: > Heh, I remember trying the exact same thing in Shake years ago, to > transform a roto point instead of using a 4-point stablise - the problem is > the dod was an integer > > Nuke's appears to be not be an integer, but the values in your tree appear > to either be 0.0 or 0.5, which is slightly odd > > Seems like it'd be fairly simple to make a plugin which exposes the 2D > transform matrix, > http://docs.thefoundry.co.uk/**nuke/63/ndkdevguide/knobs-and-** > handles/output-knobs.html<http://docs.thefoundry.co.uk/nuke/63/ndkdevguide/knobs-and-handles/output-knobs.html> > > Ivan Busquets wrote: > >> it looks like nuke gives a rounding error using that setup (far >> values are .99902 instead of 1.0). probably negligible but I like >> 1.0 betta. >> >> >> One small thing about both those UV-map generation methods. Keep in mind >> that STMap samples pixels at the center, so you'll need to account for that >> half-pixel difference in your expression. Otherwise the resulting map is >> going to introduce a bit of unnecessary filtering when you feed it to an >> STmap. >> >> An expression like this should give you a 1-to-1 result when you feed it >> into an STMap: >> ------------------------------**---------------------- >> set cut_paste_input [stack 0] >> version 6.3 v2 >> push $cut_paste_input >> Expression { >> expr0 (x+0.5)/(width) >> expr1 (y+0.5)/(height) >> name Expression2 >> selected true >> xpos -92 >> ypos -143 >> } >> ------------------------------**---------------------- >> >> With regards to the original question, though, it's a shame that one >> doesn't have access to the concatenated 2d matrix from 2D transform nodes >> within expressions. Otherwise you could just multiply your source point by >> the concatenated matrix and get its final position. This information is >> indeed passed down the tree, but it's not accessible for anything but >> plugins (that I know). >> >> You could probably take advantage of the fact that the bbox is transformed >> the same way as your image, and you CAN ask for the bbox boundaries using >> expressions. So, you could have something with a very small bbox centered >> around your point of interest, transform that using the same transforms >> you're using for your kites, and then get the center of the transformed >> bbox, if that makes sense. It's a bit convoluted, but it might do the trick >> for you. >> >> Here's an example: >> ------------------------------**---------------------- >> set cut_paste_input [stack 0] >> version 6.3 v2 >> push $cut_paste_input >> Group { >> name INPUT_POSITION >> selected true >> xpos -883 >> ypos -588 >> addUserKnob {20 User} >> addUserKnob {12 position} >> position {1053.5 592} >> } >> Input { >> inputs 0 >> name Input1 >> xpos -469 >> ypos -265 >> } >> Rectangle { >> area {{parent.position.x i x1 962} {parent.position.y i x1 391} {area.x+1 >> i} {area.y+1 i}} >> name Rectangle1 >> selected true >> xpos -469 >> ypos -223 >> } >> Output { >> name Output1 >> xpos -469 >> ypos -125 >> } >> end_group >> Transform { >> translate {36 0} >> center {1052 592} >> shutteroffset centred >> name Transform1 >> selected true >> xpos -883 >> ypos -523 >> } >> set C48d17580 [stack 0] >> Transform { >> translate {0 -11} >> rotate -34 >> center {1052 592} >> shutteroffset centred >> name Transform2 >> selected true >> xpos -883 >> ypos -497 >> } >> set C4489ddc0 [stack 0] >> Transform { >> scale 1.36 >> center {1052 592} >> shutteroffset centred >> name Transform3 >> selected true >> xpos -883 >> ypos -471 >> } >> set C4d2c2290 [stack 0] >> Group { >> name OUT_POSITION >> selected true >> xpos -883 >> ypos -409 >> addUserKnob {20 User} >> addUserKnob {12 out_position} >> out_position {{"(input.bbox.x + input.bbox.r) / 2"} {"(input.bbox.y + >> input.bbox.t) / 2"}} >> } >> Input { >> inputs 0 >> name Input1 >> selected true >> xpos -469 >> ypos -265 >> } >> Output { >> name Output1 >> xpos -469 >> ypos -125 >> } >> end_group >> CheckerBoard2 { >> inputs 0 >> name CheckerBoard2 >> selected true >> xpos -563 >> ypos -623 >> } >> clone $C48d17580 { >> xpos -563 >> ypos -521 >> selected true >> } >> clone $C4489ddc0 { >> xpos -563 >> ypos -495 >> selected true >> } >> clone $C4d2c2290 { >> xpos -563 >> ypos -469 >> selected true >> } >> ------------------------------**---------------------- >> >> Cheers, >> Ivan >> >> >> >> >> >> >> On Tue, Sep 6, 2011 at 6:09 PM, J Bills <jbillsn...@flickfx.com <mailto: >> jbillsn...@flickfx.com**>> wrote: >> >> sure - looks even cleaner than the ramps crap done from memory - >> actually, now that I look at it for some reason it looks like nuke >> gives a rounding error using that setup (far values are .99902 >> instead of 1.0). probably negligible but I like 1.0 betta. nice >> one AK. >> so play around with this, joshua - >> >> set cut_paste_input [stack 0] >> version 6.2 v4 >> >> Constant { >> inputs 0 >> channels rgb >> name Constant2 >> selected true >> xpos 184 >> ypos -174 >> >> } >> Expression { >> expr0 x/(width-1) >> expr1 y/(height-1) >> name Expression2 >> selected true >> xpos 184 >> ypos -71 >> >> } >> NoOp { >> name WARP_GOES_HERE >> tile_color 0xff00ff >> selected true >> xpos 184 >> ypos 11 >> >> } >> Shuffle { >> out motion >> name Shuffle >> label "choose motion\nor other output\nchannel" >> selected true >> xpos 184 >> ypos 83 >> >> } >> push 0 >> STMap { >> inputs 2 >> channels motion >> name STMap1 >> selected true >> xpos 307 >> ypos 209 >> >> } >> >> >> >> >> >> On Tue, Sep 6, 2011 at 5:23 PM, Anthony Kramer >> <anthony.kra...@gmail.com >> <mailto:anthony.kramer@gmail.**com<anthony.kra...@gmail.com>>> >> wrote: >> >> Heres a 1-node UVmap for you: >> >> set cut_paste_input [stack 0] >> version 6.3 v2 >> push $cut_paste_input >> Expression { >> expr0 x/(width-1) >> expr1 y/(height-1) >> name Expression2 >> selected true >> xpos -480 >> ypos 2079 >> } >> >> >> >> On Tue, Sep 6, 2011 at 4:46 PM, J Bills <jbillsn...@flickfx.com >> <mailto:jbillsn...@flickfx.com**>> wrote: >> >> sure - that's what he's saying. think of the uv map as >> creating a "blueprint" of your transforms or distortions. >> >> after you have that blueprint, you can run whatever you want >> through the same distortion and repurpose it all day long >> for whatever you want that might need it. so if you need it >> for some utility use to know where pixel 1234x735 is, just >> UV map those distortions and then put a little paint dot at >> 1234x735 and run it through the stmap using that uvmap. >> 1234x735 will be magically whisked away to 1414x644 or >> wherever your transforms take it. >> >> here's an example for you to plug your xforms into, and then >> your paint blob or whatever would go into the stmap: >> >> set cut_paste_input [stack 0] >> version 6.3 v2 >> Constant { >> inputs 0 >> channels rgb >> name Constant2 >> selected true >> xpos 2862 >> ypos 1292 >> } >> set Ncc0e6650 [stack 0] >> Ramp { >> output {rgba.red -rgba.green -rgba.blue -rgba.alpha} >> p0 {{width-width} 100} >> p1 {{width} 100} >> name Ramp3 >> selected true >> xpos 2970 >> ypos 1387 >> } >> push $Ncc0e6650 >> Ramp { >> output {-rgba.red rgba.green -rgba.blue -rgba.alpha} >> p0 {100 {height-height}} >> p1 {100 {height}} >> name Ramp4 >> selected true >> xpos 2862 >> ypos 1384 >> } >> Copy { >> inputs 2 >> from0 rgba.red >> to0 rgba.red >> name Copy3 >> selected true >> xpos 2862 >> ypos 1449 >> } >> NoOp { >> name WARP_GOES_HERE >> tile_color 0xff00ff >> selected true >> xpos 2862 >> ypos 1519 >> } >> Shuffle { >> out motion >> name Shuffle >> label "choose output\nchannel" >> selected true >> xpos 2862 >> ypos 1565 >> } >> push 0 >> STMap { >> inputs 2 >> uv motion >> name STMap1 >> selected true >> xpos 2985 >> ypos 1675 >> } >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Sep 6, 2011 at 3:59 PM, Joshua LaCross >> >> <nuke-users-relay@thefoundry.**co.uk<nuke-users-re...@thefoundry.co.uk> >> >> <mailto:nuke-users-relay@**thefoundry.co.uk<nuke-users-re...@thefoundry.co.uk>>> >> wrote: >> >> __ >> Thanks Anothony. The kites are already in the scene. I'm >> trying get the positional x and y values after going >> through all the additional transforms >> >> ______________________________**_________________ >> Nuke-users mailing list >> >> Nuke-users@support.thefoundry.**co.uk<Nuke-users@support.thefoundry.co.uk> >> >> <mailto:Nuke-users@support.**thefoundry.co.uk<Nuke-users@support.thefoundry.co.uk> >> >, >> >> >> http://forums.thefoundry.co.**uk/<http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.** >> uk/cgi-bin/mailman/listinfo/**nuke-users<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >> >> >> >> ______________________________**_________________ >> Nuke-users mailing list >> >> Nuke-users@support.thefoundry.**co.uk<Nuke-users@support.thefoundry.co.uk> >> >> <mailto:Nuke-users@support.**thefoundry.co.uk<Nuke-users@support.thefoundry.co.uk> >> >, >> >> http://forums.thefoundry.co.**uk/<http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/** >> nuke-users<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >> >> >> >> ______________________________**_________________ >> Nuke-users mailing list >> >> Nuke-users@support.thefoundry.**co.uk<Nuke-users@support.thefoundry.co.uk> >> >> <mailto:Nuke-users@support.**thefoundry.co.uk<Nuke-users@support.thefoundry.co.uk> >> >, >> >> http://forums.thefoundry.co.**uk/<http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/** >> nuke-users<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >> >> >> >> ______________________________**_________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.**co.uk<Nuke-users@support.thefoundry.co.uk> >> >> <mailto:Nuke-users@support.**thefoundry.co.uk<Nuke-users@support.thefoundry.co.uk> >> >, >> >> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/** >> nuke-users<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >> >> >> >> ------------------------------**------------------------------** >> ------------ >> >> ______________________________**_________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.**co.uk<Nuke-users@support.thefoundry.co.uk>, >> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-users<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<Nuke-users@support.thefoundry.co.uk>, > http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> > http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-users<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
