Pixels to 3D coordinates

Blitz3D Forums/Blitz3D Programming/Pixels to 3D coordinates

fireshadow4126(Posted 2009) [#1]
I'm looking for a way to convert pixels (such as the
MouseX()
) to 3D coordinates. Could someone please help?


Beaker(Posted 2009) [#2]
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).


fireshadow4126(Posted 2009) [#3]
awesome

thanks Beaker


Beaker(Posted 2009) [#4]
Don't forget you probably need to zero the plane/quads alpha.


Jasu(Posted 2009) [#5]

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.


Ross C(Posted 2009) [#6]
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.


Jasu(Posted 2009) [#7]
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?


Ross C(Posted 2009) [#8]
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.


Beaker(Posted 2009) [#9]
Any "3rd party graphics engine that doesn't have picking" is possibly not worth using.


Adam Novagen(Posted 2009) [#10]
I'm amazed I haven't seen a math solution to this in the archives.


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


_PJ_(Posted 2009) [#11]
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?



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.

Otherwise you'll just have a vector of infinate length.

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.


Gabriel(Posted 2009) [#12]
Probably because a math-based routine uses nothing but the CPU, while an entity-based routine probably uses graphics hardware accelleration.

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


Ross C(Posted 2009) [#13]
Yeah. In blitz3D, the CPU does nearly everything except draw the graphics.


BlitzSupport(Posted 2009) [#14]
How about this?
2D-to-3D entity positioning (or something)


fireshadow4126(Posted 2009) [#15]
wow
thanks BlitzSupport,
but i think i'll just use
CameraPick(Mousex(),MouseY())

thanks everyone else too