 |
//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. |
 |
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; } |
|
|
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. |
|
|
Ta. I'll go looking for that one later. |
|
|
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. |
|
|
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? |
|
|
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? |
|
|
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. |
 |
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) |
|
|
Lights are the only entities I can think of that do skin switching. |
|
|
@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. |
|
|
Committed at rev 6050: Special value of -1 for skin lod level plus conditional shadow twiddling. |
- Anonymous
