Light-mapping approaches, engine discussion

[nbohr1more]

Doom 3 and light-mapping have been discussed to death over at Doom3world but not much after the GPL release.

I wanted to start this topic to discuss the relative performance tradeoffs for possible implementations.

My main interest is using the lightmap to modulate ambient lights rather than replace "real lights" though some
of the approaches below might work for that purpose too.

Approach 1: Full map low resolution 3D texture sparse sampled per ambient light

Positives:
works for both static and dynamic geometry
only one input resource per map
could be used for "real" outdoor lighting with a single source (sun \ moon) if the ambient shader is modified to
set normal shading based on the light_center of the ambient light

Negatives:
Large dataset
May require LOD hierarchy or interpolation (or both) to avoid resolution artifacts
3D textures are not widely used (driver issues?, performance?)
May require hacks like scripting the light_center to move to change lighting in
interior vs exterior situations

Approach 2: Multiple definable brush volumes with mapped 3D textures sample per associated Ambient light

Positives:
works for both static and dynamic geometry
could be used for "real" outdoor lighting with a single source (sun \ moon) if the ambient shader is modified to
set normal shading based on the light_center of the ambient light
each ambient can produce it's own unique scene contributor
easily modulate the ambient contribution to the scene via dynamically raising or lowering ambient light levels per light
no need to script light_center behavior as with approach 1

Negatives:
Large dataset (not as large as approach 1)
3D textures are not widely used (driver issues?, performance?)
More overhead and complexity than approach 1 (performance?)
Multiple light-map bake operations (per ambient light)

Approach 3: Full map medium resolution traditional 2d light-map sparse sampled per ambient light

Positives:
uses traditional 2D UV based light-map data
low dataset requirement
only one input resource per map (low complexity)
should have a good performance profile

Negatives:
Dynamic objects wont match the ambient shading quality of static objects (mitigation: probes?)
Cannot be used in place of real lights because of issues with dynamic objects (see point above)
Ambient solutions with normal shading may look incorrect since only one light_center can be defined

Approach 4: Multiple definable UV regions with light maps sample per associated Ambient light and interpolated
ambient attenuation from the radius of the light volume towards the light_center (inverse projection) cubemap
or spherical harmonic
(similar to HL2 ambient cubemap?)

Positives:
uses traditional 2D UV based light-map data
lower dataset requirement than 3D textures
approximates real light bounce behavior
per ambient light contributions and dynamics possible

Negatives:
still some mismatch between dynamic and static lighting (better than approach 3)
more overhead than approach 3, more UV data
Multiple light-map bake operations (per ambient light)
Multiple cubemap or SH bakes (per ambient light)

Approach 5?: add more pseudo radiance bounces to Maha'X's Brilliant Highlights shader.
add the same bounce behavior to ambient lights


Thoughts? Options?  Analysis?

[Zombie]

What's the motivation for lightmaps?

Wouldn't it be better to just change the renderer to a physicaly based renderer and add things like GI, And the different methods of AO to give the light bounce feel?

Sure your minimum performance is going to sky rocket, but you'll have a much better looking game.

But if you want to go lightmaps, I'd go full traditional UV style for everything, then flag dynamic objects to ignore lightmaps and just use dynamic lighting and shadows.

Kind like how Half Life 2 does it, but I would look in to adding shadow map support so the shadows from dyncmaic objects fit with the lightmaps, stencil shadows would contrast too much against lightmaps I think.

[nbohr1more]

I have a few reasons for interest in Light-mapping.

To begin, we are continually asked about this feature from former Thief 1 \ 2 mappers who are used to
it in Dromed. They know that TDM has a heavier performance requirement and know that real-time lighting
is a big culprit in that aspect. Simply having the feature would allow them to work on maps in their own
preferred method rather than struggling with Doom 3's light optimization. Of course, nothing is as simple as
it seems from a lay perspective (I will include myself in that category to some degree... ). Mappers will want
to have their cake and eat it too. They will want dynamic models to blend with backgrounds, etc. So some
sort of sensible approach that makes that possible is what I'm aiming for.

Another reason, "publicity". Yes, it might not be a popular thing to say but the public (like the Thief \ Dromed community)
has roughly speculated about Doom 3 with lightmaps since it was released. Having the feature would generate some
publicity for our project and the more eyes we capture > the more players we have... then > the more mappers and contributors
we gain. It's a numbers game. We've already seen a reasonable upswing in mappers since going standalone. This would
be another inflection point for community growth.

Final reason = Pessimism. I have been trying to beat the drum (bountysource campaigns, etc) for getting assistance porting BFG's renderer
to vanilla or replacing the renderer with a deferred or forward+ approach for awhile but nobody has stepped-up with a (public) solution yet.
Some of the above approaches are easier to implement as augmentations to the default rendering method in Doom 3 than replacing
significant amounts of the rendering pipe-line with BFG (etc) type rendering. The lower barrier of entry may entice a less experience developer
to try and tackle the project. The result, hopefully, is that (good looking) static or ambient light can have a lower performance requirement
than the current orthodoxy where multiple real or ambient lights are used to decorate (or a single flat ambient light is used and the artistic
result is compromised.) Yes, a true GI would be great but TDM already is too taxing on mainstream PC's for it's comparative visual output
(in the eyes of the public, at least... )... adding GI as an option would just make the game unplayable for more people.

So the hope is that this discussion will shed light on the best approach or inform about other possible pros and cons of each method.

Without full expertise on the underlying tech, I am partial to the "second approach" since it seems the most flexible.

[The Happy Friar]

Motorsep got the BFG engine fully supporting custom content now, just no code released yet: http://www.kot-in-action.com/blog_new.html

But, for the lightmaps, the most important question to me (if I had the mind to do this) would be this: Is my goal speed increase in gameplay, make it more like old tech or for extra eye candy?

Not 100% sure if Darkplaces does lightmap + realtime, but BerserkerQ2 does lightmap+real time.  It's not bad but the real time still kills the performance. 

So, maybe instead of forcing Doom 3 in to something we want, it might be easier to take something else and add in the parts we want.  Like adding all the external file support of D3 to another id tech engine.

[nbohr1more]

Well, thinking on this some more, one thing that might not be too "low level" is fixing the spectrum keyword behavior
then assigning a secondary spectrum light and associated light-map model.

Workflow:

1) Draw a brush to match the dimensions of a selected ambient light
2) Export the contents of that brush via the the ASE exporter in Dark Radiant
3) Baked light bounces onto the exported model in Blender
4) Import model back into map and position to match ambient light volume
5) Apply spectrum keyword to material shader for the model

This would have the affect of only rendering ambient bounce detail when the associated ambient light is
of sufficient brightness and the contributions would go up and down dynamically.

The tricky part is still dynamic objects. You would need to include multiple spectrum stages in the material and
use a baked AO map for the spectrum pair...

Downside: all that external baking and model data (not too different from other commercial engines with light-mapping)

[Zombie]

Hrm having to export top bake? As a level designer I would say no thanks!

To bake lighting you already have to spend time unwrapping your models on the second UV map, otherwise you're gonna get auto unwrap UVs and it'll look bad, I don't then want to export to another application for certain areas to bake lighting. Just modify DOOMEdit to bake lighting for the whole level, it doesn't usually take long to do with modern PC's.

If you're gonna use lightmaps you should implement a full lightmap addition, not a half arsed one, you'll hit walls and frustration very fast with content developers.

What you should do though is nuke stenicl shadows if you haven't already and add shadow maps, and AO. That stuff is so cheap to run on todays hardware. It's not like you're making crysis level of detail and have massive sprawling areas.

Trebs RB BFG Renderer is very fast with shadow maps, you sould look into it.

[nbohr1more]

Yeah, Treb's work is good but we would need to port the GUI infrastructure from vanilla Doom 3 to make it workable
as we rely heavily on custom GUI code for our readables.

As for coding lightmap support into the editor, the mod's former lead developer was dead set against most texture bake
operations in our custom gtkradiant branch "Dark Radiant". We would need to attract a developer interested in porting
the lightmap bake from vanilla gtkradiant... It would be cool. Honestly it would be great to have texture and normal-map
bake support in Dark Radiant but I understand it would lead to larger maps with more custom assets... (not that mappers
aren't already stuffing maps with their own textures, sounds, and models anyway... we've got small missions with over
100mb of assets in them for pete's sake...)

[Zombie]

100mb of assets (sorry that this is going to sound smug - but I don't mean anything bad by it)

But 100mb is nothing really, I'm working on the new Assassins for X1 and PS4, and each section of the map is about 3gigs of data, I dream of only having to load 100mb

But nothing there is baked, except the GI, but god damn it looks gorgeous.

[nbohr1more]

Well, in a commercial game, each level is expected to have unique assets. The Dark Mod was designed to
be similar to fan mission editing for Thief 1 and 2 where the maps are 90% brush geometry which use textures from
the base game. So you can have a fairly large mission be under 30MB as long as you use stuff that is in our overall
project repository (about 3.5GB). The idea was to limit map sizes so that they wouldn't be too much of a bandwidth burden
for either the team or players (you should've seen the Thief 1 players balk at the "enormous" approx 10mb size of the first few missions).
Now the rules seem to be out the window. Mappers just stuff maps with all sorts of custom content and hopefully the
team wont run outta funds hosting it all. 

[motorsep]

Store data on DropBox and pay nothing?

Proper lightmapping required 3D voxel grid that will light up dynamic models accordingly. That's why it's not a trivial "bake textures" solution.

Doom 3 and derivatives were designed with unified lighting in mind. So from my point of view, you either need real-time GI, or more complex ambient lighting using probes, or stick to stylized art direction to take advantage of existing implementation.

If you really can't live without lightmaps - UE4 is there for cheap

And on top of that, baking lighting is by no means fast :/ I haven't tried UE4, but RAGE and q3map2 are _slow_ when it comes to baking lighting. Maybe 12 core CPU with 64Gb of fast RAM and SSD makes difference, but let's face it - most modders don't have that kind of hardware.

[motorsep]

By the way, Darkplaces engine has real-time photon based GI.

I don't know whether it's strictly idTech 5 related or in general (I've read somewhere UE3 took forever to bake lighting), but http://www.mapcore.org/page/features/_/interviews/interview-with-thibault-dkm-courbet-r40

"...the compile times for the megatextures and the radiosity lighting are horrendous making it impossible to work without a pretty big render farm and the different layers of technical things you have to do every time you change a layout ...."

Note that CryEngine 3 doesn't have lightmaps. All lighting is real-time.

[argoon]

What i find strange is why have you guys chose idtech 4 for TDM if lightmaps was something you guys wanted on it?  Why not chose one of the idtech 3 sources out there in the first place?

I'm not against lightmaps mind you but a game like thief gains much more with real time lighting, if you guys want to bake something then bake the ambient lighting only but let the direct lighting and the shadows be all dynamic, if not you guys are just going back instead of going forward, and if the old thief mappers aren't happy with how TDM does things, then let them be angry, they should be the ones adapting to the new tool not the other way around.

[motorsep]

One idea that comes to mind is to add option to dmap not to calculate prelit shadows, add flag to lights that makes dynamic shadowing code aware of such lights.

Levels would have to be all modeled, with lightmaps baked to second UV. In-game lights that don't move will have no flags, and will only cast shadows from the moving objects/entities. Lights that are flagged, will act as normal Doom 3 lights casting shadows from everything. This way you get baked lighting, properly lit dynamic objects, and dynamic lights casting shadows from everything (flashlights, carried on torches, projectiles).

With this method you could stay with shadow volumes and get nice lighting on your level and boost performance. It's also a least invasive method I think.

Note that this might not work at all