| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003818 | The Dark Mod | Coding | public | 18.08.2014 08:55 | 22.06.2023 06:22 |
| Reporter | SteveL | Assigned To | stgatilov | ||
| Priority | normal | Severity | normal | Reproducibility | have not tried |
| Status | resolved | Resolution | won't fix | ||
| Product Version | TDM 2.02 | ||||
| Summary | 0003818: Parallel lights glitch | ||||
| Description | Parallel 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 Information | Back 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 ] ) { continue; } 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. | ||||
| Tags | No tags attached. | ||||
 |
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. |
|
|
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. |
 |
Probably related: https://bugs.thedarkmod.com/view.php?id=5084#c11960 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. |
 |
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. https://drive.google.com/open?id=1cipp8rwvNOkasdsT4G-5ZEGZgHYbuGSB 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. |
|
|
A selection of screenshots that were sent to me by betatesters for Perilous Refuge. peril_projected_lights_shadows1.jpg (135,456 bytes) |
|
|
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. https://drive.google.com/open?id=1LpFgFuJCax8L3VTNQHxbtJIWtOX4NO_e |
|
|
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. |
|
|
Ok, Grayman provided a good example of this issue: https://forums.thedarkmod.com/index.php?/topic/20212-issues-with-directional-or-huge-lights/&do=findComment&comment=442668 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 braeden_church.map 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!) |
|
|
(Fixed in svn rev 8506) --- reverted! |
|
|
Note: with last fixes, parallel lights can be quite bad for indoor performance This is going to be fixed in related issue 0005111. |
|
|
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/3818_parallel_moonlight.map 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. |
