Dumb Opengl Question!!

#1

Hello all

Just a quickie question which I’m a bit embarrassed about, but here goes …

My 3d math is a bit rusty and I’m not that cool with Opengl, and I’m in the middle of writing a Maya geometry exporter, but I’m having problems displaying the scene in my app. What I’ve managed to do is export the scene (below) to two raw polygon soup files - one is a ‘Terrain.raw’ file for the plane, and an ‘Actor.raw’ file for the actor’s bounding box (shown in green).

However, when I display the scene the objects stick to Maya’s coordinate system, and I have no idea how to move/position the objects around using my own ‘world’ coordinate system. I’d like to position instances of the box over the plane (as you would do with glRasterPos in 2d), but can only seem to move things using relative coordinates. Any ideas?

Dan

#2

admittedly I don’t know much about that - for one OpenGL and for the other Maya - but why don’t you just use the (same) coordinate system you already get from Maya?

#3

You’ll want to do this by exporting the objects themselves in object space, and then exporting their positions seperately… not sure if the .obj format provides for this… it’s probably easier to write your own exporter…

As for moving things around in opengl, the most general way takes a little more work but will make life a lot easier for you in the long run.

Basically you just want to build a transformation matrix for each object based on your stored transformation information.

So your per-frame drawing routine will look something like (assuming the existence of a suitable object and camera class)


 // Calling glIdentity returns us to "world space"
 glIdentity();
 
 // save the transform stack before transforming to camera space
 glPushMatrix();
 
 // Apply the inverse camera xform to line the camera up along the 
 // -Z axis
 glMultMatrix( camera->getXform() );
 
 for ( all objects in scene )
 {
 		glPushMatrix();
 		glMultMatrix( object->getXform() );
 		object->draw();
 		glPopMatrix();
 }
 
 glPopMatrix();

All the pushing and popping makes sure you transform stack doesn’t go all weird, and allows you to do heirachies easily.

the object->draw() call should literally just pass the vertex and triangle information to opengl.

If this isn’t clear enough, just email me…

#4

Cheers all, esp “playmesumch00ns”, may have to email more about this stuff (or pop over!!), but have somewhat got my head round the idea.

DirectX use the concept of world space and model space (seperatly), but OpenGL doesn’t, unfortunately. Also, I think Criterion use ‘RwFrame’ objects in Renderware for this, so I guess they just store the local and global matrices for each instance? Plus, I must start using the OpenGL FAQ on ‘OpenGl.org’ - v. useful + worth I look!!

Must go, next module to plow thru!!

D

#5

Underneath the hood, there’s only ever three transformations you really need: the xform to position the object correctly in front of the camera, then the perspective xform, then the viewport xform to position the 2d image on the screen.

This of course assumes that you’re lining up all your objects in front of a static camera. You can specify a static world space and abstract the camera by applying the inverse camera transformation before the individual object transforms.

It doens’t make the slightest difference mathematically which way you view it, and can indeed be better either way depending on the application.

Microsoft assumes DirectX users will not be able to grasp this, and so forces seperate world, and viewing xforms on the user.

All you have to do to get this in opengl is to assume your objects are in world space, then make sure to apply the inverse-world-space camera xform before anything else.

RwFrame sounds like a transform class. All you really need store is the local xform relative to the parent. You may want to store other matrices (like the world-space xform, and the inverses of everything to save having to recompute all the time) when they’re needed.

Think I mentioned before that a good way to do this sort of thing is like Maya’s heirachy: shape node under transform node under parent under parent… and so on and so forth until you get back to world space.

#6

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.