The Industry's Foundation for High Performance Graphics

1. Coding a Game, have hit Giant Roadblock

Ok so on 2 other forums I posted this topic:

"I'm writing a game engine, but I've hit a mjor roadblock. You see I'm using GLtools and this allows you to easily move a camera around the 3D world, it also has a function that I believe returns the XYZ coordinates of the camera.

Only problem is that my character is supposed to have a gun, now in relation to the camera (and the direction the camera is facing) the gun is always in the same place.

The class GLFrame in gltools has some info on which way it's facing, I'm figuring I'll write a function that returns the vector.

So my chosen method of displaying the gun is essentially to convert (somehow) the new position of the camera AND the vector (the way the camera is facing) BACK to the default (namely 0,0,0 and 0,0, -1) and then REVERSE this on the constant position of the gun to receive the NEW gun location.

My question is, how do I this.

In other words how do I find the equation that will convert the coordinates."

"I believe this is the way most FPSs do it:
Image the world as consisting of three parts. The 3D scene, which contains the actual map; the 3D HUD, which contains the character's weapon; and the 2D HUD, which contains health and ammo gauges, etc. The 3D scene is rendered to the framebuffer as one unit based on the camera position, as you're thinking. Once that's done, the camera is set to a fixed point and direction (the 3D scene will be invisible at this point, so it doesn't matter where the point is) such that the weapon is visible, and this view is rendered on top of the previous one. The result is akin to having the character stand in front of a screen that displays the scene, which is why weapons don't clip through walls when you get really close to them. Finally, the 2D HUD is drawn directly onto the framebuffer without using the camera."

So my understanding of what he said is that one must first render the scene. Then set the new XYZ origin at the camera point then render the gun based on this new point and then paste this gun ON TOP of the map scene.

My question is, how would you paste one scene on top of another. Also, is there a way to set the new XYZ origin (with the -Z going in the direction of where the camera is facing) with GLtools or freeglut?

2. Re: Coding a Game, have hit Giant Roadblock

I'm writing a game engine, but I've hit a mjor roadblock. You see I'm using GLtools
Stop. Why are you using gltools to write a game engine? It was never intended to be used for any high-performance applications.

Just because a beginner-level textbook used it doesn't mean that you should too.

The source of your problem is that you're letting gltools do your camera work for you, when you should be taking care of that. If you knew how the camera worked, then what you're talking about would be very easy.

So my understanding of what he said is that one must first render the scene. Then set the new XYZ origin at the camera point then render the gun based on this new point and then paste this gun ON TOP of the map scene.
No. He said to render the scene, change the camera, and then render the gun. Once you render something, it becomes an image. There is no rule that says that you can't render one object, change the camera, and render a new one with the different camera. The camera is nothing more than a transformation matrix; it isn't special, nor does it correspond to an image.

This is one of the problems that comes from using gltools to teach things like transforms. Without actually seeing how it all works, you're just calling a bunch of functions.

3. Re: Coding a Game, have hit Giant Roadblock

YOOOooo.

I'm quite lazy so I think I'll stick with gltools, the game is supposed to be rather primitive.

But if I understand you correctly, what you're saying is use two different cameras?

So in other words, one too render the scene, and then another one (in the position of the player) to render the gun?

I'm sorry I'm a noob. That's what you meant right?

4. Re: Coding a Game, have hit Giant Roadblock

I really wish tutorials and books would stop using the camera analogy. It might seem simpler (you're relating a new concept to something you already know) but it's not how OpenGL actually works at all, and inevitably leads to a tangle of confusion.

5. Re: Coding a Game, have hit Giant Roadblock

Wait I got it, it has something to do with matrices right right?

lawl

Just to clarify, my question is: though the scene may be changing, I would like to draw an object that always stays the same in relation to the camera.

We use matrices to transform stuff right?

So how would we use matrices to accomplish this?

Like say we have the default camera at 0,0,0 and we have a point 0,0,-1.

Let's say we have a new camera position at 2,1,-1 (with X axis being at 3,1,-1 Y axis being at 2,2,-1 and Z axis being at 2,1,-2)

How would we find the equivalent of 0,0,-1 for the new camera position at 2,1,-1?

6. Re: Coding a Game, have hit Giant Roadblock

If you want to draw a gun like they do in FPS games, then you design your gun and export it from Blender or whatever you are using. Center it around the {0, 0, 0}.

To render it, forget about the camera.
You just need to figure out a matrix that would position it. Perhaps a little on the right side and pointing towards the center of the screen.

Then, figure out how many degrees to rotate it.
It is an art. I can't tell you what values you need to use.

7. Re: Coding a Game, have hit Giant Roadblock

Ah nvm I think I got this.

Essentially whenever you move the camera all you do is just move the entire world, correct?

So for example if I wanted to move the camera was 0,0,0 to 5,5,5 it would be really moving the point at 0,0,0 to -5,-5,-5.

And after moving the world other individual coordinates could be moved.

So theoretically I could always draw the gun in the exact same place in terms of eye coordinates/view coordinates/screen coordinates right?

It's just that when I rotate or shift the world I'll have to reverse those effects on the gun so that the gun travels with the camera.

Does that all make sense? Or am I doing it wrong?

8. Re: Coding a Game, have hit Giant Roadblock

It's just that when I rotate or shift the world I'll have to reverse those effects on the gun so that the gun travels with the camera.
No. You simply don't do those things.

You transform your regular objects with one set of matrices. You transform your gun with a different set. A set that doesn't use world space at all.

9. Re: Coding a Game, have hit Giant Roadblock

Waiittttt, I'm pretty sure you use one set of matrices on the coordinates in the world.

But then don't apply any matrices to the gun (which you want to stay with near the camera). This way the world moves and the gun stays still, correct?

10. Re: Coding a Game, have hit Giant Roadblock

It's all perspective. Don't move the camera, move the rest of the "world", then you don't have to worry about the gun. Simply rotate all the parts of the world based on the camera rotation, then translate them away from the camera (so have 6 variables, camX, camY, camZ, camXRot, camYRot, camZRot). When you want to translate the camera forward, add to camZ, when you want to translate up, subtract from camY.

Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•