• Advertisement
Sign in to follow this  

Gl's inverted Z-axis

This topic is 4252 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi I'm struggling with collision detection. i've managed to perfect it in D3D, but now I've ported the code to GL, and have problems with Gl's inverted Z-axis. How can I convert my vectors to D3D style vectors ( Z is positive into screen )? I get my View Position like follows:
    	float MoveToX = ViewXPos;
	float MoveToY = ViewYPos; 
	float MoveToZ = ViewZPos;
    	float SS = 0;
    	if(Keyboard.isKeyDown(Keyboard.KEY_W)) 
	{
		MoveToY -= (float)Math.sin(Math.toRadians(ViewPitch)) * MovementSpeed;
		SS =  (float)Math.cos(Math.toRadians(ViewPitch)) * MovementSpeed;
	      MoveToX += (float)Math.sin(Math.toRadians(ViewYaw)) * SS;
		MoveToZ -= (float)Math.cos(Math.toRadians(ViewYaw)) * SS; 
	}
		
	if(Keyboard.isKeyDown(Keyboard.KEY_S)) 
	{
		MoveToY += (float)Math.sin(Math.toRadians(ViewPitch)) * MovementSpeed;
		SS =  (float)Math.cos(Math.toRadians(ViewPitch)) * MovementSpeed;
		MoveToX -= (float)Math.sin(Math.toRadians(ViewYaw)) * SS;
		MoveToZ += (float)Math.cos(Math.toRadians(ViewYaw)) * SS; 
	}
		
	if(Keyboard.isKeyDown(Keyboard.KEY_A))
	{
		MoveToX -= (float)Math.sin(Math.toRadians(ViewYaw + 90)) * MovementSpeed;
		MoveToZ += (float)Math.cos(Math.toRadians(ViewYaw + 90)) * MovementSpeed; 	
	}
		
	if(Keyboard.isKeyDown(Keyboard.KEY_D))
	{
		MoveToX += (float)Math.sin(Math.toRadians(ViewYaw + 90)) * MovementSpeed;
		MoveToZ -= (float)Math.cos(Math.toRadians(ViewYaw + 90)) * MovementSpeed; 
	}
		
	if(Keyboard.isKeyDown(Keyboard.KEY_SPACE)) 
	{
		MoveToY += MovementSpeed;
	}
		
	if(Keyboard.isKeyDown(Keyboard.KEY_LCONTROL)) 
	{
		MoveToY -= MovementSpeed;
	}
then I calculate the vectors as follows:
	Vector3f vEyePt = new Vector3f(ViewXPos,ViewYPos,ViewZPos);
	Vector3f vVelocity = new Vector3f((MoveToX - ViewXPos),(MoveToY - ViewYPos),                                            (MoveToZ - ViewZPos));

So any idea how? It's probably a math thing. The problem is also that the face normals are calculated according to a correct LH-structure meaning -1 is out of screen. So everything's a bit messed up. Thanx for your help!

Share this post


Link to post
Share on other sites
Advertisement
I prefer to change it to D3D vectors to keep the collision code the same, then just reconvert it back to GL-vectors. If I remember correctly GL is a right-handed system and D3D a left-handed system, right?

I neet to convert my velocity vector to a LH-system then? Then the result of the Collision and Response function should be converted back to a RH-system.

Then my question is: How do I convert a vector from RH to LH and back again?

Thanx, sorry for this long post... :$

Share this post


Link to post
Share on other sites
If you do that (stick an inversion on the MV), do you not hit issues with the backface culling needing changing and so on?

Surely it'll invert all your CW/CCW tests?

Share this post


Link to post
Share on other sites
Hi,

Yep it will certainly cause issues - the OP would be better handling the problem at a higher level in my opinion.

E.g. rather than getting OpenGL to convert his vectors using the ModelView matrix mentioned in the FAQ do the conversion when required by the collision system if thats the handed-system that the collision sub-system requires.

Cheers,
dhm

Share this post


Link to post
Share on other sites
I won't have a prob with culling. I still draw my faces correctly, I use a different list of faces, I know it's a waste of memory, but I then create them Clockwise and calculate a LH-facenormal. I use that only for collision detection.

So I need to convert my RH-movingvector to a LH-movingvector only for collision and then the result back to RH-system. Any ideas? I can easily get my moving vector in a LH-vector, but to convert that afterwards to RH-system I donno how...

Oh for the record my collision detection system works only with a LH-system...

See my prob?

Thnx

Share this post


Link to post
Share on other sites
So you're saying that instead of simply "switching" OpenGL to the same handedness you rather go and do a ..load of extra work by essentially changing everything else?

Share this post


Link to post
Share on other sites
Yeah I know it's a lot of extra unneccesary work :( any other ideas? I really don't wanna go through changing the collision code, cause i want it to be multiplatform (D3D and GL) thats why I actully wnt to change to LH-system all-through...

That will help me immensely...

Do I only invert a vector's Z-axis to switch between LH and RH? And scale a matrix by (1,1,-1)(x,y,z) to switch between LH and RH?

Cause that didn't work... This calls for serious debugging...

I can collide but my slide vector is really wasted! Donno how to fix it. Perhaps I could email it to someone to helpwith debugging? I know it's quite a lot to ask...

Thanx for the OpenGL.org link, really helpful ;)

Thanx

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Just for interest:

Many commercial games use different sets of polys for collision and rendering. Reasons:

1) It's then possible to optimise both sets of data for their specific requirements
2) You can use different representations (normally you use much lower poly collision models)
3) etc.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Just for interest:

Many commercial games use different sets of polys for collision and rendering. Reasons:

1) It's then possible to optimise both sets of data for their specific requirements
2) You can use different representations (normally you use much lower poly collision models)
3) etc.


Yeah I agree, it can be optimal, but if one doesn't implement it optimally it can be a waste of memory!

Share this post


Link to post
Share on other sites
Quote:
Original post by Climax
Do I only invert a vector's Z-axis to switch between LH and RH? And scale a matrix by (1,1,-1)(x,y,z) to switch between LH and RH?


Nooooo... don't even touch any vectors. Flip a few signs in the projection and viewmatrix and you're done. Worst case you have to add glFrontFace(GL_CW) during initialization. Everything else can be neatly hidden away in some camera class or whatever you might be using to set up the view/projection.

z-axis of the view matrix is inverted and this is working fine for me as projection.


float PMtr[16]={
1/xFac, 0, 0, 0,
0, 1/yFac, 0, 0,
0, 0, (farp+nearp)/(farp-nearp), 1,
0, 0, (2*farp*nearp)/(nearp-farp), 0
};


xFac and yFac are either half the width/height of the frustum at z=1 or
yFac = tanf(FoV);
xFac = yFac*aspectRatio;

Share this post


Link to post
Share on other sites
Quote:
Original post by Trienco
Quote:
Original post by Climax
Do I only invert a vector's Z-axis to switch between LH and RH? And scale a matrix by (1,1,-1)(x,y,z) to switch between LH and RH?


Nooooo... don't even touch any vectors. Flip a few signs in the projection and viewmatrix and you're done. Worst case you have to add glFrontFace(GL_CW) during initialization. Everything else can be neatly hidden away in some camera class or whatever you might be using to set up the view/projection.

z-axis of the view matrix is inverted and this is working fine for me as projection.


float PMtr[16]={
1/xFac, 0, 0, 0,
0, 1/yFac, 0, 0,
0, 0, (farp+nearp)/(farp-nearp), 1,
0, 0, (2*farp*nearp)/(nearp-farp), 0
};


xFac and yFac are either half the width/height of the frustum at z=1 or
yFac = tanf(FoV);
xFac = yFac*aspectRatio;


Do I need to flip the projection amtrix as well? I though only the view, according to the FAQ of Opengl.org...

Share this post


Link to post
Share on other sites
Quote:
Original post by Climax
Do I need to flip the projection amtrix as well? I though only the view, according to the FAQ of Opengl.org...


I'd try it step by step. A quick search turns up a couple pages about left and right handed projection matrices, so I guess you can either tell OpenGL that your front faces are clockwise or change the projection (I would prefer the latter, because hidden in a camera class it doesn't secretly make or rely on arbitrary changes nobody knows about).

Note however, that the above matrix is for a symmetric frustum and takes a few shortcuts.

Share this post


Link to post
Share on other sites
Cool

Thanx Trienco, I changed the viewmatrix now to a LH-system. The only thing now is that eventhough I create my faces CW I have to cull CW... Weird? does changing the projectionmatrix solve this?

Anyways my collision still doesn't work, I can't understand it... Everything is the same as my D3D sample. Maby changing the projection matrix will help, though I doubt it.

I'll have to do serious debugging. Oh btw. my D3D sample was in C++, but I'm now writing a school project which must be in Java. I'm using the LWJGL appi, maby their vector class' math functions work differently?

Anyways thax for the help guys!
PS. anyone interested in seeing my code? :P

Share this post


Link to post
Share on other sites
Quote:
Original post by ClimaxThe only thing now is that eventhough I create my faces CW I have to cull CW...Weird?


Only if you also created them CW in D3D.

Quote:
Anyways my collision still doesn't work, I can't understand it... Everything is the same as my D3D sample. Maby changing the projection matrix will help, though I doubt it.


Your physics and collisions should have absolutely nothing to do with your graphics. If you find ANY graphic API calls in your physics code, you screwed up the design.

Share this post


Link to post
Share on other sites
No there aren't any graphics api calls. I just hoped that it might be a vector inversed because of LH and RH problems. Guess it wasn't that then.

Like I said it's ported from C++ to java, but I think some maths stuff might not be the same, especially with vectors. I think the only prob comes in where I calculate the slide vector, cause that sometimes works right other times not, so donno why, but thanx hey ;)

Cheers

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement