Jump to content
The Dark Mod Forums

Recommended Posts

Posted
4 hours ago, duzenko said:

Awesome for speed?

Can we have a benchmark setup for this?

I don't argue that it would improve things, but I'm skeptical on how much it would improve

Awesome for mappers, as it will give us another avenue for controlling light count and performance.
Ill agree that its an edge case, but if we are supporting lights with models hiding or fading out a distance, street lamps for instance, wouldn't we need code to turn lights off anyhow?

Posted

Okay so Ive updated the test map to reflect this. Maybe this isn't an issue with shadow mapping, but I dont know. Dmap and then load it up

lodfade.map

 

So this is the common scenario.

A light inside a closed portal is still bleeding through the walls and shadowing the boxes on the outside of the building. Obviously if I add a door we won't have this problem, but this isn't always feasible.  In complex spaces this happens a lot. 

lodfade_example_2021-07-22_16_16_19.thumb.jpg.568bd0211edf49a2c96417bf96261fbb.jpg

Now if I could just hide that light at a certain distance I can eliminate that problem. 
lodfade_example_2021-07-22_16_16_192.thumb.jpg.bb6214dbd06835057cc1720831438beb.jpg

 

There might be other ways to fix this problem, but once again in complex spaces (which are most city missions) this happens more than you would think. Its not a systemic solution, but it could give mappers more control. 

  • Like 3
Posted
15 hours ago, kingsal said:

Okay so Ive updated the test map to reflect this. Maybe this isn't an issue with shadow mapping, but I dont know. Dmap and then load it up

lodfade.map 34.34 kB · 0 downloads

 

So this is the common scenario.

A light inside a closed portal is still bleeding through the walls and shadowing the boxes on the outside of the building. Obviously if I add a door we won't have this problem, but this isn't always feasible.  In complex spaces this happens a lot. 

lodfade_example_2021-07-22_16_16_19.thumb.jpg.568bd0211edf49a2c96417bf96261fbb.jpg

Now if I could just hide that light at a certain distance I can eliminate that problem. 
lodfade_example_2021-07-22_16_16_192.thumb.jpg.bb6214dbd06835057cc1720831438beb.jpg

 

There might be other ways to fix this problem, but once again in complex spaces (which are most city missions) this happens more than you would think. Its not a systemic solution, but it could give mappers more control. 

It's a good example, actually

I always wondered if DR allows to clip the light volume so that the light origin is not in its center?

Posted
15 hours ago, kingsal said:

Edit: Keep in mind in the top image, the light debugger is showing where the light is bleeding through so thats why you see the back wall illuminated. 

That reminds me, is there any way to get the old shadows debugger back? It was much easier to read:

Clipboard02.jpg.1fccae53eb4dd72e08a265a810caca73.jpg

Posted

@peter_spy Yeah so I had to turn off a couple things to get it to work, new front end renderer and obviously use stencil lights. You might also have disable uncapped FPS. 
 

@duzenkoNo unfortunately you cant clip light volumes in that way. You can move the volume to fit the space so it doesnt go outside the wall and then adjust the center. However, thats pretty time consuming and it  wont work for lights that spawn and attach things to their entity origin, torch flames for intance.  A lot of authors use the custom light objects that automatically def_attach lights and FX, so those rely on the center and origin being the same. 
 

it would be pretty useful if we had a kind of brush that just acted as a light clip volume that stopped the shadow rays. It would give us more explicit control for sure. 

Posted (edited)
9 minutes ago, kingsal said:

Yeah so I had to turn off a couple things to get it to work, new front end renderer and obviously use stencil lights. You might also have disable uncapped FPS. 

Hmm, I only managed to get this version to work, but it's not super useful, as it kind of extends to infinity, these should be clipped by the light radius:

buildercompound_2021-07-23_17_29_20.jpg.11e1c7e8a272f6fff26bd5ca07114589.jpg

  

9 minutes ago, kingsal said:

No unfortunately you cant clip light volumes in that way.

I think this could be done by using spot lights, not sure if that's what Duzenko meant. But that's a common gamedev trick too, using spotlights to avoid hitting too many surfaces by a shadowcasting light.

Edited by peter_spy
Posted
5 minutes ago, peter_spy said:

I think this could be done by using spot lights, not sure if that's what Duzenko meant. But that's a common gamedev trick too, using spotlights to avoid hitting too many surfaces by a shadowcasting light.

Yeah you might be able to use a spot light, but that wont work for most of our custom light entities which use volume lights. 
 

There are definitely ways around this problem. My point it is they are fiddly and time consuming and in some cases require specific engine knowledge. It might be easier for a mapper to just hide that light at a distance or yeah draw some kind of clipping volume. 

Posted

Also we should probably discuss light clipping and lighting techniques in a different thread as that's own can of worms.

@duzenkoSo for the hide_distance stuff it looks like these things would be helpful to add to the list:

  • Func_rotating and other movers?
  • SEED (more so investigate why they aren't working properly)
  • Lights, specifically entities that spawn lights and FX.

If we can get a gentle fade out / in on all those things that would be incredible. Basically we'd have an industry standard system. I can see lots of cases where gradually dropping out lights and objects at distance will significantly help performance on larger maps or outdoor areas. Also being able to fade out FX when you get close to them is valuable for stuff like fog. This helps prevent "washing out" the screen when you get close to an emitter. 
 

 

  • Like 1
Posted
18 minutes ago, kingsal said:

Basically we'd have an industry standard system.

Hmm, I wonder what would that be, since e.g. both Unreal and Unity have LOD systems, and even some pretty fancy fade in/out editing tools (see: https://docs.unity3d.com/Manual/class-LODGroup.html), but none of them have anything like that specifically for lights.

Posted
21 minutes ago, peter_spy said:

Hmm, I wonder what would that be, since e.g. both Unreal and Unity have LOD systems, and even some pretty fancy fade in/out editing tools (see: https://docs.unity3d.com/Manual/class-LODGroup.html), but none of them have anything like that specifically for lights.

Yeah its possible that lights are harder to do, but maybe more feasible in a dynamic-only light engine like doom 3.

Posted

The thing is, both Unity and Unreal offer both types of renderers (forward and deffered) and all types of lights now. You can use baked lightmaps and dynamic lights, both stationary and moveable, just like in idtech4. But LOD systems are still at geometry level.

I get that this idea sounds great on paper. Technically, you could turn off all the shadowcasting lights and reduce your shadow tris to 0, and overall tris count by 1/4th, or 1/3rd even. But I'd hazard a guess that this is nearly impossible to do without the level looking awful. I'd be curious to see a practical example proving me wrong though.

Posted
2 hours ago, peter_spy said:

I get that this idea sounds great on paper. Technically, you could turn off all the shadowcasting lights and reduce your shadow tris to 0, and overall tris count by 1/4th, or 1/3rd even. But I'd hazard a guess that this is nearly impossible to do without the level looking awful. I'd be curious to see a practical example proving me wrong though.

Got it. Regardless we should be able to get light models to hide if not the lights themselves.

  • Like 2
Posted

Out of curiosity, did a small experiment with awfully unoptimised nature models in a huge room 4096x4096, and with proper hide distance, lod fade and fog values you can have many lights and still manage performance. This is a top down view:

01.thumb.jpg.cd8a7f4e48e9a81a44ff10894e288bab.jpg

Again, these models are horribly unoptimised, but even with these dreadful stats the game was able to hold 60fps on the gtx 1060:

02.jpg.7a5ea58f9242f744d3c855b191f7c3fe.jpg

Posted
2 hours ago, duzenko said:

Fixed hide_distance for light entities in svn rev 9492

@stgatilov You might want to review this change

That's such amazing news! So light sources will hide with distance as well now and no longer be active? And does it interfere with triggering lights on and off? Just making sure I asked.

I'm on the latest dev snapshot and the FM I'm working on already uses hide_distance on small lights: Will update once a new dev version is out and see if this works. Thank you very much for the fix, that's much appreciated ^_^

Posted
54 minutes ago, MirceaKitsune said:

That's such amazing news! So light sources will hide with distance as well now and no longer be active? And does it interfere with triggering lights on and off? Just making sure I asked.

I'm on the latest dev snapshot and the FM I'm working on already uses hide_distance on small lights: Will update once a new dev version is out and see if this works. Thank you very much for the fix, that's much appreciated ^_^

Only the entities affected

I.e. the light will still shine, just its entity (e.g. the lamppost) will be hidden

I'm not keen to  mess with the lights themselves

I think it won't hurt to leave the light interacting with a nearby wall - that's just two triangles to draw

  • Like 1
Posted
6 hours ago, duzenko said:

Fixed hide_distance for light entities in svn rev 9492

@stgatilov You might want to review this change

Hey, I really like it! 😉

I looked what's the actual difference, and it seems to be only LOD processing and some hacky decal stuff... which probably should never happen for lights anyway.

Still, I suggest to test the game thoroughly and keep attention to lights behavior 🤔

Posted
28 minutes ago, stgatilov said:

Hey, I really like it! 😉

I looked what's the actual difference, and it seems to be only LOD processing and some hacky decal stuff... which probably should never happen for lights anyway.

Still, I suggest to test the game thoroughly and keep attention to lights behavior 🤔

This entire charade with idEntity subclasses does not make sense to me. idEmitter, idLight, maybe more classes don't call the super's overridden Think(). We got a mess of copy-pasted poorly maintained Think's scattered across the code.

As matter of fact, it's not impossible for a idLight entity to have some decals on it, unless I'm missing something

Posted

https://youtu.be/hDZSD5XbiN8

That's still 2.08, by the way, and it was recorded @1440p. But yeah, that would confirm my suspicions, other engines don't do LODs for lights because there's no need to. Those ridiculously bad models could be replaced with optimized ones and with more geometrical variety, plus other effects needed to make an FM look complete. Open areas are already possible in this engine, it's a matter of level design and game art tricks :)

Posted
8 hours ago, duzenko said:

This entire charade with idEntity subclasses does not make sense to me. idEmitter, idLight, maybe more classes don't call the super's overridden Think(). We got a mess of copy-pasted poorly maintained Think's scattered across the code.

As matter of fact, it's not impossible for a idLight entity to have some decals on it, unless I'm missing something

I think that's the reason why Entity-Component-System architecture became a popular replacement for object-oriented approach with inheritances.

Posted
10 hours ago, stgatilov said:

I think that's the reason why Entity-Component-System architecture became a popular replacement for object-oriented approach with inheritances.

Personally I love the way idTech 4 defines entities and its inheritance system. Of course this doesn't mean better isn't possible. And when I say that I refer to the way it works at the surface for a mapper, where for example if you want your own type of light you can simply inherit the base light entity and modify just the parameters you need in your own, very easy and efficient. When it comes to the base entities at the core of the engine, I don't know how they're coded and that might indeed be messy.

This brings me to a little question I had: Is the basic dist_check_period / hide_distance mechanism coded in the engine or is it a script? Asking since if no one's planning to tackle hide_distance for light sources by default, I'm thinking of creating my own branch of atdm:light_base with a scriptobject to implement fading and performance optimizations. This wouldn't be as clean but the script system should be flexible enough to allow it.

Guest
This topic is now closed to further replies.

  • Recent Status Updates

    • JackFarmer

      "The Year of the Rat." 
      😄

      Al Stewart must be proud of you!
      Happy testing!
      @MirceaKitsune
      · 1 reply
    • datiswous

      I posted about it before, but I think the default tdm logo video looks outdated. For a (i.m.o.) better looking version, you can download the pk4 attached to this post and plonk it in your tdm root folder. Every mission that starts with the tdm logo then starts with the better looking one. Try for example mission COS1 Pearls and Swine.
      tdm_logo_video.pk4
      · 2 replies
    • JackFarmer

      Kill the bots! (see the "Who is online" bar)
      · 3 replies
    • STiFU

      I finished DOOM - The Dark Ages the other day. It is a decent shooter, but not as great as its predecessors, especially because of the soundtrack.
      · 5 replies
    • JackFarmer

      What do you know about a 40 degree day?
      @demagogue
      · 4 replies
×
×
  • Create New...