Thanks.

glLoadIdentity(); // reset to world 0,0,0 glTranslatef(-4.0f, 0.0f, 0.0f); // move 4 units to the right glBegin(GL_TRIANGLES); glVertex3f( 0.0f, 1.0f, 0.0f); // 1 unit above current world position glVertex3f(-1.0f, -1.0f, 0.0f); // 1 unit left and 1 unit below world positon glVertex3f( 1.0f, -1.0f, 0.0f); // 1 unit right and 1 unit below world position glEnd();

If you wanted the triangle in a different place, you don't change the coordinates in the glVertex3f calls, you change the coordinates in the glTranslatef call.

------------------
Brian

"OOP programmers have a lot of class"

Check out this webhost! Fantastic prices, features and support!

[Edit]
Beaten to it, and it's a lot more explicit answer, I haven't touched OpenGL in a year and a half I think.
------------------
Check my libraries (C# assemblies):
http://calinnegru.googlepages.com/downloads

[This message has been edited by Calin (edited April 20, 2007).]

OK. Then I guess my real question is, what is a unit? Obviously, 1.0 does not refer to one pixel.

I am currently reading "OpenGL Programming for Windows 95 and Windows NT" by Ron Fosner. It has been a very good book, although the editing was not too good. I am about 7 pages away from reading about Matrix Transformations, so maybe that will help explain things as well.

The "unit" is definitely a little odd for a while. One way to think about it is to start from the default world setting (after a load identity call). Here, the x (also y) coordinate runs from -1 to 1. This gives a sense for the "unit", basically being related to the default screen or viewing window size. As you make manipulations to the viewing matrix, the unit kind of carries along with it as the size of the original screen.

More complicatedly, OpenGL uses that "homogenous coordinates" system, where all the vectors and matrices have a secret fourth component attached to them called w. Usually, the w is 1 for a point; in matrices, they use this component to cause translations (instead of needing to add matrices, it's a fun exercies to verify). Not terribly useful in the beginning, but it will become useful to be aware of it.

[This message has been edited by Nomad (edited April 20, 2007).]

------------------
Brian

"OOP programmers have a lot of class"

Check out this webhost! Fantastic prices, features and support!

The unit is really based on the current screen. The default being the X and Y running from -1.0 to 1.0. So, if I pull back and change 'z' by -5 (moving in the +z direction), then 1.0 will end up being less screen space.

If I want to move an object in x, y, or z, I use glTranslatef, again, using values relative to the current screen.

You have all helped a lot. Thanks. I will put this to use so I can see it all in action. I had family over and a birthday party for my daughter this weekend, so I just haven't had time to write any new code.

I don't understand what Nomad was saying, so your response to him leaves me unsure as well. To set how the "world" is displayed on your screen, you need to first use the glViewport and gluPerspective. Maybe Nomad was meaning using -1.0f and 1.0f in the parameters to gluPerspective or something, to set the screen as those perspective dimensions or something. I use different values, but it doesn't really matter as long as you know what you're doing and how you're thinking about your view into the world space. Hopefully he'll clear up what he meant.

Anyway, you'll probably find lessons 1 & 2 on http://nehe.gamedev.net VERY helpful.

------------------
Brian

"OOP programmers have a lot of class"

Check out this webhost! Fantastic prices, features and support!

I did most of my work based on the book I'm using. I started looking at the NeHe Tutorials and will spend more time with them after I'm done with the book.

Most of my research and understanding is acutally going beyond what we will be using at work. Our product is mostly 2D and mainly required the transparency capability of OpenGL. But I enjoy going beyond and seeing what other potential things we can use.

BrianT is right in that your units really correspond to whatever scale your game world uses. If you want a car to be "12.0" units long, make sure your camera is far enough away (say, "20.0"-"30.0" range) so that you can see it. The units are very natural, based on proportionality rather than anything concrete like the pixel-based lengths of normal 2D programming.

For me, the transition from concrete pixel-based lengths to this more flexible system in OpenGL was a little strange at first. It was just helpful for me to think of basing the units on the screen size for the initial world configuration, so that I would have something more concrete and hardware-based than objects in my game world.