[PD] [pix_crop] offY incoherence
ben at ekran.org
Mon Jun 7 21:13:51 CEST 2010
This is normal media-art practise, mapping one range of values to
another. Having one normalized system of coords does not solve all
problems, sometimes you want to know the position in actual pixels,
sometimes you don't. Not to mention the beauty of non-linear mappings.
Getting a handle on mapping from one set of numbers to another is the
very centre of interactive media, and what one should get used to once
they figure out what functions/object boxes/operations do.
I've always covered gemunits in my gem classes. Knowledge of things like
the [rectangle 5.333 4] that fills the 4:3 gemwin, and the [rectangle
7.111 4] rect that fills the 16:9 gemwin have become normal...
I prefer rounder aspect ratios myself (1:1, 2:1, 3:1,...), blame the
On 10-06-07 03:59 AM, patko wrote:
> ----- "cyrille henry"<ch at chnry.net> a écrit :
>> openGL coordinate can easily be change using the perspec message to
> Allright, then if I want to have gemwin coordinates system adapted to the blob,
> I'd need to find out how to multiply perspect values to have my zeros at the lower corner left
> and my ones to higher corner right.
> By fiddling with numberboxes I've figured out that any windows with a 4:3 ratio has one horizontal
> unity that is about 5.33 and vertical unity about 4.
> So it's really tricky to get values that are only between 0 and 1
> inside the edges of the rendering window.
> In fact , at the end it's far easier to multiply the values outputed by [pix_blob] on x by 10.66 and remove 5.33,
> and on y by 8 and remove 4, or divide gemmouse values by gemwin dimen and then multiplying by the same values.
> Is there a way to not-have-to fiddle values for getting an accurate positioning of objects in gemwin?
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list