hide_distance broken again?

[peter_spy]

1 hour ago, HMart said:

The only "fade" I could easily do, was the normal monster burn effect used on Doom 3, but is bad for LODing and like I said uses alpha testing, not alpha fading.

Not sure why it would be bad for LODing, it kinda depends on what you put in the alpha channel of the texture. It can look a bit like the reverse monster fade out in Doom3, and from a proper distance it looks good; it beats an object popping in and out of a thin air.

[HMart]

59 minutes ago, peter_spy said:

Not sure why it would be bad for LODing, it kinda depends on what you put in the alpha channel of the texture. It can look a bit like the reverse monster fade out in Doom3, and from a proper distance it looks good; it beats an object popping in and out of a thin air.

You are right, the doom 3 like effect I used was bad for LODing but I concede that I may just have done a bad job, I tried some other alpha textures but it just looked strange and not a smooth transition like I wanted, so I gave up.  Others may make it look and work well anyone is free to try.  

[peter_spy]

 

[HMart]

That looks very good, like I said, I did a bad job and that proves it. 

[peter_spy]

Sorry I didn't prepare a test map, just grabbed what I had from my stuff, as I don't want to be distracted much from the level design exercises I'm doing right now.

But you can imagine this being applied to stuff like distant trees or grass, or perhaps even buildings (you could couple that with some distance fog, etc.). In general it should be pretty versatile and work with almost every object.

Edited July 17, 2021 by peter_spy

[kingsal]

@HMartFade in/ out is possible in TDM, see the test map below. The glow and grass textured planes will fade in and out.

@duzenko @stgatilov Pasting from discord:

Here is the test map I put together based on an old one Peter_spy had: lodfade_example.pk4

Couple bugs I noticed right off the bat:

• Light entities will not hide
• Strangely the SEED entity hides different func_static children at different distance even though they are set the same
• Any hide or LOD setting on SEEDs don't seem to propagate to their children. Didnt thoroughly test this though
• Fade only works with those specific materials in the material folder.

Lod_fadeout_range controls the fade distance. This is absolute from the origin of the object and needs to be higher than the hide_distance. So its starts fading at the hide distance. Im not sure why its called lod_fadeout_range, maybe it fades after the last LOD stage? Im not sure but we'll need to investigate this. I assume if no LOD is set it just starts from the hide_distance.

[HMart]

I see no fade in/out, in that test map the entities just blink out of existence do I have to turn something on? 

edit: ho I see it now, is obviously not alpha blending but alpha testing, like used on the Doom 3 monsters and peter_spy example, but works fine. I will need to try harder it seems. 

Edited July 17, 2021 by HMart

[kingsal]

55 minutes ago, HMart said:

edit: ho I see it now, is obviously not alpha blending but alpha testing, like used on the Doom 3 monsters and peter_spy example, but works fine. I will need to try harder it seems. 

The particle on the right alpha blends I believe. 

[peter_spy]

Also, if you use shadows with stencil, these will pop in and out at fade distance; only maps with fade in and out smoothly with the model (which kinda makes sense).

According to my notes, stuff like lod_x models should work correctly, but things will get wonky when it comes to skins for different lods. It seems like the model will always switch to lod_0 skin when going between hide_distance and lod fadeout range.

[duzenko]

The emitter entities being the focus of my effort right now, I can see that then emitter itself gets 'hidden' properly

The next stop is where its surfaces are emitted by the frontend

EDIT

The render entity is removed, but instantly re-added from idFuncEmitter::Present. I'm not sure if we need to check for visibility in this code, or it's better done in some other place. E.g. if the emitter should be rather inactivated, etc.

[duzenko]

Emitters seemingly fixed

At revision: 9479

[MirceaKitsune]

https://bugs.thedarkmod.com/view.php?id=5668

Is there no chance that we could get hide_distance working for lights as well? My FM's have a slightly more open design which I didn't wish to sacrifice, and to keep performance okay I need to use hide_distance on some meshes with many func_portal ents to close all doors and windows at a distance. This still doesn't help enough, which is why I preemptively set a hiding distance on small lights too in case we're lucky and this will be fixed.

I don't know the code but lights can already be turned on / off by triggers. Is there no easy way for the engine to use the same system to disable a light source based on distance, same way it disables rendering a mesh? I hope this can be looked into in some form.

[duzenko]

49 minutes ago, MirceaKitsune said:

https://bugs.thedarkmod.com/view.php?id=5668

Is there no chance that we could get hide_distance working for lights as well? My FM's have a slightly more open design which I didn't wish to sacrifice, and to keep performance okay I need to use hide_distance on some meshes with many func_portal ents to close all doors and windows at a distance. This still doesn't help enough, which is why I preemptively set a hiding distance on small lights too in case we're lucky and this will be fixed.

I don't know the code but lights can already be turned on / off by triggers. Is there no easy way for the engine to use the same system to disable a light source based on distance, same way it disables rendering a mesh? I hope this can be looked into in some form.

Lights don't draw anything by themselves

If there's an entity touching the light it will still emit all its surfaces for e.g. depth pass, ambient pass, etc

I understand your idea but IMHO hiding entities (or replacing them with billboards) is more beneficial overall

You would have to produce a test map where distant lights is a major performance problem for me to investigate this any further

[peter_spy]

That plus you can reduce distant shadowcasting by using as many "noshadows_lod_x  1" as you want. That should help quite substantially, since lights that cast no shadows are much cheaper in terms of performance. It's just that in this case you can achieve this by turning off shadows on the models, not in the light entity. Bear in mind that none of the optimisation tricks will help you much, if you have dozens of overlapping lights hitting tons of objects. That would be just using lights in incorrect way.

[nbohr1more]

We have seen a few mappers optimize lighting performance by creating distance triggers to toggle them off.

One thing that legitimately begs for this capability is in the case where light bounding boxes expand beyond

the visleaf they are assigned to but do not contribute to lighting in the unintended area.

Though this is what the areaLocked keyword is for?

 

Using hide_distance would make this easier than the triggers or scripts currently used for this at least.

I think the general objection to this is that mappers could easily make ugly light toggling in the distance.

 

I believe Tels made a demo where he faded lights in\out based on distance and this would also look better than a hide_distance option.

His design shrunk the light volume to zero after fading the projection image colors as I recall.

[kingsal]

Being able to hide lights at a distance would be helpful actually. Better  yet being able to fade them out gently would be awesome. 
 

There are cases where lights bleed through walls and being able to just turn them off with a distance check would be a very quick and easy way to prevent  that. Controlling that with scripts is a mess, imo.

[MirceaKitsune]

Agreed. It's funny that when bringing up hide_distance for lights I'm asked why would that improve performance. Lights that cast shadows are one of the biggest performance consumers, sometimes more so than mere meshes in an unlit area. And you don't need to have a dozen lights touching the same spot, obviously I know better than that as a mapper: Even one medium range light, such as an electric lamp, can seemingly double the triangle count (per total drawcalls) if it hits too many meshes in its vicinity.

Especially for someone like me who does more open city designs (not that open but not deliberately cramped either) which aren't possible to portal at maximum efficiency everywhere, this could make a huge difference and let them run a lot more smoothly. So much so that I kind of want to delay releasing my new FM until this limitation is lifted... I won't be releasing it before 2.10 anyway, hence why I'm hoping we can get this one fix to enable hide_distance for light ents before it.

Like I said I don't know the code, but do know lights can be turned on and off by triggers; Would it take more than a few lines of code to check the distance between the view and light origin and turn rendering the light off? This could probably be done even from a script by modifying the definition of the base light entity, though doing it in the engine might be more efficient. Sadly I don't know that code myself nor have a development setup of TDM ready nor the time for this (working on other goodies I'll share soon).

[peter_spy]

That's why you can have a noshadows lod, and also you can hide models being hit by these lights. As Duzenko wrote, lights are expensive only when they hit something expensive. In that regard your performance won't get magically improved just because you turn off the lights.

[MirceaKitsune]

49 minutes ago, peter_spy said:

That's why you can have a noshadows lod, and also you can hide models being hit by these lights. As Duzenko wrote, lights are expensive only when they hit something expensive. In that regard your performance won't get magically improved just because you turn off the lights.

I see you point, but there are two issues with that. First the mapper has to add hide_distance and / or lod_noshadows to every model in the radius of the light which is tedious... imagine if you inserted a prefab with items of different sizes, you don't want the whole thing disappearing in the same spot. Which leads to the second issue: If the model is large you don't want it disappearing because it would be too obvious... the light fading away could be more subtle and acceptable than the model or its shadows doing so.

[peter_spy]

If a model is large and unoptimized, it will still be drawn, even if there's no light. So it's not that much of a performance, but aesthetics-related thing now, and that is subjective. I'd hazard a guess that changing lighting conditions like that will look more jarring than a switching between model visibility or lod stages in the same lighting.

[MirceaKitsune]

55 minutes ago, peter_spy said:

If a model is large and unoptimized, it will still be drawn, even if there's no light. So it's not that much of a performance, but aesthetics-related thing now, and that is subjective. I'd hazard a guess that changing lighting conditions like that will look more jarring than a switching between model visibility or lod stages in the same lighting.

Yes, but it might be drawn in an area where only the ambient light hits it. A high-poly model becomes even more expensive for each light that has to calculate its faces, in addition to the normal calculation used to draw it. Just learned this better myself during recent discussion on the matter.

[peter_spy]

1 hour ago, MirceaKitsune said:

Yes, but it might be drawn in an area where only the ambient light hits it.

That ambient light would already act like tris multiplier. See the comparison I made in the newbie thread again. Even in complete darkness, the tris are still drawn. That's why it's better to address this at model level. 

[MirceaKitsune]

22 minutes ago, peter_spy said:

That ambient light would already act like tris multiplier. See the comparison I made in the newbie thread again. Even in complete darkness, the tris are still drawn. That's why it's better to address this at model level. 

Sure, but they're drawn less is the point. The ambient light is universal and unavoidable on a map, though optimized specifically to improve performance from what I remember reading. Any light added too close can make a model twice more costly than it sitting in total darkness already was.

[duzenko]

12 hours ago, kingsal said:

Being able to hide lights at a distance would be helpful actually. Better  yet being able to fade them out gently would be awesome. 
 

There are cases where lights bleed through walls and being able to just turn them off with a distance check would be a very quick and easy way to prevent  that. Controlling that with scripts is a mess, imo.

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

[peter_spy]

3 hours ago, MirceaKitsune said:

Sure, but they're drawn less is the point. The ambient light is universal and unavoidable on a map, though optimized specifically to improve performance from what I remember reading. Any light added too close can make a model twice more costly than it sitting in total darkness already was.

Ambient light does that already too, as I demonstrated earlier. You have to account for the initial tris count to be at least tripled when you're placing a model in a map (ambient world + regular light, or + distance fog, so quadrupled even). If you're using lods/hide distance for models and func portals, and still can't get decent performance, you either need to up your level design game, or find better models (or both). Just hiding lights won't save you.

It can be fun gameplay or aesthetic trick though, I guess it will be easier to use than scripts.

Edited July 22, 2021 by peter_spy