Jump to content
The Dark Mod Forums

MirceaKitsune

Recommended Posts

I recently saw a post about the functionality of the idTech 6 engine, which brought this suggestion to my attention. It's actually a simple and trivial improvement, although I can imagine people missing it and not thinking about its absence. Also keep in mind I don't know the lighting code of TDM, and everything I say is purely out of observation.

 

Like most engines that use dynamic lighting, TDM tends to have considerable performance issues when a lot of lights are rendered at once. This is often because of shadows and possibly other calculations. A common way to prevent extra computation in the renderer is caching all lights, and only updating each one when necessary. Meaning either the light itself has moved, or something is moving in front of the light. If both the light and the geometry it affects are static, there is nothing to recalculate, which offers a significant performance boost.

 

TDM has a serious problem here: Even if the engine already knows how to cache lights, every torch has a moving light source! If you look closely at a torch, you'll notice its shadows constantly bob around. While this makes sense aesthetically, it also means that light will be recalculated each frame... even if the torch is mounted on a wall and no physical object or NPC is currently moving within its radius. Since most maps use torches and have areas where characters don't walk in front of them, I see a notable performance improvement being lost here.

 

My personal suggestion: First of all, does idTech 4 support light caching for static lights + geometry to begin with? If somehow the original engine didn't have that, I definitely think it should be patched in! Once that's solved, I believe moving light sources for flame based lights should be controlled by a cvar; If people are okay with the performance loss, they can enable that to get bobbing shadows... if not, disable to allow torch lights to be cached and improve overall FPS.

 

An idea to compensate for the visual loss: Can't we use an animated light texture to simulate moving flames altogether, as well as pulsating brightness? The light bobbing looks pretty extreme anyway: In real life, candles have a smooth flame that casts a neat shadow, and shadows don't always move that chaotically even when it's a noisier flame like a campfire.

Edited by MirceaKitsune
Link to comment
Share on other sites

light_torchflame_new01 actually has the note 'Light is steady for performance reasons' in its description. Presumably MirceaKitsune has in mind light sources like light_fireflames which have spawnargs related to oscillation (of the light centre, I think).

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to comment
Share on other sites

light_torchflame_new01 actually has the note 'Light is steady for performance reasons' in its description. Presumably MirceaKitsune has in mind light sources like light_fireflames which have spawnargs related to oscillation (of the light centre, I think).

 

I didn't check the names specifically, but I am indeed referring to that oscillation. It's a nice effect, but if the light's origin moves all the time you can't make use of this important optimization.

 

As far as I know, this is already done at dmap time, static lights are optimized.

Moveable light sources are the real killer.

 

Couldn't movable light sources be cached in realtime somehow? As long as a candle is sitting still on a table, and of course nothing within the light's radius animates, this should theoretically be possible! Same for dropped torches (that have stopped rolling around) and even the player's lantern (as long as they're standing perfectly still).

 

But this might be less of a problem for starters, since most maps don't have a lot of movable lights from what I've seen (like candles). Most lights are torches mounted on walls, and not the type guards can pick up and run around with. If even those could be cached, the performance improvements might be huge! I assume what you mentioned only works for classic light entities though, not lights that are part of any entity definition (which would include all types of torches).

Link to comment
Share on other sites

The oscillation technique was added by us so mappers could use them in specific situations where they wanted some added realism, but not for use all the time.

 

The problem is that as far as I'm aware, it's used by all of the torch entities. Radiant encourages mappers to go ahead and place those all the time, since they're the easiest solution... I attempted to make a map some time ago, and they were definitely the first and only option that jumped to my attention! So ultimately, maps end up using oscillating lights everywhere.

 

There might be a better solution however: Oscillation could be distance based instead. This could rely on a multiplier, ideally cvar controlled... which let's say is 1.0 when the player is 5 meters away or closer, 0.5 when they're 7.5 meters away, 0.0 when 10 meters away or farther. This gradually decreases oscillation, then makes sure that lights farther than 10 meters disable it entirely and can make use of caching! At that distance you probably don't notice it anyway, so this would maintain the effect while improving performance for large maps. Perhaps this solution is more worth considering?

Link to comment
Share on other sites

 

The problem is that as far as I'm aware, it's used by all of the torch entities.

light_torchflame has 'Light pulses but is static' in its description. Any torch that uses it (atdm:torch_gothic02_wall was the class I looked at) should be oscillation-free.

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to comment
Share on other sites

light_torchflame has 'Light pulses but is static' in its description. Any torch that uses it (atdm:torch_gothic02_wall was the class I looked at) should be oscillation-free.

 

Ah... I see. I didn't know of this difference until today... I'd imagine many mappers wouldn't either until being around for long enough. Maybe having a clearer distinction between the two can help, so mappers are aware and can be encouraged to use non-oscillating lights in most cases? I'm still curious about a few things however:

 

- Was light caching tested and working for torch entities that don't use oscillating lights, as well as electrical lamps? Or does it only work for the classic light entities, which there's pretty much no point to using in TDM nowadays?

 

- Would it be possible to cache movable light sources as well (like candles) as long as they aren't being moved? Since they can be repositioned by the player, I imagine dmap can't handle this kind of caching.

 

- What do the devs think about my LOD idea for oscillating lights? Could the effect be distance based, so even lights that use it can have a lighter performance decrease on larger maps?

Edited by MirceaKitsune
Link to comment
Share on other sites

Regarding the use of oscillating lights I would suggest a small addendum to the description in DR: Currently, it is described as ""Creates moving shadows". Maybe, we could add a "Too many moving shadows might affect perfomance" or something like that. This way mappers would at least know, that the moving shadows may be bad for performance, even though they look more realistic.

Link to comment
Share on other sites

Regarding the use of oscillating lights I would suggest a small addendum to the description in DR: Currently, it is described as ""Creates moving shadows". Maybe, we could add a "Too many moving shadows might affect perfomance" or something like that. This way mappers would at least know, that the moving shadows may be bad for performance, even though they look more realistic.

 

I'd advice a honest but technically understandable term for everyone in their descriptions. Something like: "Notice: Oscillating lights can't make use of light caching, and are more performance intensive than static lights".

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...