I've noticed the new Scene().WorldToScreen() function in Poser 7, and I've been thinking about its possibilities.  Could it be used to gain access to the 3D view in Python?  Click in an area and select the nearest vertex, is my thought.

Unfortunately, the only Python functions I can find relating to mouse position or events are in the curses module, which apparently only works on Linux.  There is a Windows curses available, but it only includes some keyboard functions.

Does anyone know of any other way to access mouse location or click data in Python?  Could this be approached using a .dll or something?  Or is it all just impossible?

Mouse events are in the province of whatever GUI toolkit your using e.g. Tkinter, Python itself doesn't have a mechanism for receiving or handling them (being intended for command line use).

So then the question would be whether Tkinter returns mouse positions relative to the Tk GUI elements or relative to the screen.  Hmm.  I'll have to tinker a bit and see what turns up.  Perhaps the 3D view could be re-drawn (or captured as a still) for use in the Tk interface...?

Hmm, hmm.

Thanks, nruddock.  I'll dig a bit more. 

Hi Cage,

Over my head as usual, in this forum; but Ockham's HanselandGretel.PY accepts input from a dragged mouse, to create a walk path.

=  )

Hmm!  I'll take a look at that, then.  Thanks, Angelouscuitry.  :D

Hansel also accepts a background pic so you can trace from
a floor plan or a road map. 

Directly answering the technical question: You can get mouse
positions for the whole screen, if you're using the PIL package
along with TKinter.  You probably have PIL if you've got any of
the more complex scripts like WW.   It's not part of the basic
Poser install, and I suspect that a 'full-screen' position will
be fairly hard to get reliably, because Poser is greedy about
mouse and keyboard events.

Getting the mouse position with respect to a TK canvas is
straightforward, as you'll see by looking at the Hansel code.

I've been wondering about the WorldToScreen function too.  It seems
like it could be powerful, but it also seems to be backwards from what
we'd really want for any interesting script....

Backwards, yes.  My thought was to position the camera, log the world to screen postions of the vertices, click to select a vertex based on screen coords.  Refresh the world to screen list when the camera has moved and stopped moving again.  The clicked mouse coordinates would have to be checked against the logged list values to find the closest match.  Not the way it should be done, but, once again, this is yet another PoserPython function which stops somewhere short of being immediately and fully useful....  Sigh.

I guess I can see why they did it this way: for any 2-dimensional XY on the screen,
there are an infinite number of Z values that would be "behind" that point. 

Still, what would have been truly useful is the frontmost actual vertex that is
behind this XY point. 

They have to be applying some kind of culling of points in their display code or rendering code somewhere, to determine what is in front and what is behind.  I can grasp why they may have left it like this, but it seems, too, like they could have gone just a bit further and developed a new potential for the software, instead of stopping in the easy place.

But, like I've said, I may just be grumbly today from banging my own head up against my own prgramming limitations....

Thanks for the info on PIL.  I'm going to tinker with all of this, once I'm done with the current wave of projects....

Quote - They have to be applying some kind of culling of points in their display code or rendering code somewhere, to determine what is in front and what is behind.

OpenGL has functions for doing picking (see -> http://glprogramming.com/red/chapter13.html), the SreeD code will have something similar, but it boils down to finding all polygons within a given volume, or which intersect with a line.

For the purpose of my hypothetical PPy experiment, I thought I might cull by getting the distances of the points from a plane defined by the camera position, then favor the closest one which fits the proper clicked coordinates in the world to screen list.

So far the only point-within-volume function I've been able to grasp is just checking whether something is within a bounding box, with the bbox having flat sides on x,y,z.  It's a drag being math-dumb....

When the view camera is an orthogonal one (like it is for the top, front, left etc. cameras) then it is relatively straight forward.
When the camera is a perspective one, then it's a bit trickier as the picking volume is really a frustrum (truncated pyramid), but the general idea is the same.
If picking is being done along a line, then the math is simpler (or rather there's just less of it) for determining whether any particular polygon is intersects the pick ray (the need to take into account the camera viewing transform is still present however).

Oh, frustrum culling and all that.  Right.  I think I have some sample code lying around somewhere for that sort of thing, from when I was trying to program a 3D game in Game Maker.

But it wouldn't just be a case of finding the distance to the camera for each vertex?  See, I tend to make rather simplistic assumptions about things like this before I stumble into them....  LOL

I hope to experiment with these ideas soon.  If anyone else wants to jump in ahead of me, feel free.  :D 

Quote - But it wouldn't just be a case of finding the distance to the camera for each vertex?

It's more to do with how efficient the floating point math can be done.
Checking if a point is in a simple bounding box is a few compares, calculating the distance requires a square root calculation (which you wouldn't actually do, you'd keep everything squared).
Even checking against a frustrum (which requires a matrix transform) is comparatively quick.