Jump to content
  • Advertisement
Sign in to follow this  
Climax

Gl's inverted Z-axis

This topic is 4523 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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!