Rosebud47

Could confirm that the depth of the picture appeared less in the Pimax, than in other HMDs, but after managed to adjust the eye-lens-distance by adjusting values in the stereo.lua the depth in the Pimax could be corrected as it should be with no disadvantage in comparison with other Headsets. The Pimax offers a lot of potential, which could grow with optimized hard- and software to deliver the images to Pimax´panels. You could already crank up the image in the Pimax to a phenomenal quality, but it is with current connected hardware unplayable regarding the perfomance. Me too awaiting some after market products from LensLabs and VRcover to make the Pimax more comfortable. But there´s also a nice thing with the large field of view, if you regularly need glasses to correct a short-sighted view: the large field of view puts the image of the panels more close to the viewport. HTC Vive or Samsung Odyssey viewport is approx 1 - 2 meter from the eye to the virtual world. With the large FOV this distance is closer an could(!) make wearing glasses under the Pimax obsolete. It depends on the person and personal grade of short-sightness.

Kegetys´ mod I don´t use. You´re right, choosing between different zoom factors adds something to the setup. In my observation, the zoom speed depends on the frametime, the lower and better the frametime is, the faster and smoother the speed of the zoom is. The nausea effect while zooming results of not optimized performance of the system. Maybe zooming is kind of stresstest for VR nausea effect. In anyway I wouldn´t like to miss this zoom effect - it´s a great feature for VR. Another advantage, more in practice than theoretically, with the zoom speed is, that you could keep focus and concentration to the poitn you´re looking at - it really feels better to me, than an instantly change to a zoomed in picture. Parallel Projection I don´t use. As I understood, it is only meant for VR games, which does not support the regular way the Pimax works. DCS does support the Pimax really well; surely there are issues, like the VR zoom with the Pimax at the moment, but it is like some cockpit functions , which became buggy through the weekly patches. As far as I could have read, Parallel Projection in the Pimax, will push the performance significally down, what should be avoided in any case. The introduced flickering light stripes at night of lightend areas on the ground were observe by a regular glance out of the cockpit, not while zooming. I didn´t had a look yet to the label masked thing. Actually I avoid labels in the cockpit as far as it can, but for the Doorgunners in the Huey, I have mapped a key to activate the setup label for the doorgunners and deactivate it, once the setup is done. Will have a look on its appearance on my system with the mod next time.

Hi lefenuste, a quick feedback on the mod: It´s now a bit difficult to give you feedback, as the effort to fix the VR zoom with Large FOV headset is more than appreciated and there is also much respect on your work and ability. The convergence with the (VR-) zoom with Pimax Large FOV mode is not right at the moment, as it shows a different image on the right eye right side of approx 1/4 of the zoomed in picture. I did use the user_keymapping.ini you´ve provided for the Pimax large FOV. But a mayor issue with the (VR-)zoom was for me, that it instantly shows a zoomed in picture and that you need different keybindings for each zoom-level. With regard to keybindings, it is a quite important issue, cause the buttons on the HOTAS are already very limited and it didn´t work to spend 4 buttons on the HOTAS only for zoom. More important than the keybinding is, that the zoom-levels show instantly. I didn´t thought, while reading your description, on how the zoom mod works, that especially this circumstance became an important issue in practice with the mod and you may say, that the result in zooming with the mod function is the same as the original DCS zoom. Zooming in in steps feels not as natural as zooming in with an analogue transition through the 3-dimensional space, like everyone is used to with zooming in with cameras for instance. Also it could make you feel disorientated zooming in with steps compared to the original smooth transition due to zoom with the original DCS zoom, which feels much more natural and practical. Mostly I need the VR zoom to read the detailed information on the HSI in the Tomcat or the MFCDs in the Harrier or the smaller gauges and button labeling and positions in every cockpit. Hopefully DCS developer could fix the broken VR zoom with Large FOV VR HMDs, as it feels that there is only needed some adjustment with the VR zoom not an entirely different zoom function. With regard to the cockpit lighting, I´ve mentioned before, that with the mod, it looks like restrained illumination of the panel background lighting with the mod - maybe I came to the statement because of good and positive will to support the mod and looking happily forward to an expectation of improvement, but lastly, when I removed the mod files and stepped back into the cockpit, the panel background lighting appeared pretty much the same to me as with the mod installed. Never felt a need to adjust the cockpit lighting, as was not broken and if so, I used to adjust by Gamma settings in the DCS system menu or brightness with the Pitool settings. Same for the label masking, never felt the need for a fix on it, as the label masking is fine with unmodded DCS. When flying over a city at night, I could have observed flickering stripes of light on the ground with the mod, where are light of houses and street lamps, which appeared as well on the right eye, right side of large FOV. I think it appeared because of a general convergence issue with large FOV. Please don´t feel demotivated by my findings, but I´m actually looking to give constructive critique back. In anyway une grande merci beaucoup pour toi for having a look inside the VR zoom issue we are facing with the Pimax. Please don´t hesitate to put out a more elaborated stage of your mod to more meet the users expectations on the mod.

First of all, none of the new VR Headsets is really bad, they are all better than the first generation of VR HMDs and sooner or later there will be even better HMDs maybe of new competitors. The infrared tracking system technology of the original Oculus Rift seems to be no longer used in any of the new VR device. So there is only left Inside-out-tracking with front cameras and no additional external sensors ( new Oculus device and HP Reverb WMR ) or the Lighthousetracking system with external sensors ( Valve Index, Pimax ). Beside these two tracking technologies, there are three platforms for the HMDs: Oculus, SteamVR and WMR ( WMR API is intergrated into Windows 10 OS ). All WMR headsets are compatible with SteamVR and DCS through an additional SteamVR for Windows Mixed Reality App, which is for free and easy to handle, but combining the two different tracking technologies, lighthouse and inside-out-tracking, is generally not supported, as they work in different ways. But there is a way to combine Lighthouse tracking technology for the Handcontrollers with the Inside-out-tracking technology for the headset, but it is not easy to setup. You need to have the Lighthouse external sensors for tracking the handcontrollers in anyway. Then you need to run both APIs in parallel, which is generally not on purpose, but could be done. Then you need to align the localisation of the headset with the localisation of the handcontrollers through different tracking methods, which is the hardest thing. This is really not recommandable in anyway. For DCS you can´t do it wrong with any of the new Headsets.

Sad to hear that, but it is no indication for the quality of their product. Promoting specific hardware providers may result into separating DCS Pilots into different camps. Implementing Vulcan is fantastic and follows a philosophy to provide advantages on every system, independent of hardware brands.

Thanks for clarification and the Video link - love these guys from Tested.

Unexpected performance improvement? Didn´t you mentioned before, that you get plus 10fps with the mod (...)? I could have get average 4ms plus in frametime with the mod, which is great. What exactly is meant by ´label masking´?

@itarrow You´re absolutely right! The price tag for the headset only looks quiet moderate and not such overpriced like the HTC Vive Pro. I wonder if they have integrated Inside-out-tracking with the two frontcameras, otherwise the frontcameras are more or less useless. If the Index could provide Inside-out-tracking alternatively, it will be best buy for first time VR buyers.

The specs of Valve´s Index sound very interesting. Especially the 144Hz mode for panels and the lens technique the Index uses. Both seem very promising for a generally improved VR experinece. Of all VR HMD provider Valve is surely the most innovative one. The index was in developement since two years minimum and I believe, that Valve focused to invent real improvements for the benefit of the VR experience. Resolution and FOV seems to be like current standard, but the new inventions the Index comes with, sound very promising. A 144hz mode surely could improve image quality, maybe reduce shimmering massively, which is a common issue of VR visuals. But running the panels in 144Hz means the GPU needs to create 72 FPS*2 real frames with reprojection for optimum 144Hz mode, which is even for the most powerful PCs very challening with DCS. Let´s see tests, but I would bet, the Index will leave the other new upcoming HMDs behind with regard to potential image quality and flexibility.

Hi lefenuste, had yesterday the chance for a first look in DCS with your mod. Only took a flight of 10 minutes with the Huey and Tomcat each, but with both have measured an improved to performance about 20% in frametime. Very good improvement. On this first glance everythings looks very good, maybe even better as unmodded. The panel backlight in the Tomcat appeared more restrained in VR, which is also good. But need more long time testing with different scenarios to tell more. But the perfromace improvement is right there. Not came to test the VR zoom yet - looked quite comcplicated and don´t know, if I can map the VR zoom to my HOTAS. In regular, I actually try to avoid installing mods, which reconfigures the graphics engine, cause I´m always afraid, that the mods will break common original graphics features of DCS, while improving particular graphical features. Your graphics mod is the first I ever installed ( beside cockpit mods, sound mods, etc. you could download from the DCS main page ). Also there are worries, how things go with the mod, when there are updates to the graphics engine by ED or graphical updates to the cockpits by the developer, but we´ll see ... In anyway a big thanks to you, also for the user_keymapping_zoom.ini for large FOV. Will try it out and talk about it here. It may be interesting to split the mod into 2: one for the graphical/ performance improvement and one to fix the VR zoom issue with large FOV only.

De ne rien! Je sais, que j´ai besoin overclocking le CPU. :)))

That´s exactly what I think too. Yesterday night just run DCS with Pitool 2.0 and SteamVR SS 20%: The image quality was really good! To get an impression of the image quality, I used to focus on a specific shimmering line in the cockpit and observe the aliasing and strength of shimmering with different supersample settings. But with Pitool at 2.0 or even 1.75 the performance drops to approx 24ms GPU frametime on my system. My experience is, that everything above 20ms frametime, there are stutters and a strong ghosting effect - I need to have a frametime of approx 15 - 17ms to get a smooth experience. But I also need to say, that my CPU is currently running with default 3.4 GHz, since I set the Bios back to default some weeks ago...definitely need to overclock the CPU again ... Also I need always MSAA x2 in DCS menu to eliminate strong shimmering. I think, if you got a really powerful CPU, System and GPU Pitool at 2.0 and SteamVR SS at minimum SS setting is a good choice. Unfortunately Pitool doesn´t have space in the rendersettings for more finetuning, but SteamVR SS could be scaled in small steps. So I switched back to Pitool 0.5 and SteamVR SS at 150% DCS MSAA x2, DCS PD 1.1 to get a enjoyable frametime below 20ms on every scenario with large FOV. There are always some peaks up and down in the frametime, but not really perceptible while flying. btw. I won´t go back from the large field of view to a smaller one, which surely is a tradeoff with performance - but I love the feeling of flying, speed and situational awareness in the cockpit with large FOV. :)

Hi Lefenuste, yes, will test your mod and follow your instructions, files and lines you´re pointing to make the VR zoom work again. Will write you back this week. I´m hardly looking for a working VR zoom with the Pimax in DCS, but tested another very nice improvement for the visual quality of DCS with the Pimax in the last days. Let me put my findings a bit separate, but inbetween our discussion, so it could be easily followed up by everyone. Regarding Pitool and the Supersampling process, we could only try and error to find optimum settings. The whole VR thing is more or less a black box, when it comes to specific interfaces. This is mostly because there´s not yet one standard for all VR devices. Currently we have three companies fighting for standard and first place in the market with standardized interfaces for VR ( Valve, Facebook and Microsoft ). It would be easier, if the Pimax could be connected directly and only via SteamVR compositor, but the Pimax functionality and interface is still in developement, which makes it far away from any standard, like SteamVR is handling. I had long time setting in Pitool of 1.75 and in SteamVR SS 40% to get a flyable performance in DCS and quite good visual quality. Please correct, if I´m wrong, but in my current understanding the setting in Pitool defines a request on renderresolution. At Pitool 1.0 the requested renderresolution is already much higher, than the native resoultion of Pimax panels. I´m not sure how much of this requested resolution will be finally visible in the panels or just being over the panels edges in a non visible area, but on cost of performance pixel filling rate of the GPU. I think, the renderprocess starts at Pitool with a defined request through Pitool settings for the renderresolution, then the request is grabbed by SteamVR as the interface between DCS and VR device through openVR API. With set SteamVR at 100% the request given by Pitool is not changed and forwarded to DCS graphics engine. But if the request is already supersampled by Pitool, any additional supersampling by SteamVR ( e.g. 140% ) effects in potentialized supersampling process. Not sure if this procedure is really good as it must be a lot demanding to the GPU with less effects on the perceptible visual quality. When the supersupersampled request reaches DCS, there could be done additional supersampling through PixelDensity of the image the DCS engine creates for the request. In my understanding, DCS PD really supersamples the image in the way of increasing the pixel density of a resolution defined image, whereas SteamVR and Pitool supersamples by resolution only. ... I don´t know, but would be glad to have a common understanding of these processes, to better optimize the settings. Anyway, take a look on some new settings which corrects the tangent space of the Pimax with large FOV mode. Maybe the corrected values could also support the VR zoom issue with Large FOV HMDs. _____________________________________________________________________ Tangent Space ("eye-to-lense-distance") correction for Pimax with Large FOV mode By correcting some values at DCS´ stereo.lua file, the geometrical shape of objects in DCS could be corrected and the 3-dimensional effect with the Pimax in Large FOV mode improved. Please follow the source link in the end for further explanation. The stereo.lua file could be found in DCS main directory: ../Eagle Dynamics/DCS Open Beta/Config/MonitorSetup The values in the stereo.lua file has to be replaced by following colored ones for Pimax in Large FOV mode: _ = 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 = 1 / 1.62; eye_shift = -0.032; --tans of side angles projection_bounds = { left = -2.769231, right = 1.346154, top = 1.269841, bottom = -1.269841, } }, Right = { x = screen.width * 0.5; y = 0; width = screen.width * 0.5; height = screen.height; viewDx = 0; viewDy = 0; aspect = 1 / 1.62; eye_shift = 0.032; --tans of side angles projection_bounds = { left = 1.346154, right = -2.769231, top = 1.269841, bottom = -1.269841, } } } UIMainView = { x = 0; y = 0; For Pimax with normalFOV mode mode the values are the same but for left eye: left = -1.742203 and right eye: right = 1.742203 This effects every geometrical object, like switches, cockpit interior, canopy, cockpit itself, clouds, trucks, buildings, hills, mountains. Don´t know, if the aspect ratio in lime color is setup correctly, but followed the advised value from the source: https://forum.pimaxvr.com/t/all-the-different-fovs-of-pimax-5k/16053

The Lighthouse tracking system, which came along with the first HTC Vive was an invention of valve and licensed to HTC to be sold together. The Lighthousetracking is the most advanced tracking system with regard to precision of tracking the headset and controller or other trackable accessories. Also the original Lighthousetracking could cover a bigger roomscale than any other trackingsystem. Valve´s Lighthouse 2.0 tracking system could cover an even more bigger area for room scale tracking. Surely Valve wants to license their tracking system to more VR Headset manufacturer and wouldn´t concept a Headset of their own, without their own Lighthouse tracking system. Surely for us simmers a such advanced roomscale tracking system is not really needed.

Have got the newest Pitool Version 121 Beta FW 211 installed. Also tried the previous Pitool version 112 and the according firmware, but there was no difference for me between these two Pitool versions. Yeah, I think it´s right to get nearly the same performance if running Pitool with a rendertarget of 2.0 and SteamVR SS set to 20%. But I also think that downsampling is always accompanied by a loss of image information/quality, respectively subpixel information. The Pitool setting rendertarget 1.0 is already upsampled, as the resolution shows in SteamVR with 100%. My approach was to come as much close to the Pimax´ native resolution without downsampling and loosing image quality. Pitool setting 0.5 is a bit below native resolution of 2560 x 1440 but closer to it than Pitool setting 0.75. Maybe it´s more advisable to set 0.75 in Pitool to not undergoing the native resolution and to get most picture information/quality out of the basic rendertarget setting before supersampling it with PD in DCS VR menu and SteamVR SS override. It´s difficult to discuss image quality, as image quality always lies in the eyes of the observer, when it´s about nuances. Also other factors on different configurations might influence the image quality and performance, so finally everyone has to find settings by his own, which satisfies most. But finding and sharing ways to improve performance and image quality is something worth to share with everybody in my opinion.

Welcome! Now the only thing needed is the Spring Update for the MiG21, Black Shark Cockpit Update, VR Optimization for the terrain and Vulcan API. :) It´s difficult to proove the effect of an edited stereo.lua, as it depends on subjective point of view. For me I found the picture clarity in the Pimax slightly better, than with the original stereo.lua. Anyway, there´s a ´steamvr.dll´ file somewehere in the DCS folders, which correspond back to steamVR to demand the correct resolution from DCS game engine for the particular Hedaset connected via steamVR compositor to the computer. But defining precisely the resolution and aspect ratio of the Pimax within the stereo.lua doesn´t hurt. The editing in the stereo.lua does effect the graphics in VR. How much and if within visable range, has to be decided by trying. Anyway it could be simply copied back the original values and everything is fine. So I could have adjusted my real IPD within the stereo.lua, which is 32 for left eye and 31 for right eye ( in total 63 ).

Just made a very nice experience I´d like to share. After installing the new Nvidia driver, had some fiddeling around with all settings and came to the conclusion, that the settings in Pitool are not good. Pitool render setting at 1.0 actually renders far to high and SteamVR SS need to be pushed down to 40% to get close to the native resolution of 2560 x 1440. So I finally set the Pitool Rendertarget to 0.5 and SteamVR SS to 140% to avoid any downsampling through SteamVR and come close to the native resolution. Meanwhile I think most of the Pitool Settings are crap, like fixed foveated rendering and the render target presets. Somehow the PD adjustment in DCS VR menu does not show in the SteamVR SS override resolution calculation. But the rendertarget settings of the Pitool shows in the resolution of SteamVR SS override. My thought was to keep the upsampling process on side of SteamVR, not Pitool, so final settings are now: Pitool everything off except smart smoothing on. Pitool Rendertarget at 0.5 SteamVR SS at 200%, which results in a render resolution of 3018 x 1861 pixel DCS VR menu PD at 1.2 as it is really good to sharpen the image and get rid of most of the shimmering. These settings are a little bit too high at the moment but in result the image clarity and sharpness is really good with very less shimmering compared to other settings. Flying with the Tomcat at 10.000 feet into the sunset over Nevadas Mountains was just breathtaking. The performance with these settings are much better than with Pitool rendertarget at 1.0 and a downsampled SteamVR SS. With the Tomcat, the MiG, and Huey I got very solid and stable 36 FPS @72Hz and a smooth experience left and right outside the cockpit. With all three models the GPU Frametime was between 15 and 20 ms. With the Huey NOE flight the frametime was a bit over 20 most of the time. A low level flight with the Tomcat and the MiG over the Strip in Las Vegas also pushed the average frametime a little up, but once past the Strip and flew up or to Nellis, the frametime gets back to 15-17ms. The optimum frametime in VR is 11ms, so 16ms are really good for DCS, I think. So my recommendation would be to set the render target in Pitool at 0.5. Then the PD in DCS VR menu set at 1.1 or 1.2. A PD setting in DCS VR menu to 1.3 was too much too handle. Then set the supersampling override in SteamVR between 140 - 200% depending on to your system/GPU. Then only adjust the performance within SteamVR SS setting. System: 2080Ti Pimax 5k+ @Large field of view, 72Hz, smart smoothing activated. Contrast +2, Brightness -1. DCS stereo.lua edited, Nvidia 430.36 settings all to default/application controlled.

The Odyssey I used to have connected to the VL/USB-C connection via a Microsoft HDMI to USB-C Adapter. My subjective impression was, that the colors in DCS became more vivid. For the Pimax I bought the same Microsoft DP to USB-C Adapter, but the Pimax couldn´t connect through the USB-C Adapter/connection.

thx, found it :)

@cromhunt thanks for your solution. Is it possible to upload the working JesterAI_Page.lua file into this thread, so we don´t need to roll back and forward again, but simply download your file to replace it?

Yeah, just some thoughts in hope it could help. Another infrared emitting source interfering with the tracking system is really far away from a common solution, but wouldn´t exclude the possibility entirely. Anyway if other possible source of errors could be excluded, then I think you´re very close to a solution when looking for a power issue. I´ve preordered the Vive instead the Rift, when it first came out and installed it into the living room. The Lighthouse Sensor boxes were connected to the power net in the living room instead to the USB connectors of the PC. Everytime my wife came in and switched on the lights in the living room, the tracking in VR jumped into another position. For the peace in the family, I´ve moved the VR setup into another room. Meanwhile only DCS is running on the VR PC in the simpit. But the tracking system seems to be very sensitive on current fluctuation, ... maybe it was the light of the bulbs interfering with the laser tracking , which caused this issue. Since I got a 2080Ti, I was running again into a power issue, as the RTX card is much more power demanding than the GTX cards. Beside HOTAS, Pedals and additional periphery with the simpit, the newly Pimax 5k caused problems by lack of power. Deselecting in the windows option the windows controlled power saving option for the USB HUBs didn´t help and finally I had to replace the 700watt gold power unit with a 1000watt titanum power unit, which finally solved the power issue. But please don´t blame on me, if you´re going to invest into a bigger PU for the PC and your problem is not gone. :) With the Rift sensor setup, there are many users reporting, that the many USB connections needed could cause issues. People tend to setup up the Rift with an additional USB card ( which also demands some power of the PU ). Still just a few thoughts on sources of errors with the tracking system, but I´m pretty sure, that the tracking issues are not directly related to DCS. Hardest thing would be to reproduce the error, in order to check if the problem still exists after doing some changes to the system ...

VR zoom is currently not working properly with Pimax, whether with or without parallel projection. Also tried different IPD settings in DCS setup and in the stereo.lua file, which is the same, but without effect on the VR zoom issue. Also tried different values of the image bounderies in the stereo.lua, like it could be adjusted with a workaround for the Odyssey cross eyed effect, but as well without any effect on the Pimax VR zoom issue. Hope someone finds a solution sooner or later.

Exactly the impression I get, when VR zooming with parallel projection activated. BTW parallel projection isn´t really needed for DCS, luckily, as it is on cost of some system performance.

As the problem described in the thread, it seemed like when the tracking system looses tracking for a second, the tracking setup jumps back into a default standing position of the HMD until it could get back the tracking and tracks correctly. For the Lighthouse Laser Tracking System, mirrors or reflecting surfaces like glass wndows in the area could also interfere with the lasertracking. For the Inside-out- tracking of WMR and also the new upcoming devices with inside-out tracking, planar surfaces like walls without furniture or something the inside-out tracking cameras could get fixpoints from might disturb a proper tracking of the device. For the infrared tracking of the Rift, there might be other infrared emitting sources, like remote controls or something, which might interfere with the tracking system... I don´t know, but would have guessed, that the floor level for the HMD tracking is ´jumping´ for some reason.

Sounds like you have Fixed Foveated Rendering in PiTool activated?