Hi. The shorter way to making a first person shooter which looks as realistic as possible is to use an existing engine (UDK/CryEngine/Unity). Of course, there are a few legitimate reasons for one to want to write his own engine. So the first advice is: use an existing engine unless you really have a good reason not to.

Using the fixed function pipeline is not advisable for what you are aiming for. Use shaders. Shaders are text files which are written using any text editor, like notepad. Of course, knowing what to write in those files is a different story. There is no way to "easily" implement the graphic techniques you've mentioned if you don't have prior experience with writing shaders and applications that use those shaders. If you're getting started with graphics programming, I suggest finding a good book or a good article/tutorial series until you get comfortable with how it all works together. Good luck!

In my project I have a class that can automatically generate vertex and pixel shaders based on the renderable that needs to be drawn. There is a manager class that ensures this process only happens once for each unique vs/ps. Once you start varying your renderable materials too much, the number of possible vs/ps will explode, so be warned.

If your renderables do not have certain properties it might be possible to create an "uber-shader". A single giant shader that can render all possible objects, but has a very fat list of inputs and outputs.

So to explain a bit more, the project I'm working on is what I'm calling a "reverse" mod, where I rewrite the engine to use the original art assets, but a requirement is that the original art assets remain untouched in the same format as the original game.

Anyway, those art assets come from the Gamebryo engine circa d3d9 era. They allow a model to describe up to eight textures per sub-mesh and the eight textures have special semantics for pixel shader creation. For instance one texture could be a diffuse map, another a dark map, another a light map, another a detail texture, etc.

The engine allows the sub-mesh to declare a non-uniform number of (u,v) sets. So a sub-mesh could declare that it will be shaded with 4 textures, diffuse map, dark map, light map and detail texture, but only declare two (u,v) sets and use the first one for the diffuse map and the second one for the dark map, light map and detail texture. Another sub-mesh in a different model might also use 4 textures for the same purpose, but have four (u,v) sets one for each. This creates a possibility for a large number of shader permutations, which increases milliseconds per frame and generally slows down the application.

The uber-shader approach for these types of resources is at least as (if not more) unattractive. It would require every sub-mesh to set eight textures, and for every vertex to describe eight (u,v) sets, many of which will either be duplicated or no-ops. Then the pixel shader would need a way to no-op dark maps, light maps, bump maps, detail textures, etc for sub-meshes that don't have those elements.