It looks to concrete for my tastes but I guess I will stick with it.
Adding a sun glare quad to the screen tonight. I will simply alter the alpha value of the quad based on the normalized dot product of the camera lookVector and the incoming light vector. When the value is 1, the quad will be rendered at near opaqueness and when it is 0 it will not be rendered at all. If it is <0 it also will not be rendered since the angle would be obtuse and the sun rays would be behind the camera.
This will work for just a camera but when I add in 3D cockpits I will need to cast several rays towards the sun and see if they hit.
I'm looking heavily into stencil buffer shadow volumes for my engine but I'm not sure that it would really add much to a space genre game. Problem is that there really isn't a lot of occluders and shadows in space. You might have a moon shadow onto a planet, but any render of that would look superficial at best. I do want my ships to shadow onto surfaces, however if they shadow onto a planet it is possible that their actual size in comparison to the planet's may stick out like a sore thumb. Also in pictures from the shuttle it appears that the shuttle is so far away from the earth that it does not cast a shadow onto it.
What I might do is create small shadow volumes for self-occluders, that is, elements of a ship that self shadow onto the ship. This would be pretty simply since the shadow volume would not need to extend to infinity. If the ship was very far away from the camera shadowing would not be rendered since you would probably never see it. So the shadow volume should never be clipped by the far clip plane. The near clip plane however would be a problem and I'll probably have to hack it since there is no known good algorithm for perfect near plane shadow volume clipping issues.
Anyways I really need more help on this engine. The whole rendering code needs to be revamped to handle vectors of objects that need to be rendered. The setup code needs to be altered to read the info from a file for the current system and then setup the appropriate variables based on the file contents. Right now a lot of this is hard-coded simpy for testing purposes but the quicker I move away from that mentality and setup, the quicker I can insert new objects into my game to be used by the engine.
Animation classes, timers, and functionality is already in the engine but has not been tested or used yet. I'm not sure how to implement moving parts on ships and objects and I probably need to develop some type of small scripting language for events, ship patrols/movements, AI, etc.
Individual targeting of ships systems will not be implemented since that would require a significant more amount of ray to triangle intersection test code, or at the very least ray to bounding volume or cube tests. If I could get it to run at an acceptable frame rate I might consider it.
If you wish to help in any way please PM me. You can see that this engine is for real and so far has progressed quite nicely. I'm fairly sure my class setup has not coded me into any dark corners and adding classes to the engine is a snap. I'm developing an editor in Visual Basic that will create a type of binary ini file that will describe systems, patrol paths, asteroid/debris fields, suns/stars, rotations, commodities, ambient/specular/diffuse colors, planets (along with their associated colors, materials, shaders, rotational info, etc.), etc., etc.
