Hello,

I have been searching around the forum for a bit now and I couldn't really find anything that quite pertained to my question (feel free to correct me if I'm wrong).

I am trying to create a simple 3-D game in OpenGL and I am stuck on how to make walls, boxes, etc solid (meaning the player cannot move through them). The one that seems most convenient and simple, from my searching, is the bounding box (I'm pretty sure that's what it's called). I have two problems with it: I do not know how to get the coordinates of my objects (short of trial and error) and the way I control the camera is by rotating and translating the objects themselves. So, I first don't even know what to put in for the parameters of the bounding box nor do I know how to update said parameters. I was wondering if anyone could shed some light on the situation and perhaps get me over this hump.

If you need any additional information or want to see my code/executable feel free to let me know.

Thank you.

Thanks for your quick reply.

How exactly would I go about iterating through the vertices of, say, a glutSolidCube? Then, how would I reconcile those numbers to reflect glScale, glRotate, and glTranslate calls?

This post brings my nostalgia during my uni days where I have to create a simple demo with similar features as your game for my basic CG course lab project. It was a first-person maze with colliding walls and simple first-person control. I'm no expert/guru in game development or computer graphics but I hope my following tips can help a little.

I do not know how to get the coordinates of my objects.[/quote]

I find that quite hard to believe. Surely you must have created your objects by specifying vertices and perhaps tranformation matrices in the first place, be it loaded from a file or hard-coded in the source. At the point of object creation, you should also calculate the bounding box for each object you want to implement collision detection and store them in an array or other container as you deem fit. In pseudo-code, it would be something like this:


For each object
Create object with input vertex list
Calculate four values: centroid position, length(x), height(y), width(z) that defines a bounding box
Push the bounding box data in an array/map/list etc


Later, in the update loop, you would want to check your current position (same as camera position for First-person view) against all collidable objects to see by taking difference between your current position and each bounding box position, check if it is below a certain threshold (xd,yd,zd) and offset the camera position accordingly if it is. (Note: this is just a brute force all-out collision tests, there are other algorithms to do this more efficiently)

This leads to another point which I observe from your post:

the way I control the camera is by rotating and translating the objects themselves[/quote]

I'm assuming you meant using raw glTranslate and glRotate on all objects while keyboard/mouse input are registered. Please don't do it like this unless you like to mind boggle yourself with coordinate frame reference conversion etc. There is a gluLookAt function in the OpenGL Uitility library which you can use to emulate a 3D camera. I suggest you go goggle "gluLookAt" and use it instead if you haven't already done so.

Even then, gluLookAt is still quite raw. You will need to store camera information somewhere inside an global or app-level object, update them accordingly per user input and then pass the values from this object into gluLookAt once per rendering call.

I hoped I'm being helpful and not putting you down in any way.

Cheers.

Just to reinforce what's already been said:

1. Generally for something like this you'll want to perform the collision detection in world space, rather than in the local space of the player (which I gather is what you're trying to do). Sometimes for narrow-phase tests it can in fact be advantageous to transform geometry into the local space of one object or the other, but for something like what you describe, performing the collision tests in world space would probably make the most sense.

2. Don't get too hung up on the 'transforming the objects rather than the camera' thing, as that's a purely conceptual issue and doesn't (or at least shouldn't) have any bearing on collision detection. Conceptually at least, geometry to be rendered does move through several coordinate spaces as it's processed, including local view space, but other aspects of the simulation, such as collision detection, can (and arguably should) be carried out in world space (or, more generally, whatever space makes the most sense for them).

3. The problem of 'finding out where your objects are' is often (IMX) due to a reliance on (deprecated) fixed-function convenience functions such as glRotate*(), glTranslate*(), etc. For most applications, you'll instead want to use an external math library and build and track the transforms yourself (this applies whether you're using the fixed-function or programmable pipeline). This way, if you do need to transform geometry for some purpose or other, it can be easily done. Note though that even when using the convenience functions, you can still easily track the position (and orientation, if needed) of your player for the purpose of performing collision tests.

My advice is to learn the transformation stuff on the matrix level, because:
1st, it requires you to understand what is happening at all.
2nd, the understanding allows you to solve similar problems for which no predefined routine is available, too.
3rd, you step back from the use of deprecated functions.

Please notice that even the term "bounding box" is not sufficient to describe exactly what you mean, because there are e.g. the "axis aligned bounding-boxes" (AABB) and the "oriented bounding-boxes" (OBB). Besides this spheres, cylinders, capsules, ... and composite / hierarchical volumes are in use. In general a bounding volume is a more or less course approximation of a shape just for the purpose of faster containment or collision detection or similar tests. The exact type of the bounding volume defines how they are effected by transformations. E.g. a sphere cannot be scaled non-uniformly.

If you use predefined routines to generate meshes, then the simple way of getting an initial bounding volume is to compute the volumes parameters directly from the generator parameters and the documentation how the generator uses its parameters. E.g. it can be found for glutSolidSphere:

The cube is centered at the modeling coordinates origin with sides of length size.
[/quote]

fisyher:

Ok, so I did a little more checking and I think I understand how to get the vertices for the objects I have created (I didn't know the parameter for glutSolidCube was actually the width and not the size). I just have one more question about that though: if I call glScale before it, like glScale(10, 1, 1), would the x value be 10 times greater?

As of right now, I'm starting to lean towards creating my own function and simply drawing squares and whatnot to simulate the same action.

Also, I had started using gluLookAt, and that's actually how I view the scene currently, but I either thought this way was easier or I read somewhere that I shouldn't use that function in that way. I will try it again by leaving the scene where it is and updating the parameters in gluLookAt and let you know how that turns out. I think that if I put these two strategies together it will be much simpler to get the coordinates of each object.

jyk:

Thank you for your response as well. I will look into local versus world space and hopefully understand what you're trying to convey.

haegarr:

Thanks for the information concerning what terms I should be using concerning my problem. Also, I will search around for information about matrix transformations instead of using the predefined functions.

For your question, in short, yes. Calling glScale(10,1,1) just before a vertex pt (2,0,0) in world coordinate would cause it to 'scale' to position (20,0,0) in world coordinate. But if you used multiple calls of glScale, glTranslate and glRotate along with glPushMatrix and glPopMatrix, things are going to get real messy when you try to compute the final positions of an object. If you bring in the 'camera' transformation in gluLookAt, which is really just a modelview transformation applied "globally" to all objects in the world, it might be even messier for you.

Also, I would advise against using glutSolidCube if you can help it but rather just draw your own cube using raw glBegin and glEnd calls. Here is one reason why:
http://stackoverflow.com/questions/327043/how-to-apply-texture-to-glutsolidcube

It would help alot if you can understand the concepts of Local-Space, World-Space and Eye-Space and the applied linear algebra behind them for now. Then you will understand what the other posters are saying better:)

So, if both my way and the way the earlier poster suggested are just going to be messy, what would you suggest?

Also, I have a way around your texture problem : )

So, if both my way and the way the earlier poster suggested are just going to be messy, what would you suggest?

I'm not sure which methods you're referring to exactly, but in short (as mentioned previously) you'll want to manage the math side of it yourself, and perform the collision checks (most likely) in world space.

Also, note that for simple shapes like spheres and boxes you don't need the actual transformed vertices in order to perform collision detection; there are other ways to describe these shapes that are more compact and convenient. (For example, a sphere can be represented by a center and a radius, and an axis-aligned box can be represented by a min and max point, or by a center point and extents vector.)