View Issue Details

IDProjectCategoryView StatusLast Update
0003744The Dark ModCodingpublic02.07.2015 20:45
ReporterSteveL Assigned ToSteveL  
Status resolvedResolutionfixed 
Product VersionTDM 2.02 
Target VersionTDM 2.03Fixed in VersionTDM 2.03 
Summary0003744: LOD making unwanted changes to shadowcasting and skin settings
DescriptionLOD overrides shadow-related spawnargs like noshadows and noshadows_lit and forces shadowcasting if the mapper has not specified any LOD shadow parameters. This makes LOD incompatible with entities that manage their own settings like combined entity lights.
Additional InformationFrom this forum discussion:

LOD is designed to manage shadowcasting for you. Whenever there's a LOD transition, the LOD code sets shadowcasting on the entity.

It's using only the lod spawnargs in that logic. There are optional LOD spawnargs for you to say whether your entity casts shadows at any given lod distance. The normal noshadows spawnargs are ignored after the first lod transition. If you haven't set any lod shadow spawnargs at all, it assumes you always want shadows.

possible fixes:
- noshadows_lit spawnarg overriding LOD logic.
- disable LOD from messing with an entity's shadowcasting settings in the first place if the mapper hasn't set any shadow-related LOD spawnargs on the entity.
TagsNo tags attached.


related to 0004170 resolved LOD still changes noshadows settings when not wanted 




05.06.2014 01:35

administrator   ~0006655

//disable LOD from messing with an entity's shadowcasting settings in the first place if the mapper hasn't set any shadow-related LOD spawnargs on the entity.//

This would be my preference. LOD should not mess with the entity unless the mapper wants to mess with it.


05.06.2014 16:21

reporter   ~0006657

Last edited: 05.06.2014 16:22

Suggested fix is to idEntity::SwitchLOD(). I've tested it briefly with a code step-through in front of a few torches with different lod shadow configs. I'll post it here for consideration later in 2.03 so I don't lose it when I next revert my test build. There are a couple of other places in that function that I want to look at too.

These 2 lines of code run for one entity at a time when a LOD switch has happened:

renderEntity.noShadow = (m_LOD->noshadowsLOD & (1 << m_LODLevel)) > 0 ? 1 : 0;
renderLight.noShadows = (m_LOD->noshadowsLOD & (1 << m_LODLevel)) > 0 ? 1 : 0;

They are the ones fiddling with the shadow settings. They should run only if the mapper has set at least one LOD-shadow spawnarg on the entity.
m_LOD->noShadowsLOD is a set of bitflags held in an int that hold the shadow spawnargs flags for each lod level. If the mapper has set any, that number will be something other than 0, so:

if (m_LOD->noshadowsLOD != 0)
  renderEntity.noShadow = (m_LOD->noshadowsLOD & (1 << m_LODLevel)) > 0 ? 1 : 0;
  renderLight.noShadows = (m_LOD->noshadowsLOD & (1 << m_LODLevel)) > 0 ? 1 : 0;



06.06.2014 00:04

administrator   ~0006658

A related issue I just noticed...when I put out the light, it switches to its unlit skin. But when I move back and then forward again, the original model swaps in with its original, lit skin. LOD should not override skin choices either unless the mapper has specifically asked it to.


06.06.2014 07:38

reporter   ~0006660

Ta. I'll go looking for that one later.


08.06.2014 10:11

reporter   ~0006661

The skin switch wants handling slightly differently. It happens just before the code quoted above. But there's no simple flag to check whether the mapper set any skin spawnargs. Instead there's a check on the current lod skin number being used, which at map start is set to level 0, meaning the skin for the fully detailed lod level. We could instead set it to -1 if the mapper hasn't specified any lod skin switches, leaving it at 0 if he or she has set some. Then when the lod switch happens, skins will only be changed if the current lod skin number is 0 or above. The current lod skin number only gets changed when the skin gets switched, so the -1 special value would never get changed. And that value isn't used by any other code.


08.06.2014 13:01

administrator   ~0006662

It's actually a bit more complicated. The issue here is that the light script changes the skin depending on whether the light is on or off. The LOD solution would need to maintain that switch--and at each stage of LOD distance.

For example, imagine a high-poly electric lamp model using LOD. The player walks away from the lit model and the low-poly swaps in--that low poly needs to use the lit skin. Then he walks up to the lamp and turns it off, switching the skin to "unlit". Then he backs away again--the low-poly now needs to use the "unlit" skin as well.

Your solution sounds like it would handle the original problem of the "unlit" skin on the high-poly model getting switched, but would it solve the above?


08.06.2014 17:03

reporter   ~0006663

Ah. Yes, that's a bit different. It might work or might not, depending whether the custom skin that's been set by the light script carries over through the model switch, or whether the newly attached model imposes its default skin. The model-changing code doesn't *seem* to touch the custom skin property, so it might work as it is. I'll test it.

Are entity lights the only entities that have two distinct states for skin and model, lit vs unlit? Or are there other types of entity that have two states like that?


08.06.2014 18:02

reporter   ~0006664

It works. The custom skin set by the light script is retained through lod transitions. Tested on your new brazier. I'll have to test again on something that does have lod skins set to make sure I haven't broken it at the other end of course, but it looks like good news.


08.06.2014 20:01

developer   ~0006665

Last edited: 08.06.2014 20:02

The consequence of your result is that the lit state disables LOD transitions unless you define lit\unlit skins for each LOD stage. (Unless I am misunderstanding some aspect of your test)



08.06.2014 20:22

administrator   ~0006666

Lights are the only entities I can think of that do skin switching.


08.06.2014 21:07

reporter   ~0006667

@nbohr1more: not sure I understood you right, but with this fix the model will still change with LOD, just not the skin and shadow, unless the mapper wants LOD to manage those things.

The fix I'm proposing is: for both shadows and skins, LOD is disabled only when the mapper hasn't set any LOD spawnargs at all for that category. If the mapper defines a single LOD skin for any level, lod will set the skin for every level. Likewise with shadows: if the mapper sets a single lod_noshadows spawnarg, then LOD will continue to force shadowcasting at every other level. Currently, there's no way to stop LOD resetting shadows and skins for every entity it manages at every single transition, so LOD is incompatible with entities that manage their own shadowcasting and skins like entity lights.


05.07.2014 17:37

reporter   ~0006699

Committed at rev 6050: Special value of -1 for skin lod level plus conditional shadow twiddling.

Issue History

Date Modified Username Field Change
04.06.2014 21:46 SteveL New Issue
04.06.2014 21:46 SteveL Status new => assigned
04.06.2014 21:46 SteveL Assigned To => SteveL
04.06.2014 21:47 SteveL Assigned To SteveL =>
04.06.2014 21:47 SteveL Assigned To => SteveL
04.06.2014 21:47 SteveL Status assigned => new
04.06.2014 21:47 SteveL Assigned To SteveL =>
04.06.2014 22:00 SteveL Assigned To => SteveL
04.06.2014 22:00 SteveL Status new => assigned
05.06.2014 01:35 Springheel Note Added: 0006655
05.06.2014 16:21 SteveL Note Added: 0006657
05.06.2014 16:22 SteveL Note Edited: 0006657
06.06.2014 00:04 Springheel Note Added: 0006658
06.06.2014 07:38 SteveL Note Added: 0006660
08.06.2014 10:11 SteveL Note Added: 0006661
08.06.2014 13:01 Springheel Note Added: 0006662
08.06.2014 17:03 SteveL Note Added: 0006663
08.06.2014 18:02 SteveL Note Added: 0006664
08.06.2014 20:01 nbohr1more Note Added: 0006665
08.06.2014 20:02 nbohr1more Note Edited: 0006665
08.06.2014 20:22 Springheel Note Added: 0006666
08.06.2014 21:07 SteveL Note Added: 0006667
19.06.2014 10:03 SteveL Summary LOD making unwanted changes to shadowcasting settings => LOD making unwanted changes to shadowcasting and skin settings
19.06.2014 10:03 SteveL Description Updated
05.07.2014 17:37 SteveL Note Added: 0006699
05.07.2014 17:37 SteveL Status assigned => resolved
05.07.2014 17:37 SteveL Fixed in Version => TDM 2.03
05.07.2014 17:37 SteveL Resolution open => fixed
02.07.2015 20:45 SteveL Relationship added related to 0004170