RobustToolbox
RobustToolbox copied to clipboard
space-wizards
Feat/exposure nightvision
- Add Exposure to Eye which scales all lighting range and intensity.
- Each frame, lighting brightness is measured in a small square near the player, this sampled brightness is written back into Eye for client code to use to adjust exposure
- Point lights easier to add in the lighting pass, since they rely on a simpler class than PointLightComponent
- Light measuring code might have a performance impact since we're reading a RenderTexture from the CPU. It is not noticable on my system in debug builds.
- Store texture format data in Clyde Textures
- GetPixel now works on float textures
- Engine changes alone don't add HDR exposure changes. You'll see no changes until SS14 client changes are also merged.
- Light limit pass - a single fullscreen pass compresses lights above 1.0 so extreme lighting conditions look much less bright.
- Overbrighten in standard shader - Bright lights will whiten sprites (looks far less garish and more correct)
- Extremely bright or stacked lights will always look better, as they will both be capped and will also whiten correctly.
Demos with Client code changes also https://www.youtube.com/watch?v=8JrGEDx1S6Q
Powerful ghost night vision
Human dynamic exposure changes https://github.com/space-wizards/RobustToolbox/assets/5285589/91cd7fde-30d5-4dac-90dd-795614cb04ef
I've also added good looking overexposure and light compression, so overbright regions look nicer
7 flare pointlights in the same place
Ghosts are much less sensitive to overbrightness, so you can see in the dark without blowing out regions of your screen
- NightVision has zero business being in engine, allow content to supply non-entity lights instead
- AutoExposure also has no business being in engine, allow content to preprocess the to-be-rendered-lights list instead.
- Scaling non shadow casting lights is no bueno.
- NightVision has zero business being in engine, allow content to supply non-entity lights instead
I think you're right on this. "NightVision" here is very game specific, though it's kind of a scaling vignette?
Perhaps, though I'm unsure how to accomplish that. Some sort of callback on LightManager or Eye?
* AutoExposure also has no business being in engine, allow content to preprocess the to-be-rendered-lights list instead.
Being able to scale the power of the lighting system is a powerful feature. The mathematically best way to do that is to scale the lights (scaling the buffer directly loses resolution).
If you increase a light's power, you need to increase its range by sqrt(increase) because light diminishes to the sqrt of the power.
Having a callback that processes the lights seems complex and expensive, since any changes it makes can affect the filtering. It could be done, but I think it would be nicer to keep exposure specifically in-engine.
* Scaling non shadow casting lights is no beuno.
They will look unnatural if we don't scale them but increase their power. I guess you're concerned that they will bleed through walls? Perhaps if the number of shadow-casting lights is low, some non-shadow casting lights gain shadows?
Personally if I was a content author I'd want a powerful lighting system in the engine, but I'd appreciate the choice about how the exposure changed.
I've moved AutoExposure and NightVision into client code.
Eye.Exposure is still in, I argue that it has good business being in the lighting logic. If you really really hate dynamic exposure I guess we could do a post process clientside, moving it seems ugly to me.
I'm not sure what to do with local clientside lighting, probably a list of lights in screenspace or worldspace in Eye? In the meantime I commented out the additional light.
I've now moved the light exposure code into an async process in Clyde.LightingSample.cs
I only skimmed it but wouldn't you async call it? Looks like the methods are still unsafe / void.
This is really amazing, and I hope that this makes it into the game. Excellent, excellent work!
I'm starting to get back into looking at light rendering stuff, mostly to try increase performance. While my motivation lasts I'll also try get around to looking at this PR again. But in the meantime, it might be best to split off the struct PointLight related changes into a separate PR, which would also help reduce conflicts.
I don't know much about the engine but from a more player-facing side, this PR would be amazing as it would allow for different creatures to have different eye settings, I did a lot of digging and as-is there isn't really a way for SS14 rats to be able to see in dark maintenance tunnels without allowing them to hold flashlights or disabling the lighting engine entirely, which is quite unfortunate, but this PR would look even cooler than the hacky stuff I tried!
I also just think the fake-hdr effect it gives off is pretty neat, though there would need to be a cap on how bright the bloom can get because those flares are a little out of control
Had a friend say this PR could make it so Diona could feed off light. That's a really cool change.
Had a friend say this PR could make it so Diona could feed off light. That's a really cool change.
Since the lighting calculations are currently clientside this actually wouldn't be compatible with non-visual gameplay changes. It would be possible (but hard) to do enough calculations on the server to add the functionality you want - just not with this PR.
No, and I have no plans to work on it in the future. I should probably turn off notifications here now.
Had a friend say this PR could make it so Diona could feed off light. That's a really cool change.
That would be https://github.com/space-wizards/RobustToolbox/pull/5574