>
> 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> 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>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> 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-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, 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
>>>
>>
>>
>> _______________________________________________
>> 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
>
_______________________________________________
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
