hide_distance broken again?

[kingsal]

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?

[kingsal]

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. 

Now if I could just hide that light at a certain distance I can eliminate that problem. 

 

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. 

[kingsal]

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. 

[MirceaKitsune]

FYI: hide_distance also won't work on func_rotating entities. Just noticed as I was trying to hide a spinning gear with distance.

[duzenko]

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. 

Now if I could just hide that light at a certain distance I can eliminate that problem. 

 

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?

[peter_spy]

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:

[duzenko]

Example

I think it would be so much better for this particular light behind the wall situation

[kingsal]

@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. 

[peter_spy]

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:

  

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 July 23 by peter_spy

[kingsal]

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. 

[kingsal]

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. 
 

 

[peter_spy]

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.

[kingsal]

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.

[peter_spy]

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.

[kingsal]

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.

[duzenko]

Fixed hide_distance for light entities in svn rev 9492

@stgatilov You might want to review this change

[peter_spy]

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:

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

[MirceaKitsune]

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

[duzenko]

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

[MirceaKitsune]

Ah, I see. At least there's that feature then, I guess it helps a little. Really hoped this could be made to work for light sources themselves... if it will happen it will happen I guess, in the end I can make my map work without it too.

[stgatilov]

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

[duzenko]

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

[peter_spy]

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

[stgatilov]

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.

[MirceaKitsune]

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.