While I voted for Tesseract, the mantra I and many professional game designers follow is:
It doesn't matter how it looks as long as it plays well.So staying on Cube 2 is ok for me, but why do we have to decide in the first place? Why can't we have both? Let's look a little deeper.
So from what I've heard, Tesseract replaced the static lighting from Cube 2 with dynamic lighting.
Replaced, not
added. Why? Is there
any technical limitation that prevents us from having both approaches in the engine? There is none.
Again, let's observe what we have:
- Static lighting
- Partially dynamic lighting (current Tesseract)
- Fully dynamic (hypothetical)
Static lighting requires baking precomputed lightmaps for all the lights into the map, partially dynamic lighting precomputes only some lights and fully dynamic computes everything in real time. Now, if the client chooses partially or fully dynamic, they don't need to have static lightmaps in the RAM. This can be easily solved by separating different lightmaps into separate chunks and loading only chunks corresponding to the current settings. Source engine does that. It has LDR and HDR lighting, those are computed separately into different chunks of BSP file and only one is loaded at runtime. Very simple.
Again, what is the problem? The problem is that for some reason Eihrul decided to remove static lighting from the engine.
Solution? There are several ones:
- Convince Eihrul to return static lighting to Tesseract.
- Fork Tesseract and add static lighting by ourselves.
None of those solutions are unrealistic. There are no technical problems, the only real problems are laziness and lack of time.