I think about resolving this counter intuitive problem by using values between 0 and 1 for all computings, and apply the pixels dimensions at the end
Patrice Colet - 06 32 66 03 57
----- "Mathieu Bouchard" matju@artengine.ca a écrit :
On Sun, 6 Jun 2010, patko wrote:
hello, why [pix_crop] y is offsetting from the lower left, when
[gemmouse] (or logic) is starting from the highest left?
For the same reason that GridFlow usually uses (y x) and sometimes (x y) : it's because of conflicting standards.
There's worse : if you've read books involving spherical coordinates,
you'll see that there are perhaps at least five different conventions in concurrent use... varying according to whether latitude is signed or unsigned ("colatitude") and the six possible orderings of three variables. It's crazy.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
----- "Mathieu Bouchard" matju@artengine.ca a écrit :
On Sun, 6 Jun 2010, patko wrote:
hello, why [pix_crop] y is offsetting from the lower left, when
[gemmouse] (or logic) is starting from the highest left?
It's crazy.
yes In the project I'm working on I have to manage three different coordinates systems , the picture size in pixels, the blob from [pix_blob] between 0 and 1, and openGL coordinates, between something like 10.66, and something else like 8, depending on view parameters.
Le 07/06/2010 02:35, patko a écrit :
----- "Mathieu Bouchard"matju@artengine.ca a écrit :
On Sun, 6 Jun 2010, patko wrote:
hello, why [pix_crop] y is offsetting from the lower left, when
[gemmouse] (or logic) is starting from the highest left?
It's crazy.
yes In the project I'm working on I have to manage three different coordinates systems , the picture size in pixels, the blob from [pix_blob] between 0 and 1, and openGL coordinates, between something like 10.66, and something else like 8, depending on view parameters.
openGL coordinate can easily be change using the perspec message to gemwin.
c
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- "cyrille henry" ch@chnry.net a écrit :
openGL coordinate can easily be change using the perspec message to gemwin.
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?
Hi,
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 screen makers!
.b.
On 10-06-07 03:59 AM, patko wrote:
----- "cyrille henry"ch@chnry.net a écrit :
openGL coordinate can easily be change using the perspec message to gemwin.
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Also, keep in mind that you have complete control over the units being used by setting various states in the gemwin. You can have 16x9 'units' for a 16:9 display (or 1920x1080 'units' for that matter).
On Mon, Jun 7, 2010 at 3:13 PM, B. Bogart ben@ekran.org wrote:
Hi,
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 screen makers!
.b.
On 10-06-07 03:59 AM, patko wrote:
----- "cyrille henry"ch@chnry.net a écrit :
openGL coordinate can easily be change using the perspec message to
gemwin.
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 7 Jun 2010, patko wrote:
yes In the project I'm working on I have to manage three different coordinates systems , the picture size in pixels, the blob from [pix_blob] between 0 and 1, and openGL coordinates, between something like 10.66, and something else like 8, depending on view parameters.
well, most likely, that 8 is exactly 8, and the 10.66 is exactly 8*4/3, because of your aspect ratio.
Note that if you normalise your coords to the [0;1] interval, you will get anamorphic pixels, because your scale factor is not the same in both axes. This can be more trouble than keeping the original coords.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Mon, 7 Jun 2010, patko wrote:
I think about resolving this counter intuitive problem by using values between 0 and 1 for all computings, and apply the pixels dimensions at the end
coordinates from 0 to 1 also have the same potential problem... as they can go from 1 to 0.
I mean that you still have multiple possible coordinate systems for a pixel grid even as you normalise to the [0;1] interval.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
B. Bogart -
chris clepper -
cyrille henry -
Mathieu Bouchard -
patko