Search the Community

Hello, the 'new' adaptive brightness/bloom effect that was introduced in 2.8 is somewhat inconsistent and should have an option in the settings to turn it off. The bloom-ish overlay that is added to the view is depending on the sun position and your viewing direction which can become very unpleasant when you look around (TrackIR/VR) Also the effect is not well implemented (in other words: broken) when using multiple displays: The bloom effect is simply cut off, realized that there is something wrong when exporting individual screens, so I tried to do some tiled tests using only one display On the image with the four views (it's a crop, picked just one corner for example) the bloom stops right at the edge beween front-left and front-top. This is broken, it is supposed to continue in that direction and soften out, but since the camera responsible for the viewport is not facing the sun, there is no effect applied and is only visible in the view that sees the sun (front view in this case) The other image is pretty much the same, top square is the top view, the bottom square is the front view. Same issue. Initially I was hoping the bug shows only when the views are not continuous, but as seen.. even when the views are aligned to be continuous that issue is happening. (continuous means the viewport continues into the other viewport at the same edge) There are also some posts about this: (none of them with any confirmation or official feedback) Issue with mismatching brightness on multiple views: weird behavior of the sun-vs-view 'effect': same weird shading effect, the human-brightness-knob (love the title): Is there a configuration option that can be added to the autoexec file that is not documented to disable this weird bloom/light effect? or is there a way to tweak the shader for it? IC pass is not a requirement here (for me) with this issue it is ..weird to fly when looking in the direction of the sun, impossible to get proper viewports/monitor-exports (it's not just a different brightness which could be compensated for) and almost impossible to do photographic panorama style shots when facing anywhere near the sun. A simple [ ] Bloom toggle would be quiet helpful (this applies to all new features that are added, see the shadow softening issue, also needed separate options since 'something' was changed) how to reproduce: (short version) look into the sun and move the head around. how to reproduce: (long version) same as above, but with multiple viewports. I attached an example monitor setup file for a 2 tiles layout on a single screen. (you need at least 2400 pixels in vertical for that and 1200 in width. (or adjust the numbers to your liking, did not bother to do the variables based on the current screen-resolution to have consistent and reproducible values) bugreport_1200x2400_2_tiles.lua Since the issue applies to several fields: View System Bug, 2D Video Bugs, VR Bugs, Multi-Display Bugs I posted it in generic, maybe I should post it in each section? Since Generic Bugs has only a little chance of being noticed or even bothered. Neither any of the linked posts have received any official feedback. (EDIT: either I did post it now in 2D Video Bugs by accident or the thread got already moved, not sure if I had a mental moment just now..) cheers PS: tried it with the highest and lowest settings I could pick, result is the same. It does not matter if shadows are on, or global illumination is toggled, it was literally setting everything to MAX for one test and set everything to LOW (or off) on the other test) Happens in ST and MT

There is a bug that has been in DCS for a while, if you go to outside view and back in, it overexposes the light outside and you almost cant see anything out. It shouldnt be happening when switching views, it especially happens between F10 map and back into cockpit view. happens in certain modules more than others. The biggest issue with it is the time it takes until "eye adaption" sorts out the difference of light, that part is bugged, it stays on for 10-20 seconds full bright, then suddenly very quickly goes back to normal. I believe it can be very easily recreated if you try yourself, i'm using the Meta Quest 3 VR with the KA-50, it happens to me especially in Persian Gulf and Syria, don't know the times i believe it doesn't matter. The map might not matter too, happens to me in Caucasus. Can this be looked at pleeeeeeaaaase Thanks

There are some problems with the LUU-2. Brightness and colour temperature The ingame flare is too bright. It's difficult to objectively say without an ingame light metre, but the real thing should illuminate a 500 metre circle at 5 lux. The ingame flare is orders of magnitudes brighter for sure. This would not be a huge issue, but since the flare does not create terrain shadows and is not affected by clouds (both very reasonable performance trade-offs), it can appear even brighter. With more realistic brightness values, the performance trade-offs wouldn't be that noticeable. Colour temperature is wrong. Ingame it burns with a slight green tint, while it should burn with near white with perhaps slightly warm tint. It's a magnesium/sodium-nitrate mix, that should definitely not produce a flame with green tint. Missing cockpit illumination The flare correctly illuminates the exterior of aircraft flying near it, which looks very cool. However the cockpit of aircraft is not affected, which spoils the otherwise cool effect. Since cockpits can be illuminated by external dynamic lights, i assume this is just a config error, that can be easily corrected (Tested with F-5 remaster module). Having cockpits illuminated by flares will probably make the extreme brightness of the flares even more noticeable (especially for people who don't run secondary shadows), so fixing the exaggerated brightness is paramount...

Simple tweak to star.fx to make stars better. Especially useful for high supersampling, 4k, VR OVGME Ready Breaks IC Comparison video kindly provided by VR Flight Guy in PJ Pants Arttu's Night Sky.zip

Please. With normal gamma settings some of the HUDs specifically in the hornet and viper can get down right unreadable on a sunny day. This is a real life issue and not a bug and the real life solution is a pair of shades. I'm thinking like, an in game button to put them on. You could even have an option for the frames to be visible on the edge of the screen FOV like with the apache helmet display in setting or something. The MiG-21Bis has a helmet visor that can be put on via click box. Just need something like that for all the modern jets with bubble canopies and open glass HUDs. Please would improve Quality of life beyond imagination for me.

Hi, I noticed that the BRT Button on the TEDAC Frame affects the TEDAC Image brightness when the IHADSS overlay is active and affects the IHADSS overlay brightness when the IHADSS overlay is inactive. I believe this behaviour is flipped, as it would make much more sense if the BRT button would change the IHADSS overlay brightness while the overlay is visible and the monitors' brightness while the overlay is disabled. I´ve attached the relevant track file. Note that I only demonstrated this with the BRT button, but the contrast button, the symbology button and the reset button also have the same issue. BRTControlSwitched.trk

Hello, My question is that how come that every module have different brightness? I mean, the f16, A10 II and the Apache is acceptable, but the hornet is bad. Why can't you guys at least see which one is the best of them all and try to get the others to the same level? And this is my second question, thr brightness in the F15E, does it to do with some ED code or is it only razbams code? Flying the A10 I see the screens and the colours are quite good, I wish every module was the same Regards