🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

3d picking inaccuracy.

Started by
34 comments, last by taby 5 years, 3 months ago
11 minutes ago, Uttam Kushwah said:

ya the window is of the same size and it works in any case whether i go full screen or something else.

i didn't try that much but i guess i have too.And one thing how am i supposed to find these thing exactly twice (because it is impossible to drag same size of box at same position on two different tries unless hardcode them).

You could turn off the dragging for testing, but - in any case - hitting the exact corners of the windows within a pixel or two shouldn't be too hard, and given the margin of error it doesn't need to be exactly precise.

Advertisement

actually i am thinking i will hardcode them for debugging purpose and will post it whats going wrong.

58 minutes ago, Uttam Kushwah said:

actually i am thinking i will hardcode them for debugging purpose and will post it whats going wrong.

The trouble with doing that is that it won't tell you what values glfwGetCursorPos is giving you for the corners, as that comes from where you put your mouse. Hardcoding is a good idea for the rest of the testing though.

3 minutes ago, Irusan, son of Arusan said:

The trouble with doing that is that it won't tell you what values glfwGetCursorPos is giving you for the corners, as that comes from where you put your mouse. Hardcoding is a good idea for the rest of the testing though.

i noticed this thing you told before and didn't do it because the same reason and i have checked for the glfwGetCursorPos it is giving the same values for both the cases at the corners.

let see where it gets.

But thanks for all your replies because i now know that my code isn't wrong(may be the inverse-projection only).????

11 minutes ago, Uttam Kushwah said:

But thanks for all your replies because i now know that my code isn't wrong(may be the inverse-projection only).????

You could try switching to a calculation of the inverse directly from your combined matrix rather than doing inverse(view)*inverse(projection)? It shouldn't be making a difference, but who knows?

i was doing the same thing before , or actually i was using the unproject funtion from glm but after many tries it didn't work at all so i thought of it doing manually and done that thing too what you are suggesting, i don't think it will make a change.

Do you read mesh attributes for normals as unnormalized signed bytes explicitly?

Does it matters? I think it's completely irrelevant! 

 

Check if window size is different than rendering window size, it can be a problem with the window title bar.

Then what are the mouse coords? If you use a standard perspective matrix why wont you use some simple math to involve ray creation. From eye pos to near plane

 

Like in this


inline vec3 GetDirectionFromScreen(mat4 modelview, TSpecCamera * FPP_CAM,  int x, int y, int sw, int sh, float fov, float z_near, float aspect)//, float z_far)
{

mat4 mvm = modelview;
mvm.Transpose();
vec3 dirX, dirY;
	dirX.x = mvm.m[0];
	dirX.y = mvm.m[4];
	dirX.z = mvm.m[8];

	dirY.x =	mvm.m[1];
	dirY.y =	mvm.m[5];
	dirY.z =	mvm.m[9];

//	float aspect = float (SCREEN_WIDTH) / float (SCREEN_HEIGHT);
	float a = fov / 2.0;
float cotangent = 1.0 / tan( a * imopi );

float ax = z_near / cotangent;

float screen_w = 2.0*ax;

float screen_h = screen_w;// * yratio;

screen_w = screen_w * aspect;

float scr_coord_x = float(x) / float(sw);
float scr_coord_y = float(sh - y) / float(sh);

vec3 dir = FPP_CAM->ReturnFrontVector();

//move to lower left corner
vec3 start_pos = (FPP_CAM->pos + dir * z_near) + (-dirX * (screen_w / 2.0)) + (-dirY * (screen_h/2.0));

vec3 start = start_pos + (dirX * (screen_w * scr_coord_x)) + (dirY * (screen_h * scr_coord_y));

return Normalize( vectorAB(FPP_CAM->pos, start) );

}

Anyway its dor openglbased subsystem

Anyway there may be isaues with 1.0- mouse.y and fov is not fovy byt horizontal fov

I am not using perspective matrix So eye pos won't work as point of ray casting. 

 

And yup frame buffer size is same in both cases. 

Q. Are frame buffer size and window size  two different things? 

This topic is closed to new replies.

Advertisement