Rosebud47

... so hope vr zoom could be fixed again with an upcoming update. The vr zoom with parallel projection looks weird to me, somehow not right in place. Another strange thing is, when you activate ´single pass stereo´ in the graphics.lua, on the left side there is rendering of the terrain missing, but not on the right side of the large field of view...very strange. Better setup the single pass stereo as false, then this problem is gone.

Don´t have these problems, but have you tried to run the room scale setup for the HMD again, especially the part in the setup process, in which you define the ground level. Best would be to define the ground level for the HMD manually, if possible, by setup program - would be like approx 120 cm in a sitting position from HMD to ground. Mostly the Setup process asks to put the HMD to the ground to define the groundlevel.

Wenn die HP Reverb eine Auflösung von 2160x2160 pro Auge hat, sollte die Anforderung an die GPU mit denselben Grafik Einstellungen in etwa gleich ausfallen, wie mit der Pimax mit 2560x1440 Bildpunkten pro Auge.

By adjusting the viewports in DCS, I could have get a much more better image clarity, spotting and distance view with the Pimax 5k+. Actually I was fiddling around with the settings to get the VR zoom properly working with the 5k+, but this is another story, I guess. To adjust the screen size for the Pimax, open the "stereo.lua", which could be found in c:\Programs\Eagle Dynamics\DCS World Open Beta\Config\MonitorSetup\ The Stereo.lua looks as follows: _ = function(p) return p; end; name = _('Stereo'); Description = 'Stereo render two viewports for left and right eye respectivelly' Viewports = { Left = { x = 0; y = 0; width = screen.width * 0.5; height = screen.height; viewDx = 0; viewDy = 0; aspect = screen.aspect / 2; eye_shift = -0.032; --tans of side angles projection_bounds = { left = 0.964925826, right = 0.715263844, top = 0.889498115, bottom = 1.11092532, } }, Right = { x = screen.width * 0.5; y = 0; width = screen.width * 0.5; height = screen.height; viewDx = 0; viewDy = 0; aspect = screen.aspect / 2; eye_shift = 0.032; --tans of side angles projection_bounds = { left = 0.715263844, right = 0.964925826, top = 0.889498115, bottom = 1.11092532, } } } UIMainView = { x = 0; y = 0; width = screen.width; height = screen.height; } GU_MAIN_VIEWPORT = UIMainView After editing it looks like this: _ = function(p) return p; end; name = _('Stereo'); Description = 'Stereo render two viewports for left and right eye respectivelly' Viewports = { Left = { x = 2560; y = 1440; width = 5120 * 0.5; height = 1440; viewDx = 2560; viewDy = 1440; aspect = 3 / 1.6878; eye_shift = -0.032; --tans of side angles projection_bounds = { left = 0.964925826, right = 0.715263844, top = 0.889498115, bottom = 1.11092532, } }, Right = { x = 5120 * 0.5; y = 1440; width = 5120 * 0.5; height = 1440; viewDx = 2560; viewDy = 1440; aspect = 3 / 1.6878; eye_shift = 0.032; --tans of side angles projection_bounds = { left = 0.715263844, right = 0.964925826, top = 0.889498115, bottom = 1.11092532, } } } UIMainView = { x = 2560; y = 1440; width = 2560; height = 1440; } GU_MAIN_VIEWPORT = UIMainView Not being an expert, I would guess, that the issue with the VR zoom in DCS not properly working for the Large Field of View VR Headsets relates to its non-coplanar design. Please see description in link: https://devblogs.nvidia.com/turing-multi-view-rendering-vrworks/ When activating VR zoom with a Large Field of View Headset, the images of the right and left eye overlapping in the middle. The closer the zoom goes, the more the images overlapping. This is only in the middle of the view, through the lenses of the Pimax. At the outer sides of the view, where left and right eye images are not overlapping, the VR zoom is fine. Hopefully a developer could have a look into it, as the VR zoom is very useful and even essential, when you just learn to fly and handle a new model. For a fix or workaround like for the Odyssey recently, I would be thankful like crazy :) EDIT 27.04.2019

Had mostly the same settings with the Odyssey+ too, but left the AA option in the Nvidia driver off. My impression was, that with no FXAA in Nvidia settings, the image in DCS becomes sharper. Also in SteamVR pushed Supersampling to 208, which was still fine performancewise.

Das MotionReprojection wendet die Technik von Asynchronous Reprojection auf die Kopfbewegung an, was DCSHeliflieger mit Hochachsendrehung beschrieben hat. Normales Reprojection arbeitet auf die gesamte Bewegung im Bild. Motion Reprojection erweitert die Technik auf die Bewegung des Kopfes innerhalb der Bewegung im Bild.

:thumbup: thanks ... that should solve the same problem I had 100%

For the Pimax large field of view headsets, I would recommend the Pimax 5k+ in anyway before the Pimax8k. Pimax startet their kickstarter campaign with the Pimax 8k only some years ago. The FOV and Resolution of the 8k was and still is kind of revolutionary in the market for VR headsets. Approx a year after the start of the kickstarter campaign, Pimax invented the 5K+ and offered to the backers of the original 8k to switch to the 5k+. The thing is, that both, the 8k and the 5k+ gets the same input signal of 2560x1440 via DisplayPort ( once I´ve read it´s the maximum resolution a DP connection could handle ). But the panels of the 8k are different from the 5k+. The 8k got panel resolution 3840 x 2160 per eye and the 5k+ has got panels of 2560x1440 per eye. Both at same 170° horizontal field of view. The 8k has got an internal upscaler, which scales the native input signal of 2560x1440 up to 3840x2160. This results the picture of the 8k in less clarity and sharpness compared to the 5K+. Also the panels of the 8k has got a diagonal pixel matrix, the 5k+ has got a horizontal pixel matrix, which supports a better clarity and sharpness. With both the SDE is minimal visible in a comparative way, in anyway less visible, than with any other headset available at the moment and not worth mentioning. But the overall picture clarity makes a difference, as with the 8k the picture gets liitle fog through the internal upscaling process. Having a native resolution is always the best, when it comes to picture clarity. To get comparable picture quality from the 8k to the 5k+, the 8k would need much more supersampling on cost of performance, than the 5k+, which is already very challenging to perform well.

A friend of mine gives a party on the 27th and there are people and friends coming, which I worked with and didn´t see or spoke to for over a year now. RL = RealLife

@Alpenwolf unfortunately RL event crossed my schedule to take part in the Tournament 6 on 27th. Please cancel Voight / Gazelle Mistral I´m sorry, but hope to join in a future Tournament again.

ASW, Asynchroneous reprojection, Smart Smoothing und wie sich das alles nennt, macht eigentlich alles das gleiche und nutzt immer. Wenn das headset 90 Hz als Bildwiederholrate hat, die aber nicht erreicht werden, greift ASW und Co., wenn ein Schwellenwert unterschritten wird. Dann schaltet die Software in einen 45 Hz Modus und interpoliert jedes zweite Frame und schiebt das interpolierte Frame, zwischen zwei real gerenderten Frames. Also 45 Frames echt gerendert und 45 Frames interpoliert von dem zuvor echt gerenderten Frame. Im Ergebnis fühlt sich das Bild in der Brille dann flüssig an, bei nicht allzu hektischen Bewegungen. Optimal ist bei 90Hz Displayfrequenz in der Brille stabile 45 Hz/fps mit ASW und Co. zu halten. Wenn man darunter liegt, ist ASW und Co. zwar immer noch aktiv, es werden nur, bedingt durch die Rechner/DCS Einstellungen, die 45FPS nicht gehalten und nur 30 FPs erreicht, was wieder einen weniger flüssigen Bildablauf erzeugt ( kleine Ruckler, Mikroruckler usw. ) Das Ghosting ensteht aller Wahrscheinlichkeit nach auch durch ASW und Co. und fällt immer dann auf, wenn Objekte sich schnell durchs Bild bewegen. ASW und Co. erzeugt immer eine Kopie eines zuvor gerenderten Bildes, d.h. wenn sich ein Objekt mit höherer Frequenz bewegt, als ASW den Eindruck durch doppelte Bilder nicht mehr ausgleichen kann, es hätte tatsächlich mit jedem Frame eine neue Position im Bild, entsteht der ghosting Effekt, der das Objekt in der Bewegung gleichzeitig an zwei Positionen zeigt. Wenn die tatsächlichen FPS dann auch noch bei rd. 30 FPS liegen, ist das "Geisterbild", also die Kpie eines zuvor gerenderten Bildes, wahrscheinlich dann noch länger sichtbar und wird stärker wahrgenommen, als bei 45 FPS, wo im Takt nach jedem Geisterbild sofort ein gerendertes Bild ohne Verzögerung folgt, so jedenfalls mein Eindruck.

Have bind the VR center button as well on the HOTAS. It could be found in the DCS System configuration menu. At the pull down menu, where you select your flight module to configure, there´s the option for GUI Layer - there the VR center button as well as VR zoom could be configured.

Voight / Gazelle Mistral

Can tell from the Samsung Odyssey+ Windows Mixed Reality HMD, that it got a sensor inside between the lenses, which recognizes, if you wear the headset and looking through the lenses of it or if you don´t wear it and look on to the screen/monitor. You could check by covering the proximity sensor with your finger inside between the lenses. Every time the HMD/ proximity sensor recognizes, that you wear the headset, it locks/blocks the screen on to your monitor. This locking/blocking of the screen could be turned off by pressing "windows button" + "y" on the keyboard ( or "windows button" + "z" with english keyboard layout ). When the screen is locked, only the program window in the foreground of your desktop is active for the VR headset, which is a bit irritating, while having in the VR headset only the the picture ( program window ) of DCS. The point is, that the mouse cursor in VR then only works with the one active window in the foreground. When putting on the windows mixed reality headset, make sure by pressing Alt + tab to have the DCS window in the foreground of your desktop, to have the mouse cursor locked in this window to have the mouse working in VR.

Yes, hate the shimmering too, but MSAA is very demanding. Tried anti-aliasing options via Nvidia driver, but doesn´t work as good or at all, like the MSAA of DCS World system.

MSAA 2x Large Field of View with Pimax5k+ ... the rest to be adjusted, to make it run a stable 36 FPS running the Pimax with 72Hz ( or 45 FPS when running at 90Hz ). Brainwarp Smart Smoothing cuts the target Hz anyways into half. Fixed Foveated Rendering works fine and gets a performance gain approx 10-15% ...but only at daylight. Pimax´ fix foveated rendering is crap when there are light sources, like the illumination of the gauges in the cockpit of the Mig21, as it turns the lights and illumination off, when watching through the outer ring of the sweetspot. ... love the large field of view in VR :-)

I´ve ordered the lenses from VR Lens Lab for the Samsung Odyssey, which perfectly fit too on the Samsung Odyssey+. The adapter lenses on top of the Odyssey´s regular lenses really came very close to my eyes. So I´ve ordered a new and thicker face cushin form "VR cover" for the Odyssey+ , which gave some space back between adpater lenses and eyes.

Guess you mean the ABRIS / moving map system on to the right side as MFD. For switching from russian language and letter into english, there could be found an option in the DCS System menu, which is mentioned as "native" for the KA50 native russian language. Simply switch the option into english for english language and letters in the moving map system.

Thanks to Alpenwolf for the organisation. It was great fun tonight! And a special thanks to Maverick for the stream - we love you, pal!

Couldn´t follow up the statement, that the western aircraft models sells twice as much as the eastern aircrafts in general. When it comes to a comparison between the MiG-15 and the F-86, the F-86 surely will be sold more often, because of the bigger market in the west, just because you would expect from these two models exactly the same capabilities, quality and gameplay... they even look the same and the decision to prefer the F-86 before the MiG15 might be more based on the expectation, than on any other reason, that western people get more quickly familiar with the module, than with the MiG-15. I don´t think, that any flight simmer buys a module out of political reasons, but for entertaining reasons. We are looking for the quality of module, level of detail, flight modell, depth of system simulation, capabilities of the aircraft and in particular advantages in multiplayer. Surely we rotorheads will order the Hind as same quick as the Cobra or an Apache, if there were any, but arguing from a selling point of view and to bring new players/customers into Helicopters, I think the Hind would be more preferable than the Cobra. The Hind seems to be much more exciting and iconic already, when following the discussions about each modell. This excitement might result of the close connection between Hollywood Movies and PCgaming industrie. Mostly the movies and popular media create an iconic picture and make a military aircraft famous, of which we then could keep the excitement alive through the flight sims. The Cobra has not really excitement and no iconic reference to the entertainment branch, like the F-14 for instance or the Hind. The Hind even has no western equivalent like most of the other aircrafts, it´s a unique helicopter worldwide. This might be no reason for us, already being into flight simming or helicopters, but for first buyers a reason to get into it. So, I would say in short, the more present a military aircraft is in movies or media, the better it could be sold in DCS, no matter if it´s an eastern or western modell. Surely creating a new modell should not be based on that, but it should be taking into account on the selling point of view. Finally it´s the quality of each module, what values most.

The BO-105 surely would enrich every helicopter collection and very interesting regarding its flight ability and purpose in combat scenarios. The KA50 is a great module, but I would say, its extravagant koaxial rotor design and unpopularity might hold back people from buying it and buy the Huey instead. The Mi-24 Hind, with no doubt, will be the top seller of all helicopters and surely will be an entry model in DCS for those, who never were into helicopters before. Its the most unique, impressive and popular combat helicopter, we could think of. Also a more huge variety of mission scenarios is thinkable with the Hind, more than with any other combat helicopter.

Voight - Gazelle L

die Schalterbelegung lässt sich, soweit ich es ausprobieren konnte, bei jedem Modul so modifizieren, um sie an die individuelle Belegung am eigenen HOTAS anzupassen. Glaube aber, dass die entsprechende default.lua file irgendwie an die Geräte ID vom eigenen HOTAS gebunden ist und sich so nicht einfach mit copy und paste an ein anderes System übertragen lässt. Das Editieren der .lua ist aber kein Hexenwerk und geht mit etwas Übung auch schnell. Die default.lua der MiG21 ist zudem auch sehr übersichtlich strukturiert, was das ganze nochmal einfacher macht, die Funktionen im Programmcode zu finden. 1. Die Datei "default.lua" im Verzeichnis c:/Programme/Eagle Dynamics/DCS World/mods/aircrafts/Mig21bis/Input/Mig21/joystick mit dem Windows Editor Administratorrechten öffnen. Das sieht dann so aus: Die Funktionen sind übersichtlich unterteilt in Gerätesektionen. 2. Bsp. am Umschalter AA-Modus / AG-Modus in der MiG - original code Markiert ist der Teil der zu editieren wäre. 2. Editieren In der betreffende Funktion, muss man nur noch der "down" Position der Schalterstellung noch eine neue "up" Position hinzufügen und diese mit einem anderen Wert versehen: unmodifiziert: modifiziert mit zugefügter "up" Position des Schalters und Wert: 3. speichern und die Funktion für den AA-Modus Schalter neu in den DCS Steuerungseinstellungen belegen. Den AG-Modus muss man nicht mehr neu belegen, da er jetzt automatisch ausgeführt wird, wenn der Schalter aus der oberen AA-Modus Position nach unten umschaltet. Beispiel am Fahrwerkshebel in der MiG mit oberer, mittlerer und unterer Schalterposition: unmodifiziert: 2. nur die obere und untere Position so edititieren, dass der Fahrwerkshebel jeweils in die neutrale Mittelstellung springt, wenn man den Schalter am HOTAS in die Mittelstellung setzt. Die Mittelstellung selbst muss dann nicht mehr in der DCS Steuerungskonfiguration zugewiesen werden. modifiziert: 3. An einem HOTAS Schalter mit 3 Positionen, z.B. dem FLAPS Schalter am Warthog HOTAS, dann in den DCS Steuerungseinstellungen Gears UP der obere Schalterposition und GEARS DOWN der unteren Schalterposition zuweisen. Die mittlere neutrale Schalterposition muss nicht mehr zugewiesen werden. Die FLAPS in der MiG so zuzuordnen geht nicht, weil die Schalter in der MiG etwas speziell sind und jede FLAPS Position der separaten Schalter in der MiG auch eine neutrale Position hat. Die Landelichter der MiG auf einen HOTAS Schalter mit 3 Position zu editieren war auch etwas anders und funktionierte bei mir nicht so, wie beim Fahrwerkshebel.

Das ist ein guter Tipp... muss das auch nochmal alles ausprobieren. Muss mich auch korrigieren zu einer etwas älteren Annahme, dass die PD Einstellung in DCS die Auflösung vorgibt, die von SteamVR übernommen und weiter skaliert wird. Es ist aber wohl so, dass SteamVR die Auflösung vom HMD erkennt und in DCS automatisch Auflösung und Format passend gerendert werden. Die PD ( in DCS, PiTool und SteamVR ) skaliert dann nur noch im Auflösungsformat vom erkannten HMD. Ob SteamVR die PD von DCS aushebelt oder umgekehrt weiß ich auch nicht, glaube aber schon, dass die unterschiedlichen Algorithmen auch unterschiedliche Ergebnisse liefern. Im DCS Hauptverzeichnis ist auch eine steamvr-Datei von Valve eingebettet, die für SteamVR wohl die Grafik Schnittstelle zu DCS herstellt. Ein 180 Grad curved Screen für VR von Samsung wäre schon der Hammer. Und wenn Samsung so was bringt, kann man sicher davon ausgehen, dass es ein perfektes Bild gibt, Plug´n´Play und erschwinglich wird. Das große FOV ist mMn wirklich der nächste Schritt in Sachen VR - es ist soviel besser, als ein eingeschränktes Sichtfeld mit 110 Grad. In der Spit kann man jetzt z.B. die kompletten Tragflächen beim Blick geradeaus sehen. Es fühlt sich sehr viel näher an der Realität an, als mit 110 Grad eingeschränktes Sichtfeld. An Foveated Rendering glaube ich nicht. Das gibt es schon seit Jahren nur als Idee und de facto nicht als angewandte Technik. Lediglich zwei Studien gab es bisher mit Foveated Rendering zu sehen, davon war eine frühe nur 3-D Vektorgrafik ohne Texturen im Comiclook und die jüngste eine vorgerenderte 3-D Szene in annähernd fotorealistischem Look. Beide Anwendungen wurden speziell dazu programmiert, um Foveated Rendering zu demonstrieren. Ob sich ein Foveated Rendering Programmcode auf alle oder wenigstens auf die gängigen Grafikengines anwenden lässt und ob und wie es damit funktioniert weiß man nach zwei Jahren Foveated Rendering immer noch nicht. Es gibt doch immer wieder so spezielle Tools, die in der Idee zwar gut sind, aber nie einen Standard erreichen, weil sich kein Entwickler mit der Funktionsweise seines Programms an eine spezielle Technik bindet, die nicht standardisiert ist und zudem noch spezielle Hardware, wie Eye Tracking Module benötigt. Es gibt doch schon lange ausgefeilte "VR Beschleuniger", wie Lens matched shading, single pass stereo oder VR SLI aus dem VR Works Set von Nvidia oder vergleichbares mit LiquidVR von AMD, aber kein Entwickler bindet sich an einen Hardwarehersteller, wenn er nicht direkt von ihm gesponsert wird, um die Techniken in ein Programm einzubauen. Die Grafikkartenhersteller wollen sich ohnehin nur mit ihren hauseigenen Rendertechniken gegenseitig ausstechen. Vulkan dagegen läuft auf allen Systemen und beschleunigt DSC ohne zusätzliche Hardware. Auch würde es u.a. VR beschleunigen, wenn in Zukunft nur noch HMB2 Grafikspeicher auf den Karten verbaut würde ( wie jetzt in der neueste Radeon 7 ), die die Pixelmenge, die für VR bzw. mit Supersampling hochskalierten VR Bilder schneller und besser abarbeiten können, als GDDR Grafikspeicher. Auch das könnte alle pixelintensiven Anwendungen auf allen eingesetzten Systemen verbessern ohne zusätzliche oder spezielle Anpassungen der Software. Die Industrie macht sich Hypes oder Begriffe wie Foveated Rendering, die in aller Munde sind auch zu nutze, wie jetzt zuletzt in der HTC Vive Eye, indem sie ein altes Produkt mit wenig Aufwand nochmal neu vermarktet, das neue Eye Tracking Feature in der Praxis aber nutzlos ist.

Tatsächlich sehe ich es genau anders herum. Die VR Brillen waren von Anfang an extrem kommerzialisiert. Der Anfangspreis für die Rift war 700,- € ... für ein paar alte Handydisplays und einer Art integriertem TrackIR. Den eigentlichen Clue für VR hat John Carmack mit der API geliefert. Noch schlimmer finde ich das bei Nvidia, die mit den neuen RTX Karten pro Zugewinn an Frames bepreist sind... schon irre, aber eine andere Diskussion. Die Preise richten sich nach der Einschätzung, wie viel die - oder seien wir ehrlich: wir - "Freaks" dafür bereit sind, auszugeben. Aber ram hat schon Recht, dass man nicht jeden Aspekt in eine allgemeine Diskussion vermischen muss, nur um irgendein Gegenargument formulieren zu können. Selbst huppse ich jetzt nicht mit VR Brille auf dem Kopp im Wohnzimmer rum und spiele Luftgitarre, aber für Flug- und Rennsimulationen finde ich VR geradezu prädestiniert. Wie schon so oft erwähnt, stellt VR sehr hohe Anforderungen an die Hardware. Das Dilemma dabei ist, dass DCS, verglichen mit gängigen VR Spielen, noch sehr viel höhere Anforderungen an die Hardware stellt. Glücklicherweise sind die Jungs von ED auch sehr VR affin und mit der Implementierung von Vulkan verspreche ich mir noch den größten Leistungsgewinn, um in VR die Bildqualität verbessern zu können. Und wenn in Zukunft die neuen Modelle (F-14) schon von Grund auf mit Blick auf VR designt werden, kommt es der Zukunft des Mediums in DCS auch zugute. Bei dem Fixed Foveated Rendering, das für die Pimax geplant ist, frage ich mich schon, ob das nicht wieder ein Schritt zurück ist, wenn man doch jetzt ein genial großes FOV hat und riesen Sweetspot bei dem man alles sieht und mit einem FFR dann wieder den Sweetspot so künstlich einengt, dass man sich wieder den Hals verrenken muss, um auf die Backpanels im Cockpit zu schauen; mal abwarten - ist zum Glück auch nur eine Option und kein Muss.