Lighting bug report

[BabaBooey88]

Hello CDPR

I will follow this thread up with a report linking to my findings here in hopes that this issue may be addressed. It's not a bug per se, I hope, but seemingly a byproduct of a system in the game I believe.

TLDR; It appears the mesh used for masking rain/adding occlusion to vehicle interiors is also masking out most of the game engine lights such as street lamps, car head lamps, and freeway lights. Never seen that before in a game like this and it's not all of the lights so it should be something addressable. Emissives aren't masked out as well as in raster they're just there in the scene and cast no lighting, as well the stree lamps being masked is present in raster - not an RT problem. It's not a problem with mods that add cars to the game either, likewise said mods don't seem to mask out rain - so there's my basic reasoning.

You can see in the following images how the light cast into the vehicle interior is suddenly masked out as I approach either vehicle. Same location, same time give/take a minute or two.




Continued..

Post automatically merged: Jul 15, 2023

Same car, different street lamps. No penetration on the first one, as expected functional lighting in the second image.



This first one is an emissive billboard, roll a few meters up the street and park beneath an actual game light - no interior penetration.

Post automatically merged: Jul 15, 2023

This isn't an exceptional issue btw; Light being blocked from vehicle interiors is the rule in this game currently. It's unfortunate as it impacts the ambience of driving around at night. I understand the game isn't a life simulator or a car themed game, but the experience of just moving through the city is second to none. It's quite rare in an open-world game that I just enjoy moving around in it; I almost never use fast travel in 2077! Having the light bounce around in the car and reflect off the windshield ( My Immersive Glass mod, btw ) would be great, as I routinely enjoy a good night drive IRL

Okay... working fine.

Testing with a prop spawned through AMM console... good

Good, this is working as well.

And suddenly not working... like most of the lights. I am directly under a street lamp.

Post automatically merged: Jul 15, 2023

And here are a handful displaying car head lamps not penetrating this apparent mask/occlusion volume

Direct and/or bounce lighting seems to reflect just fine though. I'll admit I haven't checked that as I was more struck by lights not behaving 'properly' in this setting.

 

[SigilFey]

Interesting! There's definitely something...although I'm not sure it's occlusion, directly. Looks sort of like the light source is being culled. Are you running this with ray tracing or rasterization? Or does it occur in both?

Reason: if running in rasterization mode, then there is the possibility of it being a problem with the assets being painted with the light. If running in RT, then this should not be as likely, and it's more likely a problem with the light source itself.

 

[BabaBooey88]

Interesting! There's definitely something...although I'm not sure it's occlusion, directly. Looks sort of like the light source is being culled. Are you running this with ray tracing or rasterization? Or does it occur in both?

It's both.

I thought I mentioned that in my post but it was rather late at night . The reason I mention occlusion is because there are, last I checked over two years ago, meshes setup in specific areas and cars to seemingly simulate the kind of ambient light occlusion you can't get with a raster AO pass or even Hybrid RT. These mesh properties also contribute to the extreme exposure - they're almost like a post-processing volume in UE, but I've seen a similar approach in other games. Another part of my reasoning is based on added vehicle mods lacking rain masks that allow lights to pass through whatever mesh is culling them.

Reason: if running in rasterization mode, then there is the possibility of it being a problem with the assets being painted with the light. If running in RT, then this should not be as likely, and it's more likely a problem with the light source itself.

Tried that. I thought it was the lights initially when I first noticed seeing as some work and others didn't - must be the lights; I changed the lighting channels, profile, etc for every street lamp, high way lamp, etc. Nadda. Then I remembered my old findings from the early moddind days (like January 2021) and noticed that box streaming in that obscures light as I approached the vehicle in the first set of images. Of course, it could still be the lights and I've missed something. Either way; CDPR did as well and I hope they feel apt to address it.


I also learned that RTXDI for Path Tracing is attached to LODs rather than camera render distance as well from trying to solve this.

 

[SigilFey]

In general, these wouldn't be things that you could "try". It would have to do with how the engine is culling light sources. For example, in the images where you spawn in light sources using the console, it seems that the engine culls the red light source altogether when it's no longer at an an angle that the camera wants to register.

Here's a question: if you were to stop the vehicle exactly where the red light vanished, then turn your head to look toward it...would it reappear? (Switching on and off, like you're flipping a light switch, as you turn your head toward it and away from it?)

Here's the rub: if a light source exists in a ray tracing engine, than the scattered, diffused, and reflected light on all surfaces will still exist in some form. If what you're describing happens in in RT mode, then there's probably not a problem with the occlusion -- there's a problem with the light source itself. How the engine is culling it based on camera angle and position. If it's a mesh (like an interior vs. exterior mesh for the car) then what I suggest simply won't have any effect. The light will be gone until the car itself is in an XYZ position where the game recognizes that it should be interacting with that light source. That would be a totally different sort of problem, most likely caused by how the interior of each car is coded to behave with light. (So: one would be a lighting issue, while the other would be an engine performance issue.)

I'm also deducing, here. I'm no expert on ray tracing, especially, but I think this could be an important distinction to try to clarify before sending in the bug.

 

[BabaBooey88]

In general, these wouldn't be things that you could "try". It would have to do with how the engine is culling light sources. For example, in the images where you spawn in light sources using the console, it seems that the engine culls the red light source altogether when it's no longer at an an angle that the camera wants to register.

I see what you are getting at, but the red light in that scene is positioned in a way that the bulb is not on screen but the lighting is - so culling is of no relation here. The render distance for lights it's considerable and differs based on the light type, but that matters not here as whether or not you seeing the light source isn't responsible for light being cast. When lights are culled they stop casting light onto surfaces and fx layers all together. They're gone entirely, same as buildings being culled and streamed in off screen causes shadows to pop in and out in some areas. Having lights only cast lighting when the light source itself is on screen would not look all that good from I can imagine and defeat it's purpose quite often.

Here's a question: if you were to stop the vehicle exactly where the red light vanished, then turn your head to look toward it...would it reappear? (Switching on and off, like you're flipping a light switch, as you turn your head toward it and away from it?)

Even if that were the case it would render having engine lights there almost moot, don't you think? If we're talking about distance culling then fair enough, and something of that nature may be at play but it's impact here isn't all that important. The issue is that when we're driving beneath these lights they aren't penetrating some kind of mask(s) attached to the car.

Here's the rub: if a light source exists in a ray tracing engine, than the scattered, diffused, and reflected light on all surfaces will still exist in some form. If what you're describing happens in in RT mode, then there's probably not a problem with the occlusion -- there's a problem with the light source itself. How the engine is culling it based on camera angle and position. If it's a mesh (like an interior vs. exterior mesh for the car) then what I suggest simply won't have any effect. The light will be gone until the car itself is in an XYZ position where the game recognizes that it should be interacting with that light source. That would be a totally different sort of problem, most likely caused by how the interior of each car is coded to behave with light. (So: one would be a lighting issue, while the other would be an engine performance issue.)

It meets none of the parameters used for culling nor are these lights aren't being culled as they're still casting light across the environment, they're just not penetrating the mask. This is why I made sure the first set of images covers the mask streaming in and I made mention that this issue is not present when using imported vehicle mods such as ctxrlsec's '67 Impala or KRNLNIK's Rolls Royce Wraith. Those mods are missing something vehicles in the game have, and one time when I forced rain the droplets were indeed permeating the interior of the '67 impala - that's why I draw my conclusion at the culprit being an intersection of the mask and the lights, which of those needs to be tweaked is up for investigation.

I was sure to thoroughly test across the different rendering pipelines - believe me, I really did want to solve this myself to compliment my reflection mod rather than putting my hopes on what's probably going to be viewed as boutique issue when CDPR has much bigger fish to fry. I would love to fix it and throw up a mod "look what I fixed", but it didn't happen so I want CDPR to know it's been noticed and honestly I would hope people on console could enjoy an improved night drive experience as well.

One thing I did not mention, as I only did this last night to run tests on another issue is that I loaded up a save from the get away following the heist. In those moments and noticed in the rear windshield that light was being cast into the car, but that the timing is considerably off from all the light sources in said scene - said lights also do not cast light into the vehicle from any other window nor do they at all when driving any one of V's personal vehicles later; I think CDPR ran into this issue and couldn't address it in time for release (we all understand why), thus it got pushed to the side while they dealt with more pressing matters and the lights in that getaway scene are specifically placed there for that effect. Check it out for yourself. Perhaps there was a bug and they decided to mask out lighting entirely, and the lights that are penetrating the vehicle interiors are the real issue - I hope not.

I'm also deducing, here. I'm no expert on ray tracing, especially, but I think this could be an important distinction to try to clarify before sending in the bug.

Oh, well I already did that and made sure that they're aware the issue is baseline. I should have mentioned that in my post as well, but I did specifically make note of it in the report form.

In terms of graphics visualization alone; in 2077 RT Hybrid (medium-Psycho) functions as another set of icing layers on the cake while PT is an entirely different icing that replaces what was there. Both still function at the behest of the engine though and often with the intent of being performant for the hardware available. It's why there are some places where an object that's entirely invisible to the camera may still cast a shadow with PT, or why NPC skin glows in ambient lighting with Psycho RT - the first example is an accident, the second is graphical infringement.

 

[SigilFey]

I see what you are getting at, but the red light in that scene is positioned in a way that the bulb is not on screen but the lighting is - so culling is of no relation here. The render distance for lights it's considerable and differs based on the light type, but that matters not here as whether or not you seeing the light source isn't responsible for light being cast. When lights are culled they stop casting light onto surfaces and fx layers all together. They're gone entirely, same as buildings being culled and streamed in off screen causes shadows to pop in and out in some areas. Having lights only cast lighting when the light source itself is on screen would not look all that good from I can imagine and defeat it's purpose quite often.

Even if that were the case it would render having engine lights there almost moot, don't you think? If we're talking about distance culling then fair enough, and something of that nature may be at play but it's impact here isn't all that important. The issue is that when we're driving beneath these lights they aren't penetrating some kind of mask(s) attached to the car.

Not moot at all. What you're claiming is entirely possible -- something is obviously making the light there one minute and gone the next. However, if it were the occlusion mask, then certain light sources would not illuminate the interior of the car at all. Ever. For it to be there one moment and gone the next in RT, that most likely means that something about the light source itself is the issue, rather than it being an occlusion issue. I mean, we can't be sure, but we can test to see if it pops back in based on camera facing or position.

Occlusion, like you're describing, is more about whether particles will be drawn if they detect collision with a mesh. Shadows and lighting work differently. Where I'm curious is: can RT lighting somehow have the same sort of "occlusion glitch" as rain or snow particles can often glitch in games if the player moves into or out of an occlusion area. As "rays" for ray tracing are going to wind up being treated like particles moving through 3D space in much the same way.

The caveat to all of this, though, is that it affects both the rasterized interior and the RT interior of the vehicles. That is strange, as it's the same glitch happening with two different systems. For a universal bug like that to occur, the only absolute commonality that they share is the light source itself, so it's ground for reasoning that something about the way the engine is handling the light source is the issue, rather than some sort of issue with the vehicle interior.

If you can, the next time it happens with a static light, try testing the camera angle / vehicle position using tiny adjustments to the mouselook and forward / backward position of the car.

It meets none of the parameters used for culling nor are these lights aren't being culled as they're still casting light across the environment...

That's not how it works. When you're looking, say, east in the game, the only part of the gameworld that's being drawn is what's on your screen at that moment. If I was to freeze the engine and have you look even slightly to the left or right, you would see that the world had almost completely vanished. It would be empty of all geometry and textures. So, when an item is not on camera, it's not being drawn in the world. The only things that would be are assets very close to you...like a wall you might bump into if moving backwards.

These assets are still loaded into RAM, however, and that's how the game can (in real time) go grab the assets it needs and draw them back in within milliseconds. But that doesn't necessarily mean that the all of the data for each of those objects (like collision, or textures...or light sources) are being culled efficiently.

You can often see the effect of this by slowly turning the camera in a given direction and watching the edge of the screen carefully. Things like trees and grass, especially, will often pop into and out of existence before they're fully on or off camera. The whole world is acting like that. (This is also how all 3D games work. It's one the biggest ways that devs increase performance -- cull assets more and more efficiently, freeing up more and more processing power and VRAM for the GPU.)


_______________


Post here again if you get a response to the ticket! I'm not sure that they'll say anything other than, "Ensure your drivers are up to date...[etc.]" but it will be interesting to see if there is an easy fix for it. From what I can see, I'm fairly confident it's an engine-level issue, though. Patches, patches, patches.

 

[BabaBooey88]

Not moot at all. What you're claiming is entirely possible -- something is obviously making the light there one minute and gone the next. However, if it were the occlusion mask, then certain light sources would not illuminate the interior of the car at all. Ever. For it to be there one moment and gone the next in RT, that most likely means that something about the light source itself is the issue, rather than it being an occlusion issue. I mean, we can't be sure, but we can test to see if it pops back in based on camera facing or position.

Well, yeah. I said that it could be on the light's side as it's an apparent intersection with the mask given all the reasons I've provided. Mod cars don't have this mask and they don't suffer this issue. Game cars do, but some lights work and I even mentioned near the end of the post that the lights penetrating the vehicle interiors could be the bug and this entire thing is intentional or an issue they weren't able to address given what occurs in the heist getaway. If that mask weren't there then this wouldn't be a problem at all, but it's there for good reason.

Occlusion, like you're describing, is more about whether particles will be drawn if they detect collision with a mesh. Shadows and lighting work differently. Where I'm curious is: can RT lighting somehow have the same sort of "occlusion glitch" as rain or snow particles can often glitch in games if the player moves into or out of an occlusion area. As "rays" for ray tracing are going to wind up being treated like particles moving through 3D space in much the same way.

Well RT and PT in games aren't the same as they are in online/offline rendering engines for tv/film. Those aren't treated like particles. We could get into that, but it would quickly get off topic. If by particles you mean photons - absolutely not. Commercial grade farms aren't even all that capable of bi-directional path tracing which is barely even an approximation of IRL visuals. I think it's only been a month or so that we've been able to visualize rays as a wave pattern in real time - and even that's an algorithm gimmick for specific assets at the moment vs. a fully realized dynamic computation. Nvidia concocting RT tranlucency/transparency/refraction gives me hope that gap will be closed swiftly though... and that CDPR may implement those features perhaps.

PT in games Cyberpunk and Portal from my understanding operate largely based on Gbuffer rather than objects fully "present" in the scene like they are with pre-rendered. It's a primitive form of the tech in some ways one could say, but a work of engineering magic as a whole. Stunning achievement even with all of the caveats it currently suffers.

The caveat to all of this, though, is that it affects both the rasterized interior and the RT interior of the vehicles. That is strange, as it's the same glitch happening with two different systems. For a universal bug like that to occur, the only absolute commonality that they share is the light source itself, so it's ground for reasoning that something about the way the engine is handling the light source is the issue, rather than some sort of issue with the vehicle interior.

If you can, the next time it happens with a static light, try testing the camera angle / vehicle position using tiny adjustments to the mouselook and forward / backward position of the car.


That's not how it works. When you're looking, say, east in the game, the only part of the gameworld that's being drawn is what's on your screen at that moment. If I was to freeze the engine and have you look even slightly to the left or right, you would see that the world had almost completely vanished. It would be empty of all geometry and textures. So, when an item is not on camera, it's not being drawn in the world. The only things that would be are assets very close to you...like a wall you might bump into if moving backwards.

I feel you and I have been talking about about two different things. My point though is that turning around won't drop the lighting from the scene entirely. Those objects are still there even if they aren't drawn and that has no practical importance for light casting or even shadow casting. Screen pace shadows, which are used for character "self-shadowing" in 2077 are screen space. That only requires the mesh part casting shadows to be drawn on screen, not the light itself.

Some objects may not be present, and some don't stream in well enough even when they "should be" on screen, but that level of aggressive culling would break entire rendering systems. Objects drawing and streaming are different. I think you're talking about a rendering frustum based on distance to the player(camera). I'm talking about the objects being present and considered in the game world at all. The lights aren't culled when I turn around because they would stop casting shadows entirely.

They're dropped from the draw calls because they aren't within in the screen space frustum, but they aren't culled. If you have an object drawn on screen, and move far enough away that it's no longer drawn entirely - it has been culled. If you turn around and that object is dropped from the draw calls to free up space for the objects that are - it's no longer drawn.

Unless I'm mistake; If all of the meshes in a scene were culled any time I turned around - Shadows would entirely break as they're removed from the Gbuffer. Enter a building with no windows, such as Afterlife - yeah, you can cull practically everything though you would not want to. Turning a corner on Elizabeth Cress st? No, you don't want to cull that aggressively.

These assets are still loaded into RAM, however, and that's how the game can (in real time) go grab the assets it needs and draw them back in within milliseconds. But that doesn't necessarily mean that the all of the data for each of those objects (like collision, or textures...or light sources) are being culled efficiently.

You can often see the effect of this by slowly turning the camera in a given direction and watching the edge of the screen carefully. Things like trees and grass, especially, will often pop into and out of existence before they're fully on or off camera. The whole world is acting like that. (This is also how all 3D games work. It's one the biggest ways that devs increase performance -- cull assets more and more efficiently, freeing up more and more processing power and VRAM for the GPU.)

I understand.

As I stated earlier; I may have misinterpreted what you intended with your question about the lights no longer being drawn on screen though.

The closest thing regarding RT (Hybrid) I can think of that may be similar to what I think you were asking is that emissive adverts revert to their lowest LOD, like LOD 3 or 2, offscreen and that will be reflected in puddles. Animated meshes like characters won't be visualized if the entire mesh is off screen. Importance Sampling may drop some assets like emissives from reflections, and it certainly does when it comes to indirect diffuse emissive lighting - in fact, there's a render distance cap for local indirect diffuse lighting when importance sampling is enabled. With PT this should be different as now the camera is tracing the path of that ray until it's final hit, it decays, or hits the render distance threshold... I believe so at least.

_______________


Post here again if you get a response to the ticket! I'm not sure that they'll say anything other than, "Ensure your drivers are up to date...[etc.]" but it will be interesting to see if there is an easy fix for it. From what I can see, I'm fairly confident it's an engine-level issue, though. Patches, patches, patches.

Yep. I will be sure to make a post if there is a change in the future. They replied that the ticket was received as they are apt to do.

I make sure to post here for things I'm more sensitive to though given nearly everything, including seemingly obscure issues, have been addressed when I post on the forum while some rather remarkable issues I've reported haven't been even following lengthy back and forth email chains with images, save files, videos, DX logs, etc. Not an indictment of support btw, they're great and very professional, just stating a peculiar reality.

 

[BabaBooey88]

I have solved this issue and will be releasing a mod that addresses it among other lighting problems.

Womp womp.

 

[BabaBooey88]

"Hello,

Thank you for contacting us, and for providing your honest feedback. We sincerely appreciate it!"

Given that's a hand written reply to a bug report, I decided I would fix more of the visual issues CDPR is not interested in addressing myself.


All of the below images are with path tracing enabled fyi.

Issues such as this light in the badlands... facing the complete opposite direction of the moon that only hits characters.
really, what's going on here?


Perhaps this completely broken lighting that takes place during the critical path for the expansion. eeesh, is this the PS3 port?


4 Months later; Ray Tracing/Path Tracing remain broken in several ways while CDPR insists it's not only fixed (they're said this twice now), it's feature complete and no longer a tech preview... and they've added totally new reSTIR!! ..even though it was part of Path Tracing before 2.0 except it's not working as apparently.

The above items aren't even bugs, those are human error issues. They're manually placed lights with specific settings repeated all across the gameworld. Ya have to stop bullshitting people for a minute and just do the work. I'm sure it's annoying the expansion broke the toys you made, it's annoying for us that our toys are broken too, but it's your project and your responsibility. If you're going to brag about these features, they need to work.

 

[BabaBooey88]

Fixes will drop after CDPR next update.