Ways to combine lightmaps and RTLights

[Spiney]

The bouncegrid cvar could be useful for improving rtlights but it seems that lights shine thru solid walls/brushes with this activated!

That's inherent to working with volume textures for lighting.

copypastepixel: Light volume sampling again

In a nutshell though, sampling a 3D scene at sparse regular intervals doesn't tend to yield very good results. Frequently the scene is sampled from behind geometry, causing light leaks and other issues.

You might be able to fix it be setting the bouncegrid to real time as opposed to static, in E1M1 for example the quad shines through the secret walls because you're using a static volume along with dynamic geometry (hidden door in this case).
My personal peeve with the current way the bouncegrid works is that the area of influence is way too low to do more convincing global illumination. Crysis 2 does something roughly similar with reflective shadowmapping rendering to volume textures, whereas the bouncegrid seems to use some kind of photon mapping approach.

[Moon[Drunk]]

I tried dp_bouncegrid_static 0 but the light still shines through brushes as before.


Here's how the difference between dp_bouncegrid_static 0 and 1 looks for me:

[FC Zvyozdochka]

With generous permission of Shadow, I'm posting here the pack containing his maps with relight for those who don't want downloading several packs.

As for original maps - Lexa2 has not yet finished his RTLights to *.lit converter, and I have almost no time for editing maps manually. So it will be done, but no so soon.

[FC Zvyozdochka]

Here comes a HUGE disappointment.
I've tried to edit start map in GTK Radiant 1.5 (just to delete several unwanted lights and to color some others), after that I saved it as start1.map and compiled it with hmap2. Resulted *.lit files just don't work with existing start.map! It means for me that I can't make relight for exisitng BSP's without changing them to edited ones.
But why then existing maps could carry changed *.lit files made by hmap2 (it has a lot of options to edit all the lights, but only altogether) or MHColor? Is there a way to change color and/or intensity of some lights and then to attach that files to the existing maps?

I don't want to create a new mapset, cause it eliminates the possibility to coop game.

Is there any solutions?

[Spike]

I don't know much about what mhcolor supports, but if you want a usable .lit file, you want a proper tool which does not allocate space within the lightmap lump of the bsp. This typically means you need a specific tool that does not change the bsp at all.
Such tools will generally need to have some lighting algorithm similar enough to vanilla to avoid big holes and other weirdness, though this is more of an issue with lightstyles other than style 0.
What I'm trying to say is that hmap2 is a general map compiler. It will not create a usable .lit file for unmodified bsps - unless of course you use some specific commandline argument to do that. The term '-relight' comes to mind, but I've no idea if that's correct or if it even exists.

Assuming mhcolor lights maps purely based upon the entities within the bsp itself, you can always 'compile' the bsp with -onlyents to update only the entity lump for mhcolor to read. You can then discard your recompiled bsp and use the lit with the pre-recompiled bsp as it is.

Note that *if* mhcolour ignores explicit colour tokens, you can try fte's r_loadlit 2 feature in the same way (again, requires -onlyents or such beforehand), but this is more unwieldly what with it being a side effect of map loading, so you're probably better off trying mhcolor first.

[FC Zvyozdochka]

I don't know much about what mhcolor supports, but if you want a usable .lit file, you want a proper tool which does not allocate space within the lightmap lump of the bsp. This typically means you need a specific tool that does not change the bsp at all.

Well, yes, both hmap2 (with -relight key) and MHColor produce *.lit and *.dlit files without modifying BSP, and then you can attach them to the existing maps - that's why MH's colored lightmaps pack and Havok's dlits can be downloaded and used.

What I'm trying to say is that hmap2 is a general map compiler. It will not create a usable .lit file for unmodified bsps - unless of course you use some specific commandline argument to do that. The term '-relight' comes to mind, but I've no idea if that's correct or if it even exists.

Yep, -relight option leads to unmodified BSP and additional lightmaps file. This is the way I made lightmaps for Shadow's maps and to the dm456sp - I just made very soft and smooth lightmaps with following option:

hmap2.exe -light -extra8x8 -intensity 0.2 -radiusscale 2 -minlight 15 -nolightvis -relight shw.bsp

But that relight is not suitable for original maps - they lack colored lighting and have many bugs which muck up the picture (especially Hipnotic maps)

Assuming mhcolor lights maps purely based upon the entities within the bsp itself, you can always 'compile' the bsp with -onlyents to update only the entity lump for mhcolor to read. You can then discard your recompiled bsp and use the lit with the pre-recompiled bsp as it is.

MHColor is just an example, it colors lights automatically while I'm trying to color them manually (with better result, I guess).

[MH]

With MHColour I was very particular about not modifying the original BSP - to the extent that I was prepared to even accept cases where it didn't light it well (some of the Rogue maps don't work well with it, for example).

I don't pretend it's a general-purpose relight tool, but when it works well it does work quite well. It's robust enough for id1 content, but anything fancy can still trip it up. If it doesn't work well with a particular map, then don't use it for that map - it's job is not to compete with manual placement of light entities and colours (which will always be better) but to provide a reasonably quick and dirty hack for automatically getting colour into some maps.

For input it uses a combination of 3 things - entities, textures and the original light data. Only certain light entities get to provide colour - mostly torches. The rest is derived from textures that have fullbright colours in them, lava and slime.

These then produce a radiosity map (it uses radiosity but no bounces) which is finally combined with the original light data to produce a LIT file. That's how the lava colouring in the hard hall in start.bsp gets to not affect the top-sides of surfaces, for example.

As with anything involving Quake lighting, brush models will be coloured as if at their origin points, and BSP brush models won't be coloured at all.

[Spike]

well, use -onlyents when 'compiling' the bsp, and it'll ONLY replace entities. Then your -relight process will use the updated ents with the old lightmap/surfaces lump.
Any lits produced from that should work fine with unmodified bsps.

Just beware of surfaces receiving lightstyles that they didn't have before.

[MH]

Just beware of surfaces receiving lightstyles that they didn't have before.

Ideally the LIT file format would have included surface offset and style info so that this wouldn't be a problem (it would have been more complete too, containing everything needed to light a map), but it's too late to go back now.

[FC Zvyozdochka]

So, what's the consequense?
I open "start.map" with Radiant, delete some lights, add some other lights and color some of them in necessary colors.
Then I'll be need to compile it. How? hmap2 -onlyents, or maybe I should use another compiler? What should it create - special entities file in addition to existing and unmodified BSP or what?

[Spike]

Grab a copy of the map source (Romero's release should generally work (although there's a couple of cases like end.bsp which might be questionable), but if in doubt, winbsp should be able decompile them well enough for your needs).
Open the map in your favorite editor.

Move ents around, create/remove lights.
Do NOT delete/add any brush entities, as that will affect lighting (the bsp needs to retain the same inline models in the same order). The brushes you see in the editor are irrelevent, they will be ignored by the -onlyents argument.
Export your .map with your light entity changes.

Compile it with -onlyents. Doesn't really make a difference which qbsp you use.
This will edit the bsp. However, in a vanilla-compatible way. Its identical to vanilla except for the entities lump.
I don't know about radiant, but worldcraft can let you recompile with -onlyents directly from the editor.

Then -relight/mhcolour your (modified) bsp.
Now that you have your .lit file, you can delete your modified -onlyents bsp and your lit will work with the true vanilla bsp too.

[FC Zvyozdochka]

I've just completed the relight of all the id maps, including DM ones.
The game look is noticeably better (IMO) in many places, and FPS is noticeably higher in many other places (but not everywhere ).
I'm opening a new thread to share this relight.