View Issue Details

IDProjectCategoryView StatusLast Update
0003818The Dark ModCodingpublic22.06.2023 06:22
ReporterSteveL Assigned Tostgatilov  
PrioritynormalSeveritynormalReproducibilityhave not tried
Status resolvedResolutionwon't fix 
Product VersionTDM 2.02 
Summary0003818: Parallel lights glitch
DescriptionParallel lights glitch, especially on or through BSP portals. Glitches include disappearing, flashing shadows, and unlit surfaces where a not-quite-vertical black line tilts with the player view.

Quite likely some or all of this is due to light culling in the renderer front end. Some of the interactions get filled back in later.
Additional InformationBack in March I demo'd a method I'd stumbled on of getting one parallel moonlight to illuminate an entire map glitch-free. That method was to use caulk tubing in and around the map to make sure the light could not be more than 1 visportal away from any spot where you wanted it to cast shadows. This bit of code looks relevant. It culls light interactions selectively for visleafs:

// check for being closed off behind a door
// a light that doesn't cast shadows will still light even if it is behind a door
if ( r_useLightCulling.GetInteger() >= 3 &&
     !light->parms.noShadows && light->lightShader->LightCastsShadows()
     && light->areaNum != -1 && !tr.viewDef->connectedAreas[ light->areaNum ] ) {

The very last condition is the one of interest: it culls light interactions from a particular visleaf if the light's own visleaf isn't "connected" to the current visleaf by an unblocked portal.
TagsNo tags attached.


related to 0005111 closedstgatilov Restore and adjust FlowLightThroughPortals for parallel lights 
related to 0005106 resolvedstgatilov dmap-optimized stencil shadows errors 
related to 0005121 resolvedstgatilov Convenient parallel light for moon or sun 
related to 0005172 resolvedstgatilov Improve interaction culling: case when player-visible object is not visible from light 




18.08.2014 09:21

reporter   ~0006856

Theory to test: if interaction culling is the culprit, it would affect all shadowcasting lights equally. Maybe it does, but maps don't tend to have other kinds of shadowcasting light stretching over several visleafs.

Parallel lights share another glitch with fog lights: you don't want the edges of the light volume to be in view as they have an ugly hard boundary. Not that it makes sense to have either in view. People probably do that with parallel lights only because they use several small ones instead of one big one in an effort to hide the glitches. That's the advice in the wiki.


19.08.2014 01:39

reporter   ~0006858

Last edited: 19.08.2014 02:46

Another to check: idRenderWorldLocal::CullLightByPortals

And idInteraction::CullInteractionByViewFrustum, which culls light interactions if the shadow could not be in the player's current view. But it uses a projection from light origin.. check this isn't used for parallel lights, or that the origin has been extended to infinity, else the test is invalid.



03.01.2020 11:02

administrator   ~0012040

Last edited: 03.01.2020 11:06

Probably related:
The original interaction scissors was flooding portal areas incorrectly, which could result in shadows disappearing sometimes.
The bug is fixed now.

It would be grate to have some sort of map to test.



03.01.2020 15:40

developer   ~0012044

Perilous Refuge suffered heavily in beta from incorrect stencil shadows being cast by projected lights (not parallel lights, those weren't used). In the release build I disabled shadows on all projecting lights, but for this bug I've uploaded a modified FM with shadows re-enabled on those lights.

Many betatesters reported these shadow issues, and different testers had problems with different lights. Not all lights were affected. Look in the buildings for projected window lights.


03.01.2020 15:42




03.01.2020 15:42

developer   ~0012045

A selection of screenshots that were sent to me by betatesters for Perilous Refuge.


03.01.2020 15:49

developer   ~0012046

If you can't reproduce the stencil shadows issue on my modified Perilous Refuge map, I've also attached the original beta build in which the above screenshots were made.


03.01.2020 17:43

administrator   ~0012049

I managed to reproduce problem both on 2.07 and SVN at location: 826.77 -1711.7 907.19 42.5 151.7 0.0
If you move around and carefully look at shadows near floor, you might notice that some shadows move with player, and they are wrong (and different from "maps").

The workaround for this issue is: r_useOptimizedShadows 0
This is different from area portals issue I was talking about, and most likely different from what SteveL described.
I'll create another issue about it.


06.01.2020 09:46


braeden_church.7z (704,035 bytes)


06.01.2020 09:46

administrator   ~0012092

Ok, Grayman provided a good example of this issue:

Here are full repro steps:
1) Download "Braeden Church FM" to get all the materials
2) Download attached archive and unpack the .map file into {root}\fms\braeden_church\maps\
3) If you play the map now, you should see strong moon light everywhere (caused by parallel light called "Moonlight")
4) Now execute: dmap
5) Restart the map again: moonlight is missing almost everywhere, except for the area near church.

When you run map at step 3, it uses .proc file of unmodified map, which does NOT contain a prelight model for Moonlight. That's why it works.
Then when you run it at step 5, it uses freshly generated .proc file, which contains prelight shadowmodel for Moonlight, which tells renderer to use another route.
This another route is buggy.
It can be disabled by setting: r_useLightPortalFlow 0 (note: you must set cvar BEFORE starting/loading mission for it to take effect!)


07.01.2020 04:14

administrator   ~0012101

Last edited: 08.01.2020 08:00

(Fixed in svn rev 8506) --- reverted!



07.01.2020 04:21

administrator   ~0012102

Note: with last fixes, parallel lights can be quite bad for indoor performance
This is going to be fixed in related issue 0005111.


08.01.2020 07:58

administrator   ~0012119

Last edited: 08.01.2020 07:59

I reverted all my changes from svn rev 8506 in svn rev 8516.

It turned out that I was wrong with those fixes.
The old code considers parallel light to start in single area. That's good because it allows it to cull away parallel light from indoors areas (by portals).
With my 8506 changes, there was absolutely no way to cull parallel lights anywhere, which was very bad for performance.

I have added test/ to assets SVN. It shows a way how to use single global parallel light to light many areas.
The idea is to add an huge area on the very top of the map and put the parallel light into it. Then provide visportals from this area down into individual areas where player walks.
This way engine will start tracing light rays from the top area through portals, and parallel light will take effect in all areas it will reach.

Issue History

Date Modified Username Field Change
18.08.2014 08:55 SteveL New Issue
18.08.2014 08:55 SteveL Status new => assigned
18.08.2014 08:55 SteveL Assigned To => SteveL
18.08.2014 08:58 SteveL Additional Information Updated
18.08.2014 09:21 SteveL Note Added: 0006856
18.08.2014 12:04 SteveL Additional Information Updated
19.08.2014 01:39 SteveL Note Added: 0006858
19.08.2014 02:00 SteveL Note Edited: 0006858
19.08.2014 02:46 SteveL Note Edited: 0006858
15.02.2017 04:40 grayman Assigned To SteveL =>
15.02.2017 04:40 grayman Status assigned => new
03.01.2020 11:02 stgatilov Note Added: 0012040
03.01.2020 11:06 stgatilov Note Edited: 0012040
03.01.2020 15:40 Dragofer Note Added: 0012044
03.01.2020 15:42 Dragofer File Added: peril_projected_lights_shadows3.jpg
03.01.2020 15:42 Dragofer File Added: peril_projected_lights_shadows2.jpg
03.01.2020 15:42 Dragofer File Added: peril_projected_lights_shadows1.jpg
03.01.2020 15:42 Dragofer Note Added: 0012045
03.01.2020 15:49 Dragofer Note Added: 0012046
03.01.2020 17:28 stgatilov Assigned To => stgatilov
03.01.2020 17:28 stgatilov Status new => feedback
03.01.2020 17:43 stgatilov Note Added: 0012049
04.01.2020 04:27 stgatilov Relationship added related to 0005106
06.01.2020 09:46 stgatilov File Added: braeden_church.7z
06.01.2020 09:46 stgatilov Note Added: 0012092
07.01.2020 04:14 stgatilov Note Added: 0012101
07.01.2020 04:20 stgatilov Relationship added related to 0005111
07.01.2020 04:21 stgatilov Status feedback => resolved
07.01.2020 04:21 stgatilov Resolution open => fixed
07.01.2020 04:21 stgatilov Fixed in Version => TDM 2.08
07.01.2020 04:21 stgatilov Note Added: 0012102
08.01.2020 07:58 stgatilov Note Added: 0012119
08.01.2020 07:59 stgatilov Resolution fixed => won't fix
08.01.2020 07:59 stgatilov Fixed in Version TDM 2.08 =>
08.01.2020 07:59 stgatilov Note Edited: 0012119
08.01.2020 08:00 stgatilov Note Edited: 0012101
11.01.2020 11:47 stgatilov Relationship added related to 0005121
22.06.2023 06:22 stgatilov Relationship added related to 0005172