St4rgun

What is particularly interesting is the VR support. That is the heaviest load on the old engine (like nearly doubling the calculations needed, having to render different pictures for each eye), I'll be very interested in the solution ED makes with Vulkan+Multicore. Not to mention the aspects of old antialiasing techniques which are applied to DCS with no VR on the table causing some artefacts now in VR. Right now if you're GPU bottlenecked in VR then by sacrifycing some quality you can go on the FSR route to allow the GPU to free some resources by calculating the image at lower than native resolution then upscaling it which is more efficient that calculating everything in native resolution. You can further help the GPU by applying motion reprojection which uses the CPU (!) to calculate the frames inbetween. Right now it does NOT matter if DCS is mainly running on one core, as other core(s) of my 10700k can help the GPU to calculate the inbetween frames to have smooth head movement even if the calculated DCS framerate is low (like 33 or 45 fps, I'm using 90 Hz Reverb G2). Of course if the mission places heavy load on the one CPU core then the FSR and MR will not be able to make miracle, the fps will tank. If DCS engine will transfer properly to multicore, then it will distribute the load on more CPU cores. So be it, but then it could steal resorces from the now "dedicated" motion reprojection calculation which is not good. It can be balanced by some (or a LOT) optimization on the rendering method to reduce the nearly 2x load on the GPU by rendering the image for each eye. Anyhow the proper balancing and fine tuning Vulkan and Multicore together HAS the potential for a MUCH better VR experience in DCS, but it is surely a tremendous task. We're eagerly waiting for the fruits of this giant work. I have a slight fear that the gains of the Multicore method will be nullified by the cons of loading more cores at least on unbalanced systems (like using weak GPU with strong CPU for VR). We'll see.

This additional control bindings would still be nice in the near future in some OB, if possible...

Check out the following screenshot. Particularly look at the left edges of the pillars in the back and the missing AA of the fence in the front. The resolution seems quite low, but despite of that the AA of the small blue lamps is perfect in the background at the left edge of the tarmac. At the same distance the left edge of the pillars are WHITE - how can it be, while the sun shines from the right, so that should be in the shadow? It seems that the lighting, the transparent textures and the applied deferred shading are fighintg each other to have proper AA at some parts while missing at others. Maybe the shaders can be adjusted? I have no idea. According to my knowledge right now the hardware full screen MSAA of the GPUs are not used because of the deferred shading. It would be interesting to read some short form of "report" or "white paper" from the devs about this whole AA <-> VR topic.

The right evidence is a screenshot: if somewhere the AA is missing then the captured still image will have badly aliased edges without proper smoothing.

I've already tried that, but MFAA has some side effect at least for me: very slight and annoying jittering motion in the headset. It is so slight that it can only be felt and not "seen", but turning it off stabilizes the picture. What helped for me right now is the transparent AA setting (Antialiasing - Transparency / 4x (supersample)). it elimitaes the aliasing of the shorelines. But the edges of the buildings, the contour of the planes, the edges of somewhat reflective surfaces like the HUD lens etc. are still aliasing badly. I'm still waiting for any feedback from the devs that they are indeed aware of the AA issues and they have some plan for the solution (or already implemented it). Unfortunately we have very litte info on the whole Vulkan development, so every small feedback is highly appreciated.

It's obvious that the AA problem is not only present on a selected few's machines in VR, but a lot of users experiencing it. That's why I'm asking if it can be resolved in the current engine, or this is a side effect of deferred shading and WON'T be solved (or not worth any effort) as long as they're working on the new Vulkan engine. I'm pretty sure, that ED will do their best for the Vulkan rewrite to avoid all these issues, and I say take all the time it needs to eliminate those once for all. But one outcome simply CAN'T be accepted: if the new graphic engine will still have this AA problem. That is a huge no go for me. So it would be nice to have some words from the devs about this topic...

Dear ED devs, the AA in VR is still pretty much half functioning, for example in the current OB the border lines of any water bodies are shimmering and aliasing badly at distance despite of the MSAA 2x setting. Is there a hope that something can be done with the AA issues in this graphic engine, or it won't be touched until the Vulkan rewrite?

I hope ALL AI units will get the GFM as wrote here, including the bombers:

ApAcHe drops -> Me "OK". VuLkAn and MuLtICoRe drop -> Me "WOOHOOOHOO!" Now seriously: VR only player here. Vulkan and Multicore are highly expected this year, but it's only expectation. These two would be the best what can happen to DCS right now. Apache and new FLIR tech are only the icing on that cake for me.

ED started the graphic engine rewrite process 4 years ago, so we just hope, that such a cutting edge technology as mesh shaders will come through to their new Vulkan implementation. Maybe in 5-10 years realistically. This tech is compatible with RTX 20xx and RTX 30xx cards and the new RX 6800 series AMD cards ONLY, so I have no hope that ED would integrate that in the near future.

Very pleased to see that several new keybindings were added to Mi24. It would be really nice to also have some important ones in the future which related to weapon release. Thank you.

The coat hanger is very nice indeed. But I'm more worried about the CPG's TEDAC screen usage. While it's not a binocular viewed sight like the optical sights of the Mi24 there's no need to "peek in" the optics, you just have to maybe lean a bit closer to the screen. This is particularly important in VR. In the AH64 videos the parts showing the TEDAC screen are displayed fullscreen. This mode is suitable when on a screen, but in VR it's not good / nausea inducing. Can we have any detailed info on using the TEDAC screen in VR while we're waiting?

That was my first tought also, that maybe we are looking at a different graphic engine the graphics was so wonderful. But @BIGNEWY said that the demo is NOT filmed on Vulkan, so this is still the "old" engine.

Your kind words made me rethink my previous standpoint. You're right, I have to save up. So bye-bye pre-ordering the AH-64. Case closed.

As I said I'm using GTX 1070 (!) right now with the G2. The framerate is surprisingly good, but there are missions where it is seriously low (like A10C-II Caucasus takeoff mission) on this OB. To reduce the strain on my GPU I have to use OpenVR FSR with NVIDIA's NIS enabled. Without that it would be unplayable. I set my Steamvr to an insanely high 100% (mind the GTX 1070!!!), and set MSAA 2x ingame. With those settings I can mainly get 22-25 fps on the ground and 33 fps airborne, which is pretty good for me (SP only). 45 fps would be perfect although. But despite all these settings the AA is really far from perfect. There are ALWAYS shimmering edges here and there, while at the same time on the monitor the mirrored image is perfect. The lack of AA at the transparent textures' edges are the worst. That's why I hope that the team managed to solve this issue in Vulkan (forward rendering maybe?), it would help a lot on image quality. To summarize: if Vulkan will be as good in VR as the current engine in 2D with at least solid 45 fps then we are golden.

In this AH-64 video the image quality is PERFECT. The problem is in VR it's a different world because of the VR support tailored into an old engine. If only proper AA and good framerate would be a reality after the update and the visual quality will be the same as in 2D then I'll be in heaven. The G2 is capable of presenting the quality picture-wise, so it's up to ED to optimize.

Good point. But the price difference is not so much plus I give this money now, in advance. In the current situation I have a proper PC to run DCS in VR with a G2, but lacking a strong GPU (using a spare GTX 1070 right now), so there is a good possibility that I won't be able to enjoy the Apache upon release until the big graphic engine overhaul hits. If I wait for the release and check out the module for free for two weeks there is a big chance that I would not buy it eventually. I know myself well. So paying early is much more dedicated to Vulkan + Multicore + VR right now, at least on my behalf. I already asked ED if we can pay for the graphic engine overhaul to be ready sooner, but they have no plans for that. I'm much less interested in Apache itself than the whole graphic engine rework.

I'm a big advocate of denying the pre-order payment. I'm doing so while I still pre-ordered the F-14 and Mi-24 modules also back in the day. After seeing the (lack of) visual performance of Mi-24 in VR I decided to NEVER pre-order the AH-64D, I'd rather wait for the released product and check this out on my PC in VR. ...BUT... Right now based on the honest communication about the delay and the sheer quality of the video presented in the development report I decided to rather pre-order the Apache. Not only for the module itself (but I really hope that it will be flyable in VR with usable framerates), but also to financially support the development team early. I'm doing this not for this particular module, but mainly for helping the Vulkan + Multicore + VR development at the same time. That's what I can do by now ED. Not much, but I hope it will help. I'm doing it in the belief that in this year we'll see a miracle in DCS at the field of VR quality. I wish for the team and all the fellow armchair pilots a healty new year!

I gave up getting info on these topics, I understand everything you wrote. Take your time to develop the best graphic engine we can imagine, so please, PLEASE be sure that it will be really stunning in VR. The performance and proper antialiasing is a key, and DSR or other resolution scaler techniques would be nice to be supported. It will take as much time as neccesary, we'll wait for it. Just make somehow the quality equal to the PERFECT details of the 2D version as is now. Thanks for all the hard work!

In the previous thread (Week 1 & 2) the most aticipated features were Vulkan, Multicore, VR optimization and Apache. These were the topics the most users wrote about. So it's an obvious decision to not write anything about those in the next newletter... We should be more patient. It seems that they will not like to spread infos on the core topics quarterly, because exactly 3 months have passed after the last real report in this topic ("multicore development report"). Hopefully at the end of January as Apache releases according to plans, we'll have more infos on these other areas as well.

It seems that the "wristwatch & glove" combo are misunderstood by some. It is cool, that ED take care of all the details at such extent, that's why we are using this sim and not others. We LOVE details. But I still not get it why it would be normal to share details of the progress on the development of SOME departments while hardly sharing info on the CORE development? I don't want to SEE something visual, but some words would be nice about the progress... Because the new pilot model of the Mi24 will interests the people who have this module (including me), while the core interests ALL the users, everyone. I hope that I'm just a bit impatient and all the great news will be present in the next(?) newsletter(s).

Hmm. Right, I'm finished. Understood.

Sorry If I was a bit ironic with the "bunch of hobbyists" phrase. I KNOW that ED is a highly professional firm, so I'm SURE they have detailed roadmaps, period. They don't want the deadlines to be puplic, it's fine, absolutely understandable. But for god's sake why don't they implement a progress indicator stripe for us to see the development status for the ongoing BIG blocks (like the graphic engine overhaul, Vulkan, Multicore, VR optimization)? Everyone remember the oldie but goldie operating system installer progress indicators, where the line went to 95% in 1 minute just to stay there for the following 10 minutes before reaching the 100%. That's not even a problem, but seing the progress of "something happening in the deep" is MUCH better than having some sparse comment from some CM like "we are having good progress", but this is only if we explicitely asked for news. How is it possible, that months of whining from the community resulted in one, only ONE report on the progress of Multicore as a "development report", but since then nothing more. And that one report was only neccesary because they silently passed the "planned" deadline without further preliminary info, so AFTER Q3 passed they decided to write that. Don't get me wrong I was really happy to have that info, but after that what we have is silence. Sorry, I'm lying: we have the "we are making good progress" answer. During the same period we can know from the newletters that the pilot of the Mi24 will have a highy detailed wristwatch, and his glove will be fine leather all are perfecly modelled... Seriously?

That's why I'm not interested in Apache so much as long as ALL my modules (about 20) looks so much differenct in VR that in 2D. Unfortunately I fly only VR, so I'm pretty much only interested in Vulkan+Multicore, but I don't care about future plans about integrated maps etc. As long as the BASIS of the visuals in VR is still not ironed out there's nothing we can speak of. And by the way hopefully we should see some serious progress in Vulkan+Multicore in the near future (originally "planned" to be deployed by Q3 2021).

If I make the assumption, that ED is somewhat profit oriented firm and not a buch of hobbyists it's highy unlikely that no roadmap exists. It's a must to know how to use the funds for the programmers, just to name one important topic. I'm pretty sure that the so called "plans" are indeed roadmaps (=plans with milestones and assigned resources), just ED doesn't want it to be public if they miss a milestone date. That's normal, but only if they doesn't treat their ordinary software users as "stakeholders". I have no idea how ED can have the right amount of financial resources to make such an enormous development. The price of each module could seem high at first glance (80 USD i.e.), but how many buyers they have? That's not a big budget concerning the number of months/years of hard development each module needs... If ED have professional users (military, firms etc.) then maybe the income from those sources can be enough to get the bussiness rolling. When we, the "armchair pilots" are NOT the highest priority customers for ED, then all we can do is wait for any development to be complete, no matter how long it takes. It doesn't matter if they "planned" something to be ready in two weeksTM, if it will take 3 years in reality, that's OK. Who cares? We can do NOTHING against it. I already asked if the Vulkan development could be speeded up by injecting extra funds in the system. I would PAY for the Vulkan (the new graphic engine in a whole) to be ready earlier to help the developers to assign more human resources. But what if it's simply impossible, like the limited human resources can't be expanded because the lack of competent programmers? According to the last and only "Multicore development report" I assumed that Vulkan and Multicore can be delivered not sooner than Q2 this year if we are optimistic, but in reality Q4 would be more realistic. But seeing the progress I would not be surprised if we should wait for 2023. We'll "DEAL WITH IT".