St4rgun

I don't think this kind of thread is appropriate while the user base is still trying to get answers (and not getting) from ED on why the clouds are STILL super ugly aliased in VR... The clouds for me changed in the good way months ago, but there's a spcific type of cloud layer which is still badly aliased on STANDARD settings. Quality with ULTRA cloud settings is much better, but it hurts frametime a lot. Look at here.

I imagine that in the future it will be inevitable to have modifiable terrain in DCS (either by the explosion craters or by the troops / bulldozers). In that case the trees and the terrain heightmap also can be modified according to tactical needs.

Using only the ingame AA settings in VR most of the clouds are really nice and smooth even at STANDARD settings but there are some specific cloud types which are extremely aliased even at closer distances. This kind of cloud type can really ruin the visuals in VR, very distracting. The simplest method to reproduce the aliasing is to open the F/A-18 AIM-120 training mission, which is in active pause mode at start in the Caucasus map. Just look around the cockpit and check out the clouds in VR. For me they are ugly aliased at STANDARD preset with MSAA 2x and MSAA 4X also. ULTRA preset looks really much better, but the impact to the framerate is high. If only this issue can be eliminated then all the clouds would be much nicer. Please, PLEASE try to fix it already! It's killing the immersion. In the current EDGE one can choose to: Not use MSAA at all and set clouds to ULRA to get at least somehow playable framerates even in rain -> but it causes wild shimmering everywhere with nice clouds Use at least 2x MSAA to get rid of shimmering of everything and STANDARD clouds -> playable framerates but really ugly cloud aliasing with certain types of clouds, but not all of them Combine 2x MSAA to get rid of shimmering of everything with ULTRA clouds to eliminate clouds aliasing and get a nice slideshow in rain

The problem persists after the new OB patch (2.8.1.34437)

For me it seems really unbelievable that in a real Hornet the pilot should have it's eye height be in a perfect position otherwise parts of the symbology DISAPPEARES... That would be a serious design flaw if it's true.

I've looked for some DCS videos on Youtube with Hornets from the last year (2D players, not VR). None of them had this kind of gap on the HUD symbology. As I recall it was not apparent about that time, because it would readily became annoying back then but I did not noticed it previously. @BIGNEWYI understand that this thread currently is in the CORRECT AS IS status, but this bug is really annoying. Could the team eliminate this "feature"? Thank you.

The new FPS counter in 2.8 revealed for us, that in the total frametime one of the largest chunk is "simulation". I wonder if the multithreading means that this "simulation" part will be completely detached from the rendering frametime, thus enabling higher framerates at start? Or the frames simply can't be rendered without the fresh simulation data no matter what? The current CPU + GPU hardware seems to be enough for pleasingly high framerates in 2D, the VR what seems extremely critical because of the need of high framerates combined with very high resolutions and dual displays. But for VR what is the most important part is to have virtually lag free very smooth movement for precise head tracking. Despite of the needed 90 fps this can be pretty much solved with asynchronous reprojection (ASW for Oculus or motion reprojection for WMR) at much lower framerates which would be perfect. The only problem are the visible artifacts of the reprojection. If those can be eliminated then even the current state of the sim would be very good for VR. But if the rendering and logic threads will be separated then this could yield high gains in the long run. The best description of the current situation is made by @SkateZilla in another topic here (I'm rather curious why not using such interesting details like this explanation in the newsletter by the way...):

What is weird that in that thread @BIGNEWY wrote this is correct as is, while the last photos or real hornets' HUDs showed that it is not the case. Is it still in correct-as-is status?

It looks like the tickness of the first plane of glass, but I suppose that in normal seating position it shouldn't be normal to have a "broad" missing line az important information. And as I remember this was not the case before, but I din't used the F/A-18 in the last months.

Is it just me, or something really happened to the F/A-18 HUD in VR? I noticed that at the bottom edge of the first combiner glass there's a small horizontal stripe where the HUD symbology is missing. The vertical width of the stripe changes as I lean forward and backward in the cockpit. In the following screenshots the G 1.1 text at the left in the first screenshot: and the "NWS" text at the right at the second screenshot: looks partly missing because of that horizontal empty stripe. Is this intended as is? I don't recall that it behaved like this before...

We asked for it countless times with really polite reasoning. Personally I became to this simple conclusion: they'll do their job in their own pace, which is perfectly fine. And if they decide not to say a single word on the status of some development it's also their decision. Even if we don't agree, THEY DON'T CARE, period. For some reason this became their policy on core development. In the last months the newsletters are rather disappointing for me also. The interesting trend is that the lack of news about the development of the core (mc and Vulkan) comes hand in hand with more often SALES. Right now we're going from one sales to another at pretty high discounts, which should be good for the customers but for me it rather hides something behind the scenes. The new clouds are deployed long time ago with the most serious bugs eliminated in the first half a year. I really like the visuals of the clouds in VR right now, if they are fine. But there're some distant layered clouds where the quality drops to about 10% because of the really heavy aliasing and shimmering. This issue is still unsolved for several months now, and we don't get a single response from ED that the developers are working on some kind of solution. Probably they won't allocate resources to solve this in the current graphic engine when mc / Vulkan in on the way where they'll implement the proper solution. The problem is we don't know if it's even true. Because of the silence.

Let me reply quick: N O P E. They don't care about anyone trying to get information about actual development status. We tried to ask for it in the last year in polite and even funny styles. Nothing changed since then. The only answer is "we currently have no new information to share, thanks." To have MSFS-style development plan for the upcoming months with strict timeframes.... In your dreams maybe. The whole multicore / Vulkan development was PLANNED to be released by Q3 2021(!) originally, at least according to their published plan at January 2021. Then the date passed and the community just got a "Multicore development report" which is still unprecendented since then. More than one whole year passed since the last somehow detailed report it total radio silence. What we know right now for sure: The multicore development will forego the Vulkan implementation, but no info about how much. The multicore is in closed beta testing status currently, but no info about the estimated length of that phase. The community managers seems to be tired of asking them about this whole topic again and again so I personally won't count on any answer from them. I'm pretty sure tho, that as long as there'll be real new info, they'll share. Maybe in weeks. Or months. Or years. Maybe never, we don't know.

Anyhow it's not our responsibility to solve such problems, we are just making a discussion on this topic here. It would be very interesting to read some whitepaper about this game engine but this will not happen I suppose. All we can do is wait for ED to finish the internal beta test for MC. By the way, @SkateZilla is it still classified that we are weeks, months or years away from the end of that test?

??? OK, right then, I'm out.

"You have no idea what you are talking about." Sorry, what? "If you don't enforce a frame rate for the physics rendering" who said anything like that? I said it can be lower (or much lower) than the refresh rate of graphics rendering. As you said "the physics engine very much needs to have a constant frame rate" which is pretty much not the case if you closely bind it to the graphics rendering right now, because the framerate is all over the place without motion reprojection. What I said that graphics rendering should have maximum priority especially for head movement in VR to have it nailed to 90 fps. Everything else in the simulation can wait. The graphics cant.

The anti-torque rotor of the AH-64D rendered in different phase for the left and right eyes in VR as can be seen in F2 view. It causes disturbing "crosseyed" vision while looking at the rotating tail rotor.

I tried to set it only once but isn't is intended to use a STATIC preset to choose the clouds formation, then switch to DYNAMIC tab and set the data there and leave it active? In that way the preset generates the clouds and the dynamic tab generates the winds. Is that right?

If only the rendering pipeline gets totally separated then that alone would yield huge gains imho. As I imagine in a simulator there"re a lot of subsystems which can be separated for parallel running in multiple threads and "sparse" syncing data. If the rendering can run freely, independently of the simulation then at least the stutters should be eliminated. For VR the display should be refreshed at 90 fps which is crucial for the smooth movement, but anything else is much less important (at least for me). Who cares if the flight model is updated "only" 20 times a second? Or if the calculation of a missile control system updated only 10 per seconds? Or all the instruments in the cockpit at lower interval? Personally I don't care if the sound of an impact is late by 0,1 s (of course the interaction sounds should be prompt). When ED made the original graphic engine then no one wanted to render a stereo image for two eyes at 90 fps with a resolution of 3100x3000 pixels/eye (with the current graphical fidelity levels). Now the main focus should be (and I'm pretty sure it is) this: very high frame rate at extreme stereo resolutions. I'm sure they'll find the proper solutiuon for this enormous task.

I hate to say but I had to rollback to 2.7.18.30765 for the better performance. Which is a pity because I liked the new FPS counter, dynamic weather, new lighting on PG and the raindrops on the canopy glass so much, but after more testing it turned out that 2.8 in this state is not for me in VR, sorry. I really hope that ED team can find a quick solution to counter this performance drop in VR.

One more small extension: The SGSSAA can make the environment a bit softer. To encounter this, the following additional settings can be appied in nVidia Profile Inspector: [4 - Texture Filtering] Anisotropic filtering mode User-defined / Off Anisotropic filtering setting 16x Texture filtering - Anisotropic filter optimization On Texture filtering - Anisotropic sample optimization On Texture filtering - Driver Controlled LOD Bias Off Texture filtering - LOD Bias (DX) -0.5000 Texture filtering - LOD Bias (OGL) -0.5000 Texture filtering - Quality High quality Texture filtering - Trilinear optimization Off Theoretically the negative LOD settings can force to use more detailed LODs for objects as the default, hence the softness is eliminated and also the cockpit interior would be even more crisp. Unfortunatelly this can make the shimmering a bit more in the environment, but not so much. Personally I switched OFF the SGSAA because the small performance penalty, maybe I'll switch them back on if ED manage to iron out 2.8 or after implementing MT / Vulkan. But I really hope that in Vulkan they have the possibility to rethink the whole AA process to be as efficient as possible.

If MT is in closed beta state thats fine, we already knew this for weeks. Let's wish it can come out to the light (to the OB) in really very short term. I'd be hugely disappointed not able to test MT in OB this year, more than a YEAR after their previous ETA for Vulkan to finish... Of course testing the core could be unimaginably complex task, so this could take arbitrary long time but I really hope this won't take years (not even months) to finish now.

I think without HDR HMDs this method is the best we can get for simulating the eye accomodation to different light intensities. If the devs can make it as an option to switch off for the ones who don't like it then great, I personally prefer it as it is now.

Just a quick update after 2.8 OB came out for anyone new to this AA technique in VR. As @Mustang pointed out in another thread for nVidia users there's a very good opportunity to get rid most of the jaggies and shimmering if the hardware is strong enough by using MSAA 2x combined with SGSSAA (Sparse Grid SSAA) for transparent textures. Check out my system specs in my signature. The results are: the clouds became pretty nice at the edges (semi transparent parts are finely antialiased), athough the low LOD are still present for distance clouds at least on "Standard" clouds mode the transparent textures (power lines, fences, trees edges, painted lines on the tarmac) are very smooth the cockpit interior is extremely detailed, crisp and smooth (in particular to the HUD and MFDs symbology) in F2 view my plane is looking as good as never before, no jaggies, no shimmering, just pure joy no detectable fps drop compared to simple MSAA 2x Important remark: be sure to make a profile with nVidia Profile Inspector for DCS only, so DO NOT CHANGE THE GLOBAL PROFILE, because doing it can mess up with other software display modes. For me changing the global profile wrecked up all Microsoft Office / Microsoft Store applications (immediate black screen after starting any of them), but disabling SGSSAA in the global profile again restored their normal behaviour.

+1

This is the single BEST suggestion I read here in the previous months! Really thanks, the quality of the visuals became MUCH better imho. Actually the clouds are still heavily aliased as before and the environment looks a bit softer for me than with transparent SSAA 8x, but the HUD and the cockipt interiors are so clear that I could not believe it at first sight. It is such a huge leap for me as the switching from SteamVR to OpenXR was!