Jump to content
The Dark Mod Forums

One solution to overlapping lights


Moonbo

Recommended Posts

I spent some time working on my WIP map today and ran into a situation with a multi-layered structure with oil lamps on each floor. The problem was that I could see both levels of my structure simultaneously and the radii of my lights was too tall and I got a lot of overlapping lights between the floors of my structure, leading to bad performance. I was able to solve the problem using a method similar to one I used in the "pit" portion of Requiem and since it works so well I thought I'd share it. Note that proper use of visportals will most often solve overlapping lights, since you can lock some of your lights behind a closed visportal where they won't render. So only use this method if you have geometry which makes that impractical.

 

Overlapping lights (i.e. lights whose radii light up the same objects/geometry) are one of the most common performance killers in TDM. Unfortunately the standard light entities have two issues which make it a common problem, especially if you're lighting up geometry where you can see through more than one room/floor at the same time:

 

a) For the sake of realism, the light entities need to be attached very close to a wall (for torches) or ceiling (hanging lamps). This means that a large part of the light radius is going to be poking out the other side of whatever wall/floor you attach it to. If you have any other lights nearby, like in the next room or the next floor, you'll get overlap.

 

b ) The default light texture on light entities (usually biground_torchflicker or biground_candleflicker) produce a relatively weak light which means you need a relatively large radius to compensate. The result is that the radius of your lights is normally going to be much wider/taller than the geometry you're trying to light up.

 

The following is a step-by-step walkthrough of one solution to this problem. This solution is meant to be used in situations (like mansions or multi-level structures) where you have many lights in proximity and need to make sure they're not touching each other for performance reasons. A drawback to this method (besides the time it takes to set it up) is that it will generate more entities in your map than if you just used standard lights.

 

I start off with a two-story structure with two wall mounted lamps, one on each floor:

 

8qm2.jpg

 

1) When you select the lamps in Dark Radiant you just see the model. You don't see the light that it will generate. But when you load up your map, the light is present. What's happening is that the entity has a default light attached to it which is spawned when you load the map. You can find it by looking at the lamp entity in DR and checking for the "def_attach" spawnarg. For these lamps that spawnarg is set to "light_candleflame", which is the light entity that's spawned on the lamp when we load the map. All of these various light entities can be found under Lights->Light Sources in the entity viewer.

 

2) Now that we've identified which light is being spawned by our lamps, the next step is to add the spawnarg "def_attach -" to the lamps. This removes the default light, so that if you were to load up the map, no light would be emitted by them.

 

3) Next create a 'light_candleflame' entity, position it on the lamp, and use the "bind" spawnarg to connect your light_candleflame to your lamp entity. Now if you load up the map, your lamp will look and act just as a normal lamp entity would. But since you can now see the light that's being cast in DR, you now can customize the spawnargs of the light. By itself this is a great way to eliminate light overlaps because you can just tweak the radius of your light (as well as color, whether it casts shadows, etc) instead of relying on the default light entity radius.

 

At this point, after creating my custom lights and tweaking their radius a bit, here's how everything looks in Dark Radiant.

 

t052.jpg

 

You'll noticed that I've still got the light radii overlapping through the ceiling. In looking at this situation the only way I can have these two light not overlap each other is to move the lamps up and down the walls until they're farther apart. Sadly I can't do that without the lower lamp ending up hovering over the floor. Not only that, but if I move the lights farther apart the light will no longer significantly illuminate the ceiling even if I boost the light's brightness to 100.

 

Let's solve the first of these problems: how do I get these two lights to not overlap without moving my lamps farther apart. The solution is to create a second light.

 

4) First, create a 'light_extinguishable' entity (found under Lights->Base Entities) and give it a radius such that it's just barely touching the ceiling and the floor. Give it the same light texture/color/ etc of the light_candleflame, and bind it to the lamp with the 'bind' spawnarg. If you want shadows to be cast from the direction of the lamp, move the light center on this new light to above the lamp (the light center determines where it looks like shadows are coming from. You can select it by clicking on a light and going into vertex mode. Then just move the vertex at the center of the light around).

 

5) Give the original light_candleflame that we created a radius of 1 1 1 . This will make the light so tiny that it won't cast onto any geometry. The reason we don't just erase it all together is because a) it creates a light flame particle for our light and b ) it will generate smoke etc when our light is extinguished.

 

Once done to both lamps, this is what it should look like:

 

ewuq.jpg

 

Voila. We've now got two lights on top of each other that don't overlap and will act exactly the same as a normal lamp entity would in game (i.e. extinguish, turn back on, etc).

 

Now let's solve the final problem: this setup is great but if I load it up in-game, the lights are very dim across the ceiling and floor, even if I boost the light brightness to 100. Because only the very edge of the light's radius touches the ceiling and floor, the illumination will be quite dark.

 

The solution is to create a custom light texture. Most lights in TDM cast a light texture, basically a 2d image painted along the light. The light textures for most lamps/candles are based on the "biground" light texture, which ends up making the lights pretty dim. There's another light texture called "brightround" which when applied will make the same light incredibly bright. My custom light texture is a brightround which flickers like a torch.

 

6) Create a custom material file with the following contents (or just use the one I have with the test map):

 

//This is a brightround with a torch flicker. Very useful if you want to avoid light overlaps because you

//can have a much brighter looking light at a much lower radius than with the standard torchlights.

 

lights/brightround_torchflicker

{

lightFalloffImage makeintensity( textures/lights/brightround )

{

forceHighQuality

// no shadow down or up

map textures/lights/brightround

colored

zeroClamp

red ((.05 * sintable [(time * ( 2 + Parm3 ) ) ]) +.95) * Parm0

green ((.05 * sintable [(time * ( 2 + Parm3 ) ) ]) +.95) * Parm1

blue ((.05 * sintable [(time * ( 2 + Parm3 ) ) ]) +.95) * Parm2

}

}

 

7) Select our light_extinguishable and open up the light editor (by default press L). In the light editor apply the brightround_torchflicker texture to our lights. You'll notice that when you do this the lights become, much, much brighter. In fact you may need to lower the light's brightness (also in the light editor) to get them looking normal. Tweak the brightness to your satisfaction and you should be good to go.

 

Here's how the lights look in-game.

 

u01o.jpg

 

You now have two working lamps stacked on top of each other without any overlap. The same trick can be used to have non-overlapping lights on either side of a thin wall, etc. Hopefully it'll be useful in your mapping endeavors :smile:.

 

LightSolution.pk4.txt

Edited by Moonbo
  • Like 2

But you should walk having internal dignity. Be a wonderful person who can dance pleasantly to the rhythm of the universe.

-Sun Myung Moon

 

My work blog: gfleisher.blogspot.com

Link to comment
Share on other sites

Er... That's a whole lot of work for a simple optimization. I would never see such a trouble.

 

Instead, I would simply use a different lighting setup. Place one big light with shadows on and put noshadows lights where you get away with it. Or use several smaller lights with shadows on and make sure they do not exceed overlap of two lights. Or use lights with shadows on, but disable shadows on majority of func_static objects.

 

There is always circumstances in a scene which you can exploit to get good performance with the most lazy implementation. Analysing the scene with r_showprimitives is useful

 

But sure, if one likes to do stuff like that, no problem. It just isn't mandatory.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

Hey Sotha, very true. This is only one solution to light overlaps causing performance problems. There are others :smile:.

 

@ Biker, I'll try to set up an article on the wiki sometime later today.

But you should walk having internal dignity. Be a wonderful person who can dance pleasantly to the rhythm of the universe.

-Sun Myung Moon

 

My work blog: gfleisher.blogspot.com

Link to comment
Share on other sites

void between floors also works

 

This is curious, since the void exists between the face of the floor and the face of the ceiling below, regardless of the distance between them, and regardless of whether one brush or two (or more) is involved. So I wouldn't expect a void sandwiched between a floor brush and a ceiling brush to be any more of a solution than a single brush that provides both the floor and ceiling.

Link to comment
Share on other sites

I'm confused. Where do the lights actually overlap in the above example? My understanding could certainly be wrong, but I thought it didn't matter at all if light volumes overlapped, it only mattered if they HIT the same thing (and that it had to be at least 3 lights and a fairly high poly shadow-casting thing to have any noticable effect, but that's a separate matter).

 

In the above example, the only thing they're hitting, as far as I can see, is the 'floor' brush. But don't they have to be hitting the same plane to be considered "overlapping"?

Link to comment
Share on other sites

I like gaining knowledge, but thinking through a silly question I had about this led to this realization...

 

One thing perhaps not clear is the unique geometry and rare circumstance to which this might apply? Visportals mean such overlap of lights don't even exist, because they aren't rendered and have no performance impact. Isn't it only if there's internal leaks, open visportals, or open geometric design you could even have such?

 

Note if you can't visportal due to design, you could simply change the radius/texture/origin offset of the existing light (via sparnarg: "set light_radius on flame" X Y Z, or equivalent and set texture...)

 

It does seem many open stairwells in FMs have lower performance, which seems to be the applicable type of geometry, with limited closed visportals.

 

PS: This might be what Stumpy meant by void working? As a single brush does work fine in my WIP, but becomes moot if you open around the void.

"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Link to comment
Share on other sites

In the above example, the only thing they're hitting, as far as I can see, is the 'floor' brush. But don't they have to be hitting the same plane to be considered "overlapping"?

 

I was presuming a liability of generating a simple visual to go along with the explanation. Perhaps consider the walls they are illuminating instead?

 

Imagine instead a wall with one of those oil lamps mounted on it that had a large enough radius to hit the floor. If there was a leak or opening to the room on the other side of the wall, and there was another light within that room also with a big radius. The floor in there would be perpendicular to both lights, and assuming no closed visportal, affected.

"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Link to comment
Share on other sites

I'm confused. In the above example, the only thing they're hitting, as far as I can see, is the 'floor' brush. But don't they have to be hitting the same plane to be considered "overlapping"?

Hmm I'm with you, @Moonbo did you mean to include the separating floor..? as this will just confuse new mappers. If the Lights are shadow casting but seperated by brush with a shadow casting texture they wont be able to overlap.

Link to comment
Share on other sites

Hey guys,

 

I should have been much more explicit about the situations where I used this optimization. It was in places where I had a lot of lights on multiple levels and you could see the levels at one time. So, the pit area of Requiem looked like this:

 

I had 4 lights in close proximity to each other on three floors that were stacked one on top of the other, with a big hole running through them:

 

 

requiemdemo201305232350.jpg

 

 

requiemdemo201305232351.jpg

 

So in this case if the lights overlapped through the various floors/ceilings then I had a serious performance hit (because the levels were visible simultaneously). That's what this method solves for - instances where you need to avoid having light overlaps through geometry. A more common example (like RJFerret mentioned) would be two levels of a house connected by a grand stairway where at certain angles you could see both floors at the same time. I'll update the OP to be more exact.

Edited by Moonbo
  • Like 1

But you should walk having internal dignity. Be a wonderful person who can dance pleasantly to the rhythm of the universe.

-Sun Myung Moon

 

My work blog: gfleisher.blogspot.com

Link to comment
Share on other sites

I'm confused. Where do the lights actually overlap in the above example? My understanding could certainly be wrong, but I thought it didn't matter at all if light volumes overlapped, it only mattered if they HIT the same thing (and that it had to be at least 3 lights and a fairly high poly shadow-casting thing to have any noticable effect, but that's a separate matter).

 

In the above example, the only thing they're hitting, as far as I can see, is the 'floor' brush. But don't they have to be hitting the same plane to be considered "overlapping"?

 

Even though lights appear to be directional due to the light_center behavior, the engine treats the light as a volumetric data set which is evaluated against both facing and non-facing polygons.

This means you will incur a hit for some "overlaps" that cannot be seen by the player in the form of overdraw.

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

...the engine treats the light as a volumetric data set which is evaluated against both facing and non-facing polygons.

 

Good to know, and will change some of my light placements and radius choices, thank you.

"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Link to comment
Share on other sites

This is curious, since the void exists between the face of the floor and the face of the ceiling below, regardless of the distance between them, and regardless of whether one brush or two (or more) is involved. So I wouldn't expect a void sandwiched between a floor brush and a ceiling brush to be any more of a solution than a single brush that provides both the floor and ceiling.

 

So... void between works or doesn't? I can test this myself though does anyone know?

 

My current WIP has multiple 2 and 3 story buildings that all currently have 8unit void gap betwen the floors is why I'm asking.

Link to comment
Share on other sites

I don't think void works either. If a light is set to "noshadows" it must render through walls (etc) to work as an ambient light across the area.

 

This is why I keep daydreaming about Deferred Rendering. No more worrying about light overlaps.

 

That said, the BFG renderer does a pretty nice job with overlaps too and doesn't rely on Deferred Rendering. It simply "doesn't skin the light

volume on the CPU then send that metric ton of data to the GPU"... It uses GPU Skinning for most light operations and it's just about as fast

as a Deferred Renderer like UE3 (I think Carmack was trying to prove a point to Tim Sweeny).

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

This means you will incur a hit for some "overlaps" that cannot be seen by the player in the form of overdraw.

 

So wait a minute. Does that mean if I have a two level tower, and on the first floor there is a light with a large radius that hits the ceiling, and on the second floor there is a complex model inside the radius of the first floor light, then there are light calculations being done for a light that isn't actually hitting the model?

 

Or, perhaps an easier example...if I make a regular light with a radius large enough to affect my entire level, but I build a box of brushes around it that seals it in, does that light still get calculated for everything in my map? Even if it's in its own visleaf?

Link to comment
Share on other sites

The answer to the first question is yes. The second question is more complex. The light calculations extend to the second Visportal past your fov but include every light whose radius touches an area within the second portal. A boxed in light counts as having two portals because you cannot get to the interior by making two turns so you shouldn't see a big hit for a boxed in light. If your area at the top of the tower is truly past the second portal then the model up there shouldn't affect the performance downstairs but the light will because it will cause everything between the first and second portal to be evaluated for draws. Conversly, the light that reaches up there from below will have an affect upstairs.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

This conversation is very interesting, is there some place where i can read in depth about the way idtech 4 treats and render lights?

 

About deferred rendering theres two types of it, one worse than the other, the first is deferred shading used in games like Stalker it has limitations that make it worse in some respects in my opinion then a forward render like idtech 4, first it only really wins on the number of small non shadow casting lights, make them bigger and or enable shadows and the performance gains go away, especially with shadows, where the limitations are exactly the same has forward rendering, it does not supports transparency, deferred shading has also very high initial memory footprint because of all the necessary textures it relies on, so on a simple scene with fewer lights is even slower than FR, it also limits the number of shaders effects and only supports a material type plus it prevents hardware AA on non dx10.1+ GPU's, you can of course use software based AA on them like FXAA or MLAA.

 

Then theres deferred lighting or Light Pre-Pass it has almost the same limitations has deferred shading but does permit more material types and also permits hardware AA on all GPU's.

 

But is possible to support many lights using forward rendering techniques like Eric lengyel demonstrated on this C4 video

 

 

See how only one of them is casting shadows and the lights are very small.

Edited by HMart
Link to comment
Share on other sites

Yeah, BFG pretty much proves that it wasn't forward rendering that caused the biggest performance problem in Id Tech 4. It was the CPU Skinning and feeding

all that skinned data across AGP\PCI-E. Moving to GPU based skinning in BFG improved performance ten-fold even though the number of render passes increased.

 

Regardless of how it's done, some solution to reduce the impact of light overlap would be cool...

 

This conversation is very interesting, is there some place where i can read in depth about the way idtech 4 treats and render lights?

 

This is the most comprehensive overview but more specific details would need to be gleaned from Doom3world and SplashDamage:

 

http://fabiensanglard.net/doom3/renderer.php

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 4 replies
×
×
  • Create New...