Cleric812

Hello all, I was looking into some stuttering issues today between textures High vs Medium and the culprit definitely is High textures on my system. However I noticed something else while checking the stats in the UI FPS info. In the line "Video mem(H/W) : xxxx.xMb/xxxx.xxMb (usage/budget)" the budget keep fluctuating between around 11.5Gb and 15.5Gb when using Medium textures my usage never exceeds these values but as soon as I bump it up to High it will exceed the 11.5Gb but not the 15.5Gb I have added some screenshots which show the fluctuation in budget. Is this indication in the stats perhaps showing a deeper issue now that the texture sizes of new modules are getting bigger and bigger? @NineLine and @BIGNEWY The difference in quality between High and Medium is barely noticeable in the CH-47 but in older modules like the UH-1 it is quite noticeable. Kind regards, Vincent van Veen DxDiag.txt

Hello all, I have an interesting issue with the CH-47. Whenever I do a cold and dark start as soon as I power o the RWR via the CDU I go from just about playable FPS to absolutely unplayable. The situation occurs both in MP and SP but is much worse in MP going from ~20-25 FPS to ~3FPS for several minutes before eventually resolving. In SP the fps returns to normal after around 10-15 sec but in MP it gets so bad it doesn't even register keystrokes anymore. I wonder if there are any issues related to the RWR? Kind regards, Vincent van Veen dcs.log DxDiag.txt MP.trk SP.trk

@BIGNEWY thank you for the reply and bringing this to the attention of the teams working hard to make our sim better. Don’t get me wrong, I love DCS and I just want to see the sim grow and be better.

So basically what I am getting from your post @BIGNEWY is that 4K 32 bit normal maps (and FLIR/roughmet textures) are intended to be this size and a huge drain on resources? I understand the desire for image quality but at what cost? Do ground units that I don't see from up close really need to have enormous files so that I take a nice looking screenshot of them? Since the other thread’s GPU's have gotten more VRAM sent we are again at the limits of what is possible with these unoptimised textures both at 4K screen resolutions and especially VR. I think the reason this feels frustrating to many is that using the script to reduce texture sizes proves the game is eating up enormous amounts of RAM and especially VRAM at high texture resolution. If I run the game with the default textures I run out of VRAM (all 16GB) nearly immediately. This leaves me with 3 options. 1. Use high texture resolution but run out of VRAM and encounter massive stuttering as the game constantly loads/unloads textures. 2. Use medium texture resolution, however now I cannot read my cockpit in certain modules since they are older and become blurry. 3. Manually alter my textures so I can use high but now I cannot join servers that require a pure client. I understand there is no pleasing everyone, but this optimisation which is sorely needed for the entire games texture library, would go a long way on alleviating all these RAM/VRAM issues. And just getting more RAM or a GPU with more VRAM is not a solution due to the costs involved. Brute forcing can only go so far. As has been suggested more than once. Perhaps the standard game should have these textures optimised and compressed using the optimal method for the texture’s purpose. And a separate pack be made available as DLC which allows users to go for super ultra high res textures for making a cool screenshot or video. Again the game can run and look amazing at high texture resolution IF the texture are better optimised. I understand this has been talked about many times. But I simply cannot see how this has not been addressed yet.

Hello all, Don’t mean to be annoying and bumping this thread but I never saw this one and I am honestly shocked to see this thread is so old already! The issue still persists to this day and is getting worse with every new module that is released! See: and: It would take less than an hour to run the script through a fully loaded (every module installed that is available) and it would reduce texture sizes by 60+ GB in total. This allows people to actually use high texture settings at high resolution and have all their cockpits readable since the older modules at medium settings are blurry. 4K 32bit textures are a total waste of resources if used for anything but the actual colour textures. And even then they would probably look just as good if they were compressed as DXT5 or similar saving so much memory both RAM/VRAM and disk space. Please have a look at this to try and improve and optimise the sim where it is sorely needed. @Flappie @BIGNEWY @NineLine It is not a handful of textures that are affected. There are hundreds of them that have to grown to ridiculous sizes that can be fixed in a matter of minutes using the script by @zbysiek Kind regards, Vincent van Veen

Good afternoon, @zyll That is basically what I have been looking for for ages now! An automated way to get the file sizes in check! Thank you so much for pointing me in that direction I ran the script through my DCS folder and noticed the following results with regards to my original 4 points as laid out in the first post: 1. Less hard stuttering whenever I fly the CH-47, AH-64 or the OH-58 around the new Afghanistan map due to smaller textures being loaded in/out om memory or the SSD. 2. VRAM usage going to a manageable 13-14GB instead of instantly running to the 16GB which is the max on my GPU. RAM usage down from 40GB to 30GB. 3. Game loads slightly faster, though not a huge deal. 4. Total game size on SSD reduced from 861GB to 804GB. The texture conversion took my 5800X3D less than an hour to complete. The aircraft and cockpits look nearly identical and you really have to put them side by side to see the difference but the advantages are huge IMHO. @BIGNEWY and @NineLine This is not a huge ask of the team. This way we can still fly around using high texture settings with clear readable cockpits. It would be a huge deal if someone could please have a look at an optimized texture resolution and format option especially with the newer modules having ever larger texture file sizes. Even compressing all textures from 32bit to a much more manageable DXT5 or similar would be a plus. Can you please let us know if there is anyone looking into this? It shouldn't have to take 1,5 years plus to do what the community has done with the script and freely available tools (many thanks to @Zyll for pointing it out and @zbysiek for creating the awesome script) Kind regards, Vincent van Veen And two more shots from the AH-64

Hello all, Still no messages I see? I did some digging through the texture files and noticed every single texture is an uncompressed 32bit file. Again for normal maps, bump maps, roughmets and specular highlights this is not needed. It is using up valuable RAM, VRAM, and disk space. Don’t get me wrong, I do not want the game to go down in graphical fidelity. But these textures are a waste of space. And I know I can set my texture resolution to medium. This helps and is the only way I can actually run the game normally on my 6900XT with my Pimax Crystal, but the cockpits of older modules such as the F-5, UH-1 and Mi-8 are nearly unreadable and a blurry mess because the colour texture files are not high res enough. They are readable at texture resolution high. If there would be a real effort to optimise all these unnecessarily large and uncompressed texture the game could run so much better at the high texture resolution setting. I am currently not at my home PC but I will have a try at changing these textures to more suitable resolutions and post some before/after shots as well as run some benchmarks. Again @BIGNEWY and @NineLine I ask you to please take this to the developers. As well as third party devs and ask them to re-examine the texturing process. The way it is done now doesn’t work and needs optimising, badly, and has done so far well over a year. 65MB textures for the chair of the AH-64 alone doesn’t make any sense, nor does it make sense for ground units or the FLIR images. We are trying to fly a flight simulator, not take screenshots where the FPS and VRAM usage is irrelevant. Perhaps it would be an idea to offer people a chance to use the super over the top textures as an addon so they can choose to load up the sim to these unrealistic textures for screenshot taking? This way the rest of us who just want to fly can use the following: Colour textures 4096x4096xDXT5 Normal and Roughmet 2048x2048xDXT5 FLIR textures 1024x1024xDXT5 And a look at the damage model textures which are often huge, some even 8192x8129x32bit Sincerely, Vincent van Veen

Hello all, Just checking in to see if there’s any response? Brgds

Hey all, Maybe not related but I did notice something odd in the dcs log file. When I start the game it recognises all the cores on my 5800X3D and assigns them tasks, from memory they are core, render, and IO. However it assigns half the CPU to core, the other to render and none to IO. Is this correct? Does anybody else see the same behaviour? It is all the way in the beginning of the log. Brgds, Vincent

Hello all, I am sorry to be bringing up the same topic again as from months ago, however I feel it is still worth mentioning again and something that might help out a lot of people who are having issues since the latest few releases. As pointed out in a post in March 2023 by @Taz1004 a lot of the normal map, roughmet, and FLIR texture sizes in the game are absolutely huge. These texture files do not need to be this huge (22+MB and some reaching 64+MB) and are furthermore stored as uncompressed 32bit textures when they can easily be compressed without giving up any visual quality. The FLIR textures don't have to be 4K since all we ever see them through is our MFD's or similar sensors which do not have this resolution in the first place. The textures that are affected are mostly found in a lot of the newer modules but they are not exclusive to them. They are also not exclusive to player controlled modules or aircraft/helicopters. Ground units have the same issues. The issue also occurs with many off the addon modules not developed by ED themselves so perhaps a word from ED to the other developers to have a streamlined and standardized texture creation procedure could be considered? From what I can tell from some of the videos I have seen regarding the latest issues with stuttering many of us seem to be suffering from, it appears that DCS is trying to use as many cores as it can get to constantly load/unload textures between SSD->VRAM->RAM->page file leading to massive bottlenecks on the SSD side as the threads end up waiting on the SSD and thus each other. Perhaps one way to combat this issue would be to have the normal map, roughmet, and FLIR textures reduced in size which would, without sacrificing image quality; 1. Alleviate some of the bandwidth requirements between all these different components. 2. Reduce overall VRAM and RAM usage. 3. Reduce texture loading times. 4. Reduce the size of the sim itself (which stands at 861GB for me personally as I own nearly all modules and terrains). I totally understand the dev team is busy but if a modder can make these changes in a matter of a week or two it should be possible for the dev team to put someone on the task of hunting down these insane textures and make them a much more reasonable size. I implore you @BIGNEWY and @NineLine to please pass this message on to the responsible people and take another hard look at these texture files since this was first reported already over a year ago. As someone who has been using DCS since the days of LOMAC, please pass this on and take it seriously because I feel this could make the sim so much more enjoyable for many. Kind regards, Vincent van Veen

Just did some flying around today and it honestly feels worse than ever. I had HWinfo running in the background to try and see what was happening to cause stutters which made it more like seconds per frame rather than frames per second. In multiplayer VR running my Pimax Crystal my Radeon 6900XT completely runs out of memory (see attached screenshots). This is with the textures set to high and does not occur when they are set to medium, however almost everything in the cockpit becomes a blurry mess and unreadable when not set to high. The more high fidelity aircraft/rotorcraft are around me the worse it gets since the sim has to load in all those textures. The first screenshot is at full native res (max GPU memory usage 16588) taken on the Persian Gulf map, the second is at 0.8 FSR (max GPU memory usage 16953) taken on the Caucasus map, the last was 0.8 FSR and taken on the Syrian map (max GPU memory usage 18006).

Hello all, Still hoping for some good news regarding this topic. Flying around in MP with multiple F-16/15/18 and other high resolution aircraft around makes my GPU basically run out of VRAM and a massive stutter fest ensues. So it’s either readable cockpits with high resolution textures and massive stutters around other aircraft. Or I have to use medium textures which makes most cockpits exceptionally blurry but no stutters. I know it’s great to see progress being made regarding so many aspects of the sim. But it does make me wonder what the priorities are if a modder such as @Taz1004 can create this mod which helps reduce memory load significantly by himself and the development team seems to be unable to do so or unwilling? @Flappie would love it if you were able to direct some of the devs attention to this issue again, fingers crossed I read this as a fixed issue in the changelog one day :)

Good afternoon all, i was wondering if there had been any progress on this from the dev’s side? Perhaps @Flappie can give us an update?

Hello all, I just spent some time writing a batch file for texconv.exe (https://github.com/Microsoft/DirectXTex/wiki/Texconv) to try to streamline the process. The thing that struck me most during this is that there seem to be some absolutely huge normal maps and roughmet textures, some as large as 80+ MB. The other thing that I noticed was the apparent lack of standardization of the texture sizes and names. some normal maps have "normal" in their name while others have "nrm" or "NM" in there names. I understand they were most likely created at different times and by different developers. However I think it might be worth it for someone to sit down for a day or two to go through these textures and standardize them. I cannot tell any difference between a 4096x4096 32 bit roughtmet or normal map and a 2048x2048 DXT5 file does the job just as well, often cutting total size of texture for the models in half at times. Just my 2 cents

+1

+1

Hello all, I hope I’m not creating a topic that is already known about but I noticed something that struck me as odd and wanted to ask if this behaviour is correct. In the latest OB version (2.8.2.35759) I have my shadows set as follows; shadows - medium, secondary shadows - off, and terrain objects shadows - off. However when I fly around low to the ground I notice that my aircraft still casts shadows on the clutter/grass objects as well as on trees and ground objects such as GeneratorF. Is this behaviour correct?

So just as a little up date as to my troubleshooting steps since it's now completely not working: 1. Restart "windows perception service", no joy 2. Clear out WMR environment data, no joy 3. Reinstall the OpenXR dll's from github, no joy 4. Reinstall the OpenXR dll's from Edmuss's pakcage, no joy 5. Reboot, no joy I will include the full error log: DrvOpenXR::GetXRAppName:103 - Setting application name to OpenComposite_DCS DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_KHR_win32_convert_performance_counter_time DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_KHR_D3D11_enable DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_KHR_D3D12_enable DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_KHR_composition_layer_depth DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_KHR_composition_layer_color_scale_bias DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_unbounded_reference_space DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_spatial_anchor DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_perception_anchor_interop DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_win32_appcontainer_compatible DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_conformance_automation DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_composition_layer_reprojection DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_spatial_graph_bridge DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_spatial_anchor_persistence DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_eye_gaze_interaction DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_hand_interaction DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_hand_tracking DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_hand_tracking_mesh DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_MSFT_controller_model DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_KHR_visibility_mask DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_samsung_odyssey_controller DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_hp_mixed_reality_controller DrvOpenXR::CreateOpenXRBackend:150 - Extension: XR_EXT_debug_utils DrvOpenXR::CreateOpenXRBackend:155 - Num layers available: 1 DrvOpenXR::CreateOpenXRBackend:163 - Layer: XR_APILAYER_NOVENDOR_toolkit DrvOpenXR::GetXRAppName:103 - Setting application name to OpenComposite_DCS debugCallback:117 - debugCallback Completed loader terminator debugCallback:117 - debugCallback Completed loader trampoline DrvOpenXR::CreateOpenXRBackend:250 - viewCount: 2 DrvOpenXR::CreateOpenXRBackend:256 - xrViewCount: 2 DrvOpenXR::SetupSession:296 - XrSystem: 1 XrInstance: 0000000000000004 XrBackend::PumpEvents:883 - Switch to OpenXR state 1 XrBackend::PumpEvents:883 - Switch to OpenXR state 2 XrBackend::PumpEvents:887 - Hit ready state, begin session... XrHMD::GetStringTrackedDeviceProperty:341 - GetStringTrackedDeviceProperty 1000 (null) XrHMD::GetStringTrackedDeviceProperty:341 - GetStringTrackedDeviceProperty 1000 XrHMD::GetStringTrackedDeviceProperty:341 - GetStringTrackedDeviceProperty 1001 (null) XrHMD::GetStringTrackedDeviceProperty:341 - GetStringTrackedDeviceProperty 1001 BaseExtendedDisplay::GetWindowBounds:15 - GetWindowBounds w 1920 h 1080 XrHMD::GetRecommendedRenderTargetSize:18 - GetRecommendedRenderTargetSize w 3176 h 3108 XrHMD::GetStringTrackedDeviceProperty:341 - GetStringTrackedDeviceProperty 1000 (null) XrHMD::GetStringTrackedDeviceProperty:341 - GetStringTrackedDeviceProperty 1000 XrHMD::GetHiddenAreaMesh:211 - GetHiddenAreaMesh eye: 0 type: 1 XrHMD::GetHiddenAreaMesh:211 - GetHiddenAreaMesh eye: 1 type: 1 XrBackend::CheckOrInitCompositors:319 - Recreating OpenXR session for application graphics API DrvOpenXR::SetupSession:296 - XrSystem: 1 XrInstance: 0000000000000004 XrBackend::PumpEvents:883 - Switch to OpenXR state 1 XrBackend::PumpEvents:883 - Switch to OpenXR state 2 XrBackend::PumpEvents:887 - Hit ready state, begin session... DX11Compositor::CheckCreateSwapChain:274 - Generating new swap chain DX11Compositor::CheckCreateSwapChain:278 - Texture desc format: 28 DX11Compositor::CheckCreateSwapChain:279 - Texture desc bind flags: 40 DX11Compositor::CheckCreateSwapChain:280 - Texture desc MiscFlags: 0 DX11Compositor::CheckCreateSwapChain:281 - Texture desc Usage: 0 DX11Compositor::CheckCreateSwapChain:282 - Texture desc width: 3176 DX11Compositor::CheckCreateSwapChain:283 - Texture desc height: 3108 DX11Compositor::CheckCreateSwapChain:311 - Texture desc format: 29 DX11Compositor::CheckCreateSwapChain:338 - Created swap chain: 3176 x 3108 d3d_make_surface_data:131 - Texture description: 3176 x 3108 Format 27 d3d_make_surface_data:131 - Texture description: 3176 x 3108 Format 27 d3d_make_surface_data:131 - Texture description: 3176 x 3108 Format 27 DX11Compositor::CheckCreateSwapChain:274 - Generating new swap chain DX11Compositor::CheckCreateSwapChain:278 - Texture desc format: 28 DX11Compositor::CheckCreateSwapChain:279 - Texture desc bind flags: 40 DX11Compositor::CheckCreateSwapChain:280 - Texture desc MiscFlags: 0 DX11Compositor::CheckCreateSwapChain:281 - Texture desc Usage: 0 DX11Compositor::CheckCreateSwapChain:282 - Texture desc width: 3176 DX11Compositor::CheckCreateSwapChain:283 - Texture desc height: 3108 DX11Compositor::CheckCreateSwapChain:311 - Texture desc format: 29 DX11Compositor::CheckCreateSwapChain:338 - Created swap chain: 3176 x 3108 d3d_make_surface_data:131 - Texture description: 3176 x 3108 Format 27 d3d_make_surface_data:131 - Texture description: 3176 x 3108 Format 27 d3d_make_surface_data:131 - Texture description: 3176 x 3108 Format 27 oovr_abort_raw:55 - Abort! XrBackend::SubmitFrames:701 - OpenXR Call failed, aborting. C:\Users\Jabbah\Documents\open-composite-acc\DrvOpenXR\XrBackend.cpp:701 SubmitFrames. Error code: -1 res

Hello all, I have to say I have been some amazing results with OpenXR however with 0.6.0 and 0.6.1 I have been bugged by the following error quite regularly: " XrBackend::SubmitFrames:701 - OpenXR Call failed, aborting. C:\Users\Jabbah\Documents\open-composite-acc\DrvOpenXR\XrBackend.cpp:701 SubmitFrames. Error code: -1 res" I haven't found a reliable way to resolve it yet, sometimes a reboot helps, and sometimes reinstalling the OpenXR dll's into the DCS folder fixes it. I am not quite sure what is going on but is a little frustrating as when it runs it runs beautifully. Has anyone else run into the same issue?

Thank so much for the help. That was the "silver bullet" that made my day!

Hello gentlemen, I have read through the entire thread with great interest since I have been struggling quite a bit with the settings regarding the motion reprojection and motionsmoothing options on my 6900XT. I have some questions regarding the settings you guys are using to achieve your results. Can you guys share your settings for the following menus in SteamVR and WMR for SteamVR respectively? Kind regards, Vincent

Hi all, Just a quick question to you Sr. What combination of motion smoothing and reprojection are you running? And are you running forced DX11 or not? I have a 6900XT as well and noticed the following. For motion smoothing: DX11 off gives me much clearer images but the motion smoothing is very janky and not smooth. If I force DX11 on using wmr for steamvr it is silky smooth. So I have to choose between smooth motion or clarity which is quite annoying. For reprojection: it introduces a lot of warping images (most noticeable on text and straight lines) no matter if I use auto or forced, and both in normal and with forced DX11. So far my best compromise has been forced DX11 and reprojection off. I am curious what settings you ended up with. Kind regards, Vincent