To be a good OpenGL programmer, you have to first be a good graphics programmer, and then learn about the specifics of the OpenGL API.

To be a good graphics programmer, you have to be a good programmer, and be good in graphics.

To be a good programmer, you have to read books and code about random things like physical dependency management, data structures, cache coherency, unit testing, etc.

To be good in graphics, you have to have an artistic sense (how does light and color interact to create a visual) and solid 3D math skills.

To develop the artistic sense, you need an understanding of art, as well as an understanding of the math/physics of color.

To get an understanding of art, read books and go to museums to study artist uses of light, composition, etc. Maybe also take up painting in the real world :-)

To an understanding of the math and physics of color, pay attention in high-school physics class, and play around a lot with the different layer blending properties in Photoshop on different images you create.

To develop solid 3D math skills, you could read up on linear algebra as well as modeling, and also play around with 3D modeling tools and languages, such as POV-Ray, Renderman, Blender, 3dsmax, etc.


You will note that the process of becoming a good Direct3D programmer is exactly the same, except for the very first paragraph :-)


On the subject of factoring into different scenes: I would define as much as I can of my scenes in a modeling tool (for graphics), and a scripting language (for behavior). Then I would have a "Scene" class which knows how to read a scene description from disk (say, in XML), and instantiate the right meshes, textures, and scripts. Then the scripting engine would take care of the high-level behavior of the scene. When switching to another scene, release the current Scene object and create a new.

Actors (like the player and NPCs) and other Entities (like doors, menus, or whatever) will, in this view of the world, be primitives that can be addressed in the scripting language. Behaviors, like "duck for cover" or "plan a path to point X" or "pan camera along this tunnel" or whatever, would be other primitives available to the scripting language, probably implemented in your core languages.

If you're not ready to integrate Python, Lua or something like that yet, then you could still think about it like this (define a Scene object interface, a way of dealing with meshes and materials, etc), and implement multiple versions of Scene with different core language behavior. Each of these implementations would probably go in its own file. However, I wouldn't wrap each file in "if( In_My_State )". Instead, only one would be instantiated at a time, and be the "current scene," and the application code would pass events like "key down" or "time elapsed" or "render new image" into the Scene.

Quote:
Then the scripting engine would take care of the high-level behavior of the scene.

lol; thats an acceptable way to say that you're going to hard code it...but that is exactly why you use a scripting language (ie it doesnt get compiled, just translated) ;)