I have recently been "volunteered" for an experimental project at the company I work for. Due to an overly large corporate bureaucracy I'm in a position where I have to do some cross platform 3d work, and I am prevented from using any outside libraries. Normally, I would use something like Ogre or SDL to get a jump start, but that's not an option in this case. I have convinced the powers that be that for best performance a library (i.e. OpenGL) is necessary and have been given permission to use it. Now aside from comments about the politics of the situation (which I really do not want to digress into), I need some advice on 3d. I've been coding in assembler and C++ on multiple platforms for about 20 years now so coding is nothing new to me. Basically here is where I am. I have a basic OpenGL window opening (sans-GLUT), full keyboard interaction working just fine, am able to display a very basic text font on the screen, and can display some basic objects with texturing and very rudimentary lighting. Right now I have no overall object storage mechanism so everything is created in immediate mode, nor do I have any sort of facility for camera rotations and viewing (despite my best efforts to date). The main problem right now is camera movement. I can handle the details of a moving window that maps onto the larger data set (i.e. a window that is swapped from the +/- 2^64 coordinate system of the data to the OpenGL "world" coordinates) but all of my attempts so far to move around in the virtual space have failed in various odd ways (i.e. I tell it to rotate around the y-axis and it rotates around the x-axis). I've read numerous articles debating the merits of moving the camera itself (either gluLookAt or matrix manipulations equivalent of this) or of rotating/translating the objects and keeping the camera and look at position fixed while moving the world around it. Any thoughts on this? The code I've used (and code I've found online at NeHe or other sites) all move the actual camera and run into an interesting problem. If you move the camera too far around the bounding box of OpenGL world coordinates, the camera begins to climb the walls in the shape of the coordinate system. I need to avoid this sort of problem while still paging in new data in the direction of motion. I also need to get some sort of storage system implemented. I've researched a variety of methods (including the Euclid etree system) and others, but again I'm prevented from using outside libraries. I've read more books on OpenGL and game design (under the thought that 3d games deal with this sort of thing), but all make some basic assumptions that don't apply. Most use simple data sets that fit handily within OpenGL world coordinates and the rest make no mention of the overall structure. My apologies for posting this here, but I figured you all might know where I can look (or maybe terms to search for) to learn more about what I'm missing. Cheers!

Rotatating the camera: make sure you are rotating about the camera local axes, not the world axes. Since you're getting wierd results you are probably doing the latter. Just create a camera class that maintains it's own orientation matrix and use that matrix to extract the relevant axes about which you should be rotating.

Something to watch out for: Gimbal Lock (google for more info and many solutions).

By storage system I assume you mean a runtime data structure and not a filesystem/database? If that's the case look into OctTree/Dynamic Octtree/kd tree as some easy methods. You'll have to implement it yourself since you can't use libraries.

As for reaching the ends of the coordinate system:

you're probably using 1 to 1 relationship between OpenGL units and meters/feet/. There's no need for that, it'll work just as well with 0.1f == 1 meter or 0.01f == 1 meter. That'll buy you a little room.

Beyond that, if your world is massive enough that you're still reaching the edge, you can have each of your spatial partitions maintain their own local system and remember offsets with neighbors. When you transition between zones, everything gets rendered relative to "current zone". The player camera can then just snap to the new relative coordinate and you're good to go.

Keep it sans-GLUT. That's some old old code that's pretty outdated.

-me

@Gage64: I'll check that link out and see if it clarifies things for me. Thanks!

@Paladine: I think you lost me here, and I think the problem is in how I'm thinking about the setup of the coordinate system. I am looking at everything in terms of my data sets coordinates. I've taken a small chunk of the data that will fit easily within the OpenGL viewing area (at a 1:1 mapping - I will try the 0.1f:1 and see how it works out) so that I am working strictly in world coordinates. I can see why you would want to keep the camera axes separate so that you can do rotations of the camera relative to it's current axes. If I remember correctly, this relates back to Euler angles in linear algebra, and it has the potential to cause some problems. While I would love to address this, OpenGL provides just enough ways to do things to lose me, which tells me I need to change how I'm looking at it.

So what is a method of handling the coordinates that is workable? I think I have the world coordinate concept down firmly. What I'm unclear on is which of the OpenGL functions to use to be most effective for a large data set (i.e. gluLookAt, rotations on the default camera, etc). Any advice is greatly appreciated.