Pixels to 3D coordinates

I'm looking for a way to convert pixels (such as the

MouseX()

) to 3D coordinates. Could someone please help?

Create a quad (or plane) that is rotated to face the camera. Make it pickable and position it where you want your Z coord to be. Use CameraPick to find convert from MouseX/Y to 3D x,y[,z]. There really isn't any other way to do it because the z coordinate will always have an effect on the x and y positions (and vice-versa).

awesome

thanks Beaker

Don't forget you probably need to zero the plane/quads alpha.

There really isn't any other way to do it because the z coordinate will always have an effect on the x and y positions (and vice-versa).
There is. The math way. I'm amazed I haven't seen a math solution to this in the archives.

Camera is basically a plane in the shape of the viewport. Camerazoom value is the distance of eye point behind the camera. Vertex positions are drawn on the screen by calculating the point where projection from vertex to eye point crosses the camera plane.

The math way might be faster than using a quad and pick, but if you are doing it only once per tick, it doesn't matter what you use.

Yeah, you can convert the x/y co-ords in 3d space the camera occupies. You still need some sort of depth though, because the camera is just a point in space.

Indeed indeed... (moment of clarity came to me) There still must be a plane or an object you are pointing at. Otherwise you'll just have a vector of infinate length. Now I see why there's no math solution available. There's no need for one. Only if you are using a 3rd party graphics engine that doesn't have picking, then the math solution is needed.

I was always afraid of making objects pickable, like they had an effect on performance like mesh intersects do. Mesh picking is just something that comes for free when calculating z-buffer, isn't it?

If you make the quad/plane very close to the camera it's fine. Hell, you can generate a maths equation if you choose a distance, without using a quad or plane, and there is no picking involved.

Any "3rd party graphics engine that doesn't have picking" is possibly not worth using.

Probably because a math-based routine uses nothing but the CPU, while an entity-based routine probably uses graphics hardware accelleration.

Effectively, yeah.. the erndering needs to know what's where in relation to the camera and what's in between will get filled in with the z-buffer, so the result is that picking can identify the drawn object in the screen representation of 3-D space, and therefore, the coords of that 3-D object.


Precisely :D If there's nothing in the way, this is exactly what you would get anyway :D - Chances are, though, you'd hit the skybox or something.

I'm pretty sure it's all done on the CPU either way.

Yeah. In blitz3D, the CPU does nearly everything except draw the graphics.

How about this?
2D-to-3D entity positioning (or something)

wow
thanks BlitzSupport,
but i think i'll just use

CameraPick(Mousex(),MouseY())

thanks everyone else too