Player flashlight or env_projectedtexture isn't clipped (r_flashlightscissor is broken)

[ghost]

The env_projectedtexture isn't clipped and therefore casts a much bigger shadow map.

I've compared against a few source games, and the result is, something in Garry's Mod changed.

Garry's Mod

with r_shadowwireframe 1

Counter-Strike: Source

with r_shadowwireframe 1

Half-Life 2: Episode 2

with r_shadowwireframe 1

Edit: It looks like r_flashlightscissor is broken in Garry's Mod. It's also default to 0 in Garry's Mod as well, when it is fixed, please make it default to 1. Tested on the prerelease branch, in case that matters.

[robotboy655]

This is disabled in GMod intentionally, though I do not know why.

[ghost]

iirc, last time something involved the flashlight being changed was to fix this other issue, https://github.com/Facepunch/garrysmod-issues/issues/141

https://steamcommunity.com/games/garrysmod/announcements/detail/1495501079426666007

[robotboy655]

No, that's different.

[ghost]

This is disabled in GMod intentionally, though I do not know why.

Is there even a good reason why someone would intentionally disable this?

[ghost]

I would like to see this enabled, because the performance loss from overdrawing is not worth it.

[robotboy655]

I have just tested and there's no noticeable performance difference with it enabled and disabled, with like 50 env_projectedtextures. In fact its a tiniest bit faster without it.

It also causes visual artifacts on the view model of the physgun/gravity gun:

[ghost]

The performance loss from an env_projectedtexture is entirely scene dependant. Flashlight models, flashlight shadows, shadow rendering, brush model rendering should always see some cost.

How complex world geometry is, will also affect the cost.

https://steamcommunity.com/sharedfiles/filedetails/?id=620613205 As an example, this map in particular has real fps issues whenever a projected texture is used, the brush model windows spike up a lot in shadow rendering and brush model rendering. Place a projected texture to cast itself upon the brush model windows.

The fact that env_projectedtexture is not cut, ensures performance will always be lost more than it should be, the clipping issue should be resolved, rather than outright disabling it.

I hope you reconsider.

[ghost]

Fixing cuts in projected texture - this doesn't really "fix" anything, it just disables r_flashlightscissor.

[Kefta]

Even if r_flashlightscissor is not re-enabled, the projected texture incorrect cutoff is a bug of its own noticeable on some brush contacts. Maybe that should be moved to an issue of its own so those fixes can be implemented?

[ghost]

I wasn't aware of that being a separate issue, but what ever the case, would it be a viable solution to "update" the projected texture with what ever is available from source sdk 2013?

I'm just presuming the one in Garry's Mod must be based on an earlier version.

[Kefta]

Jk I misunderstood the page, was thinking of a clipping bug fixed in https://github.com/ValveSoftware/source-sdk-2013/pull/336/files

[ghost]

That screenshot from Robotboy655 looks like r_flashlightscissor is cutting the flashlight at the wrong position, which in his case is at the view model position.

Edit: actually, the issue isn't with r_flashlightscissor at all. The issue is actually with the flashlight casting light on the view models, which doesn't work well with r_flashlightscissor.

r_flashlightscissor, was wrongly blamed for the issue, and whoever disabled it in Garry's Mod, didn't know or care about the repercussions.

I've re-checked the Half-Life 2 games, and Garry's Mod to confirm my findings. The Half-Life 2 games do not have the flashlight casted on the view models, only Garry's Mod does it.

ep2_outland_01a

Garry's Mod

Half-Life 2: Episode 2

Since Garry's Mod has an increased flashlight fov (default 45 in other games), I took another screenshot in episode 2.

r_flashlightfov 60

[ghost]

Do you think you could remove the "wont fix" label and reconsider fixing it?

[Raox2]

Engine performance fixes are definitely worth looking at.

[Kefta]

The issue is actually with the flashlight casting light on the view models, which doesn't work well with r_flashlightscissor.

Which works fine without r_flashlightscissor. Sounds like the actual issue is how it clips on viewmodels, which is probably why Valve didn't have viewmodel lighting enabled in the first place. Should probably just leave it disabled until it's fixed, if ever.

[ghost]

This could also help, https://github.com/Facepunch/garrysmod-requests/issues/874

Along with enabling r_flashlightscissor and disabling shadow receiving on view model.

[ghost]

zs_last_stand_mall_v5a

345 fps

164 fps with flashlight on

I have gmod_mcore_test 1 enabled, Nvidia GTX 1080Ti, and i7 8700K. If I am losing that much fps to a single flashlight in a complex scene, how's it going to affect those with lower hardware?

---

Lets say I'm one of those unfortunate, who's unable to make use of multi-core rendering, here's the result:

95 fps with gmod_mcore_test 0

---

r_flashlightdrawfrustumbbox 1, r_shadowwireframe 1, and r_flashlightlockposition 1.

The flashlight frustum box is excessively large, and this in turn produces over-sized map shadows from it's contact points on the world.

This is what the flashlight does at that position in my previous images.

For some reason this map shadow consumes the entire snow area.

---

I can't just do, r_drawtranslucentworld 0 to disable rendering those complex windows as it's a cheat cvar, and it wouldn't solve the issues originating from the flashlight itself.

---

I attempted to do it with 50 projected textures, which grinded the game to 3 fps, taking a screenshot crashed the game.

[robotboy655]

It has no effect. Same map, same spot:

r_flashlightclip 0;r_flashlightscissor 0

r_flashlightclip 1;r_flashlightscissor 1

[robotboy655]

I also noticed this bug with 2 lamps with different FOV:

[ghost]

That is really disappointing to hear, thanks for testing it out.

[robotboy655]

Maybe I am missing something, but I do think I have restored every single disabled bit of it.

[ghost]

In your screenshots, it does look like something is wrong.

r_flashlightscissor 1 is clearly cutting the map shadow, but the cost to fps remains the same, it's acting as though it isn't cut.

[robotboy655]

You can create a test map and test it in hl2 vs gmod.

[ghost]

Alright, I can confirm without a doubt that I was wrong the entire time. I tested on Counter-Strike: Source (create_flashlight) and Garry's Mod and can conclude this issue.

---

Counter-Strike: Source

mat_queue_mode 2, r_flashlightscissor 1

mat_queue_mode 2, r_flashlightscissor 0

mat_queue_mode 0, r_flashlightscissor 1 mat_queue_mode 0, r_flashlightscissor 0

r_flashlightscissor doesn't actually do anything beneficial, and Shadow Rendering is indeed the tiniest bit faster with it disabled, the difference is negligible.

I suppose the issue is the flashlight is inherently an unoptimized part of the source engine, so I'll accept that, thanks for your assistance regarding this matter, and sorry for wasting your time.

[ghost]

Could disable receiving shadows on translucent world be a solution to one of the problems?

Edit: Black Mesa has a flashlight which doesn't impact fps at all, would be great if that could be obtained somehow.

[Kefta]

I'm pretty sure they also use a clipped projected texture, which leads to similar bugs; https://www.youtube.com/watch?v=7sWQ7xZR4zo

[ghost]

I can't replicate that issue, I'm going to assume they must've fixed it ages ago.