What I'm trying to do is draw a gun for a fps game I am making but it always seems to be off. I know I am supposed to draw it last with depth test disabled. But i just can't seem to get it to follow along with the view of the camera. Assume we are just drawing a triangle to represent the gun right now, with the base being at the players end. I have access to player position and the point where he is looking (used for gluLookAt) and I also have access pitch and yaw. And ideas on what to do?
I'm not an expert but I would try something akin to the following for drawing the gun:
#If not already in modelview mode
glMatrixMode(GL_MODELVIEW)
#Push the current modelview matrix onto the stack, leaving us working with a copy
glPushMatrix()
#Translate forward to where we want to draw the gun
glTranslatef(0,0,dist)
#Draw the gun starting from this position, translation may need to account for offset so that it is centered correctly
gun.draw()
#Get rid of our modified modelview matrix and return to the original so that the camera is in the correct positon
glPopMatrix()
The best guide I have found for understanding OpenGL geometry is http://www.songho.ca/opengl/gl_transform.html
Good luck! :)
Related
I'm trying to add a skybox to the world/camera/game and I don't know how to go about it. If someone could give me some guidance on how to apply it, it would be much appreciated.
I have already loaded the skybox, I just don't know how to draw it properly so it will fit around the camera as it moves.
I have managed to texture a sort of cube, which might be close to a skybox but then it's only visible from the outside. Once you enter the cube, you can't see it from the inside. Perhaps if I could invert the cube's faces, it will show when I'm inside the cube and I can make it larger?
From outside the cube looking at it
From inside looking out
I had a similar problem a few weeks back, if you are looking for some pseudo code I think I may be able to help. First of all using a cube isn't the best idea when rendering as your box won't look natural, map it to a sphere for a smooth effect.
Create a bounding sphere around your viewer that moves relative to your camera
Apply the texture on that sphere, this will give the impression that the sky is moving relative to you
When you are drawing, disable your z-buffer and frustum (assuming you're using any culling algorithm) this will allow the sky box to be drawn but will ensure terrain is drawn over the top of the sky box when depth sort algorithms are performed by OpenGL.
Note: Don't forget to re-enable the z-buffer after the sky box has been drawn, otherwise your terrain elements will appear outside of the sphere, meaning you will only see the Sky box.
I recently wrote a basic terrain engine in DirectX but the principals are fairly similar, if you'd like to view the repo you can find it here
Check out line 286 in this file to see how the Skybox is rendered, then also visit the SkyBox implementation file to see how it is constructed, and the SkyShader implementation file to see how the texture is mapped to the sphere, the main method to be concerned with in the shader file is SetShaderParameters()
In terms of moving the skybox relative to your camera, simply set the WVP matrix of your skybox to that of your camera, and then tweak the x, y, z planes of the skybox to your liking.
Extra If you are going to implement multi-player aspects, just disable back-face rendering for the sphere, then each player can see their SkyBox but opponents cannot. Alternatively you create one large sphere around the world
Hope that helps - if you need anymore help just ask, I know this stuff can be fairly dense at first:)
I have trouble in opengl. I want to rotate my vehicle while moving forward/backward. Here's a picture which shows exactly my problem. Effects of current code are in blue - after moving the car rotates over the starting location and not the current one. I want to have situation in red - in which my vehicle will rotate over current position and later move forward/backward correctly.
My current code:
lxr=sin(angle);
lzr=cos(angle);
xr+=speed*lxr;
zr+=speed*lzr;
totalangle+=angle
glRotatef(totalangle,0.0,1.0,0.0);
glTranslatef(0.0,0.0,xr);
drawVehicle();
You can try to call translate before rotate. glRotatef rotate view matrix and it affects on current view and also matrix glTranslatef.
From the image, I thought you are translating and then rotating, but looking at the code, I see it is not true.
So, it is obvious that you are in the drawVehicle(); function not rendering your object in the center (0,0). You need to render it in the center, rotate and then translate.
Also, your translation is bogus. You are just translating in z direction, not in y :
glTranslatef(0.0,0.0,xr);
You need to do something like this :
glRotatef(totalangle,0.0,1.0,0.0);
glTranslatef(0.0,yOffset,0.0);
drawVehicle(); // render around [0,0]
you have to move the origin of the coordinate system too, in order to rotate your car as you wish.
I've read through several over-complicated articles on rendering a 3D scene with OpenGL, and haven't really found something that helps me to visualize the basic concepts of scene navigation with respect to glRotate and glTranslate calls.
From experimenting with the examples provided by LWJGL (my particular OpenGL library), I understand very basically what effect comes of their use. I can use glTranslate to move to a point, glRotate to rotate about that point, and glLoadIdentity to snap back to the origin or glPopMatrix to go back to the last glPushMatrix, which are essentially snapshots of a location and rotation. Finally, the scene will render to screen with respect to the origin.
So basically, to put a cube at point A with rotation B:
glTranslate(A.x,A.y,A.z) [now focused on point A]
glRotate(B.,,*,*) for pitch, yaw, and roll; [now rotated to rotation B]
glBegin(GL_QUADS) and glVertex3f()x4 for each 'side'(quad) relative to object's origin
glEnd()
glLoadIdentity() [reset to origin for other objects, not needed if only drawing the cube]
As for the "camera", since openGL's "eye" is fixed, the scene has to move inversely from the camera in order to simulate moving the eye with the camera. This is my understanding so far, and if this is wrong, please put me on the right path.
Now for my specific situation and question:
My 'scene' consists of terrain and a player (some arbitrary shape, located at a terrain-relevant location and a 'camera' head). The view should rotate with respect to the player, and the player move with respect to the terrain. I want the final rendering to essentially "look through" the player's head, or camera. My confusion is with the order of translate/rotate calls for rendering each part, and the direction of translation. Is the following the proper way to render the terrain and player with respect to the player's "camera"?
translate away from the player by the player's distance from origin (move the scene)
rotate away from the player's rotation (player looks 40 degrees right, so rotate scene 40 left)
render terrain
reset via glLoadIdentity
render player's head (if needed)
translate to body/hands/whatever position
rotate away from the player's rotation (step 2 again)
render body/hands/whatever
Also, does rotating have an effect on translation? Aka, does OpenGL translate with respect to the rotation, or does rotation have no bearing on translation?
I can use glTranslate to move to a point, glRotate to rotate about that point, and glLoadIdentity to snap back to the origin or glPopMatrix to go back to the last glPushMatrix, which are essentially snapshots of a location and rotation.
No not quite. Those functions have now idea of what a scene is. All they do is manipulating matrices. Here's an excellent article about it:
http://www.opengl.org/wiki/Viewing_and_Transformations
One important thing to keep in mind when working with OpenGL is, that it is not a scene graph. All it does is rendering flat points, lines and triangles to the framebuffer. There's no such thing like a scene you navigate.
So basically, to put a cube at point A with rotation B:
(...)
Yes, you got that one right.
As for the "camera", since openGL's "eye" is fixed
Well, OpenGL got no camera. It's only pushing vertices through the modelview matrix, does lighting calculations on them, then passes them through the projection and maps them to the viewport.
I'm making a 3D FPS with OpenGL and here is the basics of how it works. The game is a 3D array of cubes. I know the location of the player's current cube, aswell as the camera x,y,z and I know the x, y, z rotation of the camera too. Right now I just make a square around the player and render this and then add distant fog. The problem though, is that I'm still rendering everything that the player is in back of. How could I selectively only render what the player sees, not render everything within an X radius as Iam doing now.
Thanks
You are talking about frustum culling, if i get you right. I suggest that you take a look at this tutorial. They provide nice demos and explain everything in detail.
This sounds like you need to look into culling concepts.
Are the cubes rooms of a maze through which the player navigates? If so, and assuming the rooms are static over the course of the game, you could use a BSP tree to traverse the scene in order of depth, stopping when you pass the player.
I am currently working on designing my first FPS game using JOGL. (Java bindings for OpenGL).
So far I have been able to generate the 'world' (a series of cubes), and a player model. I have the collision detection between the player and the cubes working great.
Now I am trying to add in the guns. I have the gun models drawn correctly and loading onto player model. The first gun I'm trying to implement is a laser gun, which shoots and instantaneous line-of-sight laser at whatever you're aiming at. Before I work on implementing the enemy models, I would like to get the collision detection between the laser and the walls working.
My laser, currently, is drawn by a series of small cubes, one after the other. The first cube is drawn at the end of the players gun, then it draws continuously from there. The idea was to continue drawing the cubes of the laser until a collision was detected with something, namely the cubes in the world.
I know the locations of the cubes in the world. The problem is that I have to call glMatrixPush to draw my character model. The laser is then drawn within this modelview. Meaning that I have lost my old coordinate system - so I'm drawing the world in one system, then the lazer in another. Within this player matrix, I have go call glRotate and glTranslate several times, in order to sync everything up with the way the camera is rotating. The lazer is then built by translating along the z-axis of this new system.
My problem is that through all of these transformations, I no longer have any idea where my laser exists in the map coordinate system, primarily due to the rotations involving the camera.
Does anyone know of a method - or have any ideas, for how to solve this problem? I believe I need a way to convert the new coordinates of the laser into the old coordinates of the map, but I'm not sure how to go about undoing all of the transformations that have been done to it. There may also be some functionality provided by OpenGL to handle this sort of problem that I'm just unaware of.
You shouldn't be considering the laser as a spacial child of the character that fires it. Once its been fired, the laser is an entity of its own, so you should render as follows:
glPushMatrix(viewMatrix);
glPushMatrix(playerMatrix);
DrawPlayer();
glPopMatrix();
glPushMatrix(laserMatrix);
DrawLaser();
glPopMatrix();
glPopMatrix();
Also, be sure that you don't mix your rendering transformation logic with the game logic. You should always store the world-space position of your objects to be able to test for intersections regardless of your current OpenGL matrix stack.
Remember to be careful with spacial parent/child relationships. In practice, they aren't that frequent. For more information, google about the problems of scene graphs.
The point that was being made in the first answer is that you should never depend on the matrix to position the object in the first place. You should be keeping track of the position and rotation of the laser before you even think about drawing it. Then you use the translate and rotate commands to put it where you know it should be.
You're trying to do things backwards, and yes, that does mean you'll have to do the matrix math, and OpenGL doesn't keep track of that because the ModelView matrix is the ONLY thing that OpenGL does keep track of in regards to object positions. OpenGL has no concept of "world space" or "camera space". There is only the matrix that all input is multiplied by. It's elegantly simple... but in some cases I do prefer the way DirectX has a a separate view matrix and model matrix.
So, if you don't know where an object is located without matrix math, then I would consider that a fundamental design problem. If you don't need to know the object position, then matrix-transform to your hearts content, but if you do need it's position, start with the position.
(pretty much what the first answer says, just in a different way...)