Lightmaps In Doom 3 Engine: A Hybrid Approach To Real-time Lighting

[AluminumHaste]

http://www.fuzzpopfx.com/tutorials/doom3/

 

This looks like a similar approach as in Quake 4, might be useful for us.

[OrbWeaver]

The procedure is basically

 

1. Export map geometry to OBJ

2. Import the OBJ into a 3D app, merge into a single object, position lights and render to texture in the 3D app.

3. Export the rendered mesh with its baked material, and import it back into your map.

 

It would work, but wouldn't do the performance any good, since whole sections of your level would have duplicate geometry.

 

I did think of a similar idea of pre-baking lighting into the vertex colours for terrain meshes, which I haven't yet tried but might be successful at making outdoor areas look better. I wouldn't do it for buildings or indoor scenes however.

[sparhawk]

As long as a light is not moved it is baked anyway. So why go to the trouble?

[AluminumHaste]

As long as a light is not moved it is baked anyway. So why go to the trouble?

 

Because you can simulate radiosity this way, which isn't possible in doom3's engine.

[sparhawk]

Ah! Cool.

[bob_arctor]

Sorry, what does that mean?

[OrbWeaver]

As long as a light is not moved it is baked anyway. So why go to the trouble?

 

It is only the shadow volume which is precalculated; the light itself is rendered entirely dynamically.

[Komag]

Would this work properly with the light gem? I don't really know much about it, but it seems like it wouldn't

[Dram]

Would this work properly with the light gem? I don't really know much about it, but it seems like it wouldn't

 

Yeah it would'nt, so it's pretty useless for us anyway. Not to mention a lot of the lights are meant to be take-outable...

 

 

However, you can leave a paramater in the material files exposed to do some nifty shit with it - for example have a script which changes parm7 (which is tied in the material file to a door texture) and make a door fade in/out - which would be funky but would make the player think "wtf?". But yeah, with using this method, you could have the material change as a light is taken out, thus having a proper effect, though you'd have to have the main model broken up into several pieces, and overall it's a massive pain in the ass for less functionality and slightly better looks - what's the use if the rest of the lights cast sharp shadows?

[Dram]

Also, a much better way to achieve lightmaps is by using decals - this way you can stretch them accross the edges of a super-sharp shadow and make it look better, but again, objects that actually move will still be super-sharp-shadow casters.

[sparhawk]

Would this work properly with the light gem? I don't really know much about it, but it seems like it wouldn't

 

As long as the player is lit by the renderengine it would work. If not, then not.

[AluminumHaste]

Also, a much better way to achieve lightmaps is by using decals - this way you can stretch them accross the edges of a super-sharp shadow and make it look better, but again, objects that actually move will still be super-sharp-shadow casters.

 

That is the way this works as far as I can tell. You render the lighting to a texture, which is then applied to the whole level via a decal. This is bad as this adds an extra rendering pass per frame rendered so this isn't such a good idea.

The best way would be to add real-time radiosity lighting (which isn't possible with today's tech, too slow), that way we could have our cake and eat it too.

[bob_arctor]

What's so good about radiosity compared with the D3 system of lighting?

[OrbWeaver]

What's so good about radiosity compared with the D3 system of lighting?

 

It looks more natural. In real life, you do not get razor-sharp pitch black shadows in most situations; instead light reflects off lots of different surfaces to produce soft shadows which are only partially dark.

[AluminumHaste]

What's so good about radiosity compared with the D3 system of lighting?

 

Heh, are you serious?? Remove all ambient light from the real world, and you'll see why radiosity is so nice. It's the only reason that Quake3 visuals are better in certain situations, also it's the reason HL2 is so nice to look at. It's charming.

 

Imagine when light comes through a window in a dark room. Sure the floor is lit up where the sun falls, but also the walls are partly lit too; This is called radiosity.

Also imagine that you wanted to see some detail next to you but you don't have a light. So you take a sheet of white paper, stick it in the sunlight and it will reflect the light onto the surface.

 

Here's a pic to demonstrate why it's important:

 

If there is no radiosity, the wall that's lit up in real life, is completely black. This sucks ass for the most part. We can fake it with some low intensity spot lights, but this is where pre-calculated lightmaps show there strength.

[J.C.Denton]

The procedure is basically

 

1. Export map geometry to OBJ

2. Import the OBJ into a 3D app, merge into a single object, position lights and render to texture in the 3D app.

3. Export the rendered mesh with its baked material, and import it back into your map.

 

It would work, but wouldn't do the performance any good, since whole sections of your level would have duplicate geometry.

 

I did think of a similar idea of pre-baking lighting into the vertex colours for terrain meshes, which I haven't yet tried but might be successful at making outdoor areas look better. I wouldn't do it for buildings or indoor scenes however.

 

Aah, I was thinking along the same line. Why not bake ambient occlusion this way? Visuals would definitely drastically improve. I had also started a thread that talked about baking AO in textures:

http://forums.thedarkmod.com/topic/10720-texture-creation-suggestion-the-generation-leap/page__view__getnewpost__fromsearch__1

 

Right now AO like effect on map geometry is achieved by painting grime decals which is very cumbersome and time consuming. We can follow above approach to obtain AO for map geometry.

[Baddcog]

I think the major problem with this approach is time consumption. But also file size.

 

First, as far as I know, exported obj files aren't uvmapped, and even if they are they are tiled. AO needs unique uv space to be correct. In some cases you can overlap, but you can't bake it overlapped. So you'd have to uv map the entire level.

 

Then you get to texture size. How many 256x256 textures would it take to cover the uv for an entire map? And laying out lights for each area? Real easy to bake a room, or outside of buildings or an object. But trying to light an entire map for good AO.

 

Remember that tutorial is for an 'arena map'. All it is is a large open courtyard, that could take a few hours to set-up and bake properly and get the desired results. Now add a full castle, city streets, sewers...

 

With any baked AO there is going to be the overlay texture performance issue and texture size. But in an engine like Hammer it bakes the maps during compile. You can set the resolution of them while textureing (on top of a roof you can make the res very low, players won't see it much and it won't get many light bounce...).

You don't need extra objects, the AO maps are built into the map so you don't have to find/distribute them...

 

You also could not just make one AO object, the entire thing would always render even through closed portals, so then you also have to account for where to break it up (based on portals). That could add alot of compleity to even simple areas.

 

Sure, it can improve the looks, but it is a very difficult task to perform everytime someone makes a map.

 

What we truly need is coding bult in to the compiler/renderer that pre bakes AO using the ambient world light.

[J.C.Denton]

AO maps can be really small in size. They'll look blurry due to bi-linear filtering but that goes well with AO. So texture size won't be much of problem. UV unwrap could definitely be an issue.

 

To work around the problem of having to make entire level one object, level can be broken into different objects, but again that's cumbersome task.

 

As it seems, there has to be a built in AO generator in the editor itself.

 

What we truly need is coding bult in to the compiler/renderer that pre bakes AO using the ambient world light.

 

You don't need a light to compute AO.

[STiFU]

Yeah I dug this out too once. Here are some screenshotsetc as well.

[Baddcog]

Well, In Hammer the Ao is comupted from light sources and sunlight. Once you get into a building, with no lights in it you would have no light, even with 20 bounces, it just won't get to dark spots.

 

As the lights are dynamic, and not used during compile (and can be turned off) I assume you would need some light source to bake AO with. In which case the world ambient is best as it reaches everything in the level evenly.

The author can also adjust the brightness of that light in particlular easily.

[STiFU]

You're confusing Radiosity with Ambient Occlusion, just like I did. AO is independent of lightsources. Check it out on wikipedia.

[demagogue]

Just thinking aloud, one way to deal with the texture-quantity & UV'ing issues might be a megatexture (?), once/if we figure them out. Not sure if it would save so much time since you'd still have to get each shadow the same way, but at least you might get them all onto one megatexture and you're set for the entire space. This might just work well for outside areas (at least I don't know if/how megatexturing interiors works), and you might lose the ability to texture-swap by script, but it's an idea.

 

And I thought I recalled when we were talking about decal stencil-shadows a trick to rig the light-gem to respond by script or something.

[AluminumHaste]

Holy thread resurrection Batman!!! I posted this in 2006 lol.

[Baddcog]

You're confusing Radiosity with Ambient Occlusion, just like I did. AO is independent of lightsources. Check it out on wikipedia.

 

 

I know what it is, but in programs that render it you set paramters of how much light there is. You don't actually need to make a light, but there is a setting. Other-wise there is no light to make the shadows, hence to occlusion from the ambient light.

 

I know I said light bounces but my point is that if you have a completely dark room, and try to render AO for it the AO map would be black. Which is basically what we have in the Doom3 engine now, no light = black.

 

In DR the ambient light wouldn't 'bounce', but it would hit all surfaces, thus making some areas of the bake lighter and some areas (corners) darker.

[Diego]

I have some ideas for simulating a radiosity with dynamic lights.. probably hard to implement with scripting, also very restricted and difficult for the mapper, but in some key areas it might make a difference.

Edited March 3, 2010 by Diego