Lightmaps in Doom 3 Engine:
A Hybrid Approach To
Real-Time Lighting Click Image for Full View FAQ Kind of weird to put the FAQ up front, but a lot of people have questions regarding specific limitations in the technique I've developed. I realize the technique is far from optimal. It *could* be implemented in more effective ways. Unfortunately, the alternatives require significant modification to the Doom 3 engine. My goal was to create a solution that would be useable without modification. I did this because we don't even know yet what the boys over at CPMA and OSP will be doing with Quake 4. However, in the FAQ, I discuss some of the alternatives that might be implemented if anyone wants to carry it out in a mod. I'd, of course, be more than happy to lend a hand to any competition modders or mappers with shader programming, tech advice, or anything else that might further the competitive community. So maybe you read the tutorial and then come back here to read the FAQ. :) Alright, now lets get on with the show! Background Since the inception of Doom 3, many artists have been disappointed with the engine's limited lighting ability. Utilizing a small number of point lights to illuminate levels results in stark scenery with excessive contrast and absence of subtlety. Environments remain dark due to lack of bounced light. And the lack of area lighting creates rigid shadows and hard surface shading. From an artistic standpoint, Doom3's native solution is undesirable at best. From the perspective of a deathmatch gamer looking for pleasant environments with minimal distractions, it is a beast to reckon with. Seeing Quake 4 soon to release on Doom 3 engine, I decided to get a jumpstart on development by providing a new technique that will help deathmatch mappers create the beautiful environments they truly desire in Q4. With great pleasure I provide this solution: the introduction of lightmaps into a real-time lighted environment -- an extension to Doom3 lighting. Some Theory -- How do lightmaps work? Lightmaps are a type of "precomputed lighting". This means they are calculated -- through a process called "baking" -- before being used at runtime (the time when you actually play the game). Because they are not calculated during runtime, any changes to the environment will not require recalculation of the lighting. While the performance benefits are great, there exist potential problems. The clearest example is to imagine a dark room with an open door and light pouring in through the opening. If you computed the lighting with a single lightmap while the door were open, you would be stuck with this open-door lighting at runtime. When the door closed, the room would still look like it were open! So you say, "Wait a minute, pha3z! Doom 3's real time lighting already casts proper shadows that would make the light disappear if the door closed!" Precisely. That is why you either wouldn't use lightmaps in this case or you'd be very clever in how you used them. There is *at least* one workaround for the door example. You could bake two lightmaps -- one for the lighting when the door is open and one for hte lighting when its closed. Then you could blend between them with a script when you close/open the door at runtime. Doing that is beyond the scope of this tutorial, however. My aim is only to show how to get lightmaps into Doom 3. Its up to you to make them turn your boring old point-lighty doom3 map into a work-of-art. Lets get started implementing these wonderful lightmaps in our own doom3 map! On to Page 2 -- Last Updated: 9/12/2005 Author: Jim Houx email: pha3zme@gmail.com |