View Issue Details

IDProjectCategoryView StatusLast Update
0004128The Dark ModMappingpublic26.06.2015 20:00
ReporterSteveL Assigned ToSteveL  
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Product VersionTDM 2.04 
Target VersionTDM 2.04Fixed in VersionTDM 2.04 
Summary0004128: Spawnarg for lights to stop them affecting the light gem
DescriptionSee discussion http://forums.thedarkmod.com/topic/17066-bounce-lights-and-the-light-gem/
Additional InformationLightgem rendering passes have a special viewID so they can ignore weapons, overlays, etc.

RenderEntities have a bunch of member variables to control this kind of thing: suppressSurfaceInViewID;
suppressShadowInViewID;
suppressShadowInLightID;
allowSurfaceInViewID;

Add a suppressLightInViewID param for renderLights, to do the same job.
TagsNo tags attached.

Activities

SteveL

SteveL

06.04.2015 15:36

reporter   ~0007479

renderLights already have suppressLightInViewID. It's just not hooked up to a spawnarg.
SteveL

SteveL

06.04.2015 16:09

reporter   ~0007480

Last edited: 06.04.2015 16:11

Committed at rv 6487 (code), rv 14274 (new spawnarg).

game/Light.cpp
defs/misc.def

New spawnarg is "lightgem" which defaults to 1. It's available under inherited spawnargs.

grayman

grayman

06.04.2015 16:49

viewer   ~0007482

If a light with this spawnarg set to '0' doesn't contribute to the lightgem, is it reasonable to say that it will also not contribute to illumination of other objects? I.e. bodies on the floor, missing items, etc.

Might want to bring this up on the thread where this change was discussed.
SteveL

SteveL

26.04.2015 16:06

reporter   ~0007492

I only just spotted this question. The way it's coded right now, they are independent. The lightgem calculation is done by the renderer / GPU and it's a rendering step that's been switched off. Visibility of ropes and the like is calculated in a different way. I'll see what people think in the thread.
grayman

grayman

26.04.2015 16:18

viewer   ~0007493

Last edited: 26.04.2015 16:19

What I meant is, conceptually, if a light has this turned off so as not to affect the lightgem, wouldn't the light also be expected to not illuminate objects?

I know the code paths are different, but the object illumination path could use the same spawnarg to ignore lights in _its_ calculation.

The discussion for the thread is whether people share this view or whether they think the spawnarg should only be used by the lightgem calc.

SteveL

SteveL

26.04.2015 16:26

reporter   ~0007494

Understood. I've posted the question. I've since spotted the code you added to the LAS system (new one to me) to inhibit blend lights from affecting entity visibility, so I assume that'd be the place to put the fix.
grayman

grayman

26.04.2015 16:43

viewer   ~0007495

Yes, it would.
SteveL

SteveL

26.04.2015 16:54

reporter   ~0007496

Reopened pending outcome of forum discussion linked above.
SteveL

SteveL

27.04.2015 21:30

reporter   ~0007497

Unanimous votes in favour of consistent behaviour: either AI can see both the player and bodies using a given light, or they can see neither.

Spawnarg changed to the more generic "ai_see", which still defaults to 1.

I added a new method "IsSeenByAI()" to idLight so that the light awareness code can use the same flag that the renderer does. That'll be better for performance than checking the spawnargs every time a visibility check is done.
SteveL

SteveL

27.04.2015 22:34

reporter   ~0007498

rv 14284:
/trunk/def/misc.def

rv 6493:
/trunk/game/Light.cpp
/trunk/game/Light.h
/trunk/game/darkModLAS.cpp
grayman

grayman

26.06.2015 17:04

viewer   ~0007598

Can you add some documentation for "ai_see" to the Light wiki?

Thanks.
SteveL

SteveL

26.06.2015 19:33

reporter   ~0007599

Best place I could find was the Light Properties article http://wiki.thedarkmod.com/index.php?title=Light_Properties

I also added noFogBoundary.
grayman

grayman

26.06.2015 20:00

viewer   ~0007600

Looks good, thanx.

Issue History

Date Modified Username Field Change
01.04.2015 11:37 SteveL New Issue
01.04.2015 11:37 SteveL Status new => assigned
01.04.2015 11:37 SteveL Assigned To => SteveL
01.04.2015 11:41 SteveL Additional Information Updated
06.04.2015 15:36 SteveL Note Added: 0007479
06.04.2015 16:09 SteveL Note Added: 0007480
06.04.2015 16:11 SteveL Note Edited: 0007480
06.04.2015 16:11 SteveL Status assigned => resolved
06.04.2015 16:11 SteveL Fixed in Version => TDM 2.04
06.04.2015 16:11 SteveL Resolution open => fixed
06.04.2015 16:49 grayman Note Added: 0007482
26.04.2015 16:06 SteveL Note Added: 0007492
26.04.2015 16:18 grayman Note Added: 0007493
26.04.2015 16:19 grayman Note Edited: 0007493
26.04.2015 16:26 SteveL Note Added: 0007494
26.04.2015 16:43 grayman Note Added: 0007495
26.04.2015 16:54 SteveL Note Added: 0007496
26.04.2015 16:54 SteveL Status resolved => feedback
26.04.2015 16:54 SteveL Resolution fixed => reopened
27.04.2015 21:30 SteveL Note Added: 0007497
27.04.2015 21:30 SteveL Status feedback => assigned
27.04.2015 22:34 SteveL Note Added: 0007498
27.04.2015 22:34 SteveL Status assigned => resolved
27.04.2015 22:34 SteveL Resolution reopened => fixed
26.06.2015 17:04 grayman Note Added: 0007598
26.06.2015 19:33 SteveL Note Added: 0007599
26.06.2015 20:00 grayman Note Added: 0007600