Dante

Hi this seems like a basic question, but it has me stumped. I am trying to discern the difference between the two methods of getting the mouse coordinates and adjusting for window ratio, both of which i have placed in the attached patch.

one method works in situations such as, Federico's AMS tutorials. For a specific working example see the GL3 image to particles examples. (a non working example is in my attached patch)

the other method, which i got from Micron works in my attached patch.

If this is not just a misunderstanding on my part, I would like to know when to implement one example over the other.

mouseRatioQ.maxpat

Hi this seems like a basic question, but it has me stumped. I am trying to discern the difference between the two methods of getting the mouse coordinates and adjusting for window ratio, both of which i have placed in the attached patch. 

one method works in situations such as, Federico's AMS tutorials. For a specific working example see the GL3 image to particles examples.  (a non working example is in my attached patch)

Hi this seems like a basic question, but it has me stumped. I am trying to discern the difference between the two methods of getting the mou

confused-about-different-methods-of-correcting-window-ratio-for-mouse-coordinates

i don't have a definite answer, but i'm noticing they both start off accurate in the default setup of size "320 x 240" but then both are off when i adjust their window ratios to something like "750 x 300"(?)... micron's starts to get off-center at some point for me too.... 

oh wait! i see now: the "getsize, sendrender screentoworld 0 0" message isn't being retriggered properly when i resize(resizing doesn't send an 'init' message out of jit.world's dumpout), so if that is updated properly upon resize(i just added a 't b' to the output of 'r size' then connected that to bang the "getsize, sendrender screentoworld 0 0" message), then micron's seems to work in every case... so you could probably just go with that?

i think micron's use of 'screentoworld' is key here towards its all-encompassing usability, but i could be wrong.

i don't have a definite answer, but i'm noticing they both start off accurate in the default setup of size "320 x 240" but then both are off when i adjust their window ratios to something like "750 x 300"(?)... micron's starts to get off-center at some point for me too.... 
oh wait! i see now: the "getsize, sendrender screentoworld 0 0" message isn't being retriggered properly when i resize(resizing doesn't send an 'init' message out of jit.world's dumpout), so if that is updated properly upon resize(i just added a 't b' to the output of 'r size' then connected that to bang the "getsize, sendrender screentoworld 0 0" message), then micron's seems to work in every case... so you could probably just go with that?
i think micron's use of 'screentoworld' is key here towards its all-encompassing usability, but i could be wrong.

Sorry, yes i forgot to retrigger the screentoworld message. I believe i understand the concept of screentoworld, but do not understand the '0 0' part. I imagine these are x and y coordinates, but am not sure?

Thanks Raja. 
Sorry, yes i forgot to retrigger the screentoworld message.  I believe i understand the concept of screentoworld, but do not understand the '0 0' part. I imagine these are x and y coordinates, but am not sure? 

ya, that's it!... i remember now: 'sendrender' is the message used to send ensuing messages to the jit.gl.render object internal to jit.world... so we can find the answer in the jit.gl.render reference:

i'm guessing the z-coordinate defaults to 0. and that's why micron didn't need to include that(? ...hmmm... just tried and adding any kind of z-coordinate messes things up, haha, we figure out one answer and many other questions pop-up... ah well, at least it's good to learn this much).

I imagine these are x and y coordinates, but am not sure?

screentoworld
arguments:
x [float]
y [float]
z [float]
Converts screen coordinates to world coordinates, output out the dump outlet. The input x and y input coordinates are in pixels, and the input z coordinate is in normalized distance from camera (0.-1.), where 0. is the near clipping plane and 1. is the far clipping plane.

Thanks I appreciate your help Raja. yea i'm guessing the message is just used to negate the z coord.

I still would like to know why the AMS method becomes inaccurate when I put it in other patches, although now that I understand microns method more clearly I am more inclined to use. I guess you always have to have a backup :)

Thanks I appreciate your help Raja.  yea i'm guessing the message is just used to negate the z coord.
 
I still would like to know why the AMS method  becomes inaccurate when I put it in other patches,  although now that I understand microns method more clearly I am more inclined to use. I guess you always have to have a backup :) 

confused about different methods of correcting window ratio for mouse coordinates