j9murphy

The other cause of ghosting is a framerate lower than the HMD framerate. For example, if your game frame rate is only 50 fps and your HMD refresh rate is 90hz -> the result is ghosting.

For others reading this, there are three things at play... - Objects within the stereo overlap will be 3D (therefore more overlap is better) - Objects which are partially in the overlap and partially not will have one eye see the complete object, and the other only see only part of the object. The degree to which your brain can put these images together varies by person. For some it causes eyestrain and perception issues, for others it's really not much of a problem. Additionally, the more into the periphery that object is, the less likely it will bother you. For reference the fov for the human eye is almost 200 degrees, and the fov of stereo overlap is about 120 degrees, so the last 40 degrees at each side of your fov is experiencing this already and its not an issue. - Objects outside the overlap will be rendered in 2D as @eFirehawk points out, and again the farther into the periphery this is is (like in the human eye), the less likely it is it will bother you. You will only notice these in the HMD as 2D if you move your eyes all the way over without moving your head. Obviously moving your head would move the object to the stereo region. The human eye has a distinct advantage here of being able to move the overlap region with your eye movement. The amount of overlap expressed as a percentage is really not as important as the amount of overlap expressed as degrees of field of view. The Crystal OG and the The Super UW have very close to the same field of view covered by stereo overlap - however, the super has a wider total field of view. Therefore, the super will render objects in the periphery of its field of view in 2D that are not rendered at all in the OG. The tradeoff is this.... periphery 2D vs black. For many people the additional 2D rendering in the periphery will add to immersion. My personal guess is that if the OG doesnt bother you, the super UW wont either.. but again as @eFirehawk points out, waiting for others to try it out is probably best, as long as you understand that any 2 people may have very different experiences and both could be right. The one advantage that the Super UW has over the "lab mode" fov increase that Pimax has tried in the past is that for the Super UW they have physically moved the lenses rather than just trying to deal with it in the distortion profile.

I *think* these are the correct numbers for overlap... Pimax Crystal Super (50ppd standard) ~105 degrees of overlap Pimax Crystal Super (50ppd UW) ~90 degrees of overlap Pimax Crystal OG ~85 degrees of overlap

I've seen others say that performance (FPS) is similar but you get fewer dropouts (stutters) with PimaxXR than with the Pimax Play version at the moment. I was going to to revert back to see if I noticed a difference.

If i'm currently using the pimax openxr implementation and want to return to using pimaxxr from mbucchia, how do i do that?

This could be complicated by the fact that for some aircraft ( I think) the shutdown procedure has the pilot put the elevators down. Dont know what that does to the stick in aircraft without a physical link, but it could be that the elevators are down and the stick is centered when parked? Probably easier to ask former pilots of each aircraft what the stick position is when the aircraft is not powered and if the elevators drop on their own or not.

I tried putting the Crystal on Medium resolution last night.... my conclusions: difference in cockpit tolerable, didn't lose much if anything view out the window (far) also didn't lose a lot, was a little less sharp but also tolerable view out the window (ground under 5000 feet) much blurrier. Pretty large difference here, and not tolerable to me. My conclusion (YMMV of course!): If I were flying a high altitude A/A mission I might use this if I was struggling to maintain framerates, but that's the least likely scenario that I'm going to be struggling. For A/G missions, Helo missions, or anything where I'm flying low, this was a step backwards and not one I would not use medium for. My personal preferences only, everyone has their own sweet spot!

interesting to me that you chose to optimize your settings with render quality set to medium instead of high. Are others with 13900+/4090 doing this?

Most of you probably already do this, but I'll put it here to help others out... Before I start DCS (or any of my flight sims) I bring up windows task manager and check the overall cpu and memory. For my system, I should see an average processor utilization across all cores (first column) of about 1-2%. If it's higher than that, I know something is running that i need to kill. I sort the list by cpu to see what needs to terminated or closed. Memory on my system should be about 15%. The thresholds you use will vary by a variety of factors, but I probably find things running that are either consuming more cpu than normal, or shouldn't be running at all about a third of the time. Sometimes its a windows process and you just need to wait it out for it to do its thing and quit. This helps reduce variation of performance between sessions and keeps me from chasing my tail because I think the sim has changed in some way, but really it's my system. Because VR is so sensitive to CPU interruption, this helps ensure that the game is getting all it can.

I have a 4090 and 13900k and find that QVFR is a huge improvement to fps without creating stutters or a CPU bottleneck. Just goes to show how many variables and personal preferences are at play here. There are literally millions of possible combinations of settings and software in VR and then we have variation by map, mission, aircraft/helo etc.. I finally quit chasing settings as im sure many have. i found something I could live with that provides a little head room and just tolerate the variations and focus on the mission:)

Are you using Windows 10 or 11?

actually that didnt fix it.. I had to change the behavior of buttons that remain "on" to be momentary like a button. For example the gear lever had to be changed in the virpil config to Toggle On instead of normal. It seems that holding a button down like that was confusing gremlin for some reason...

I added a delay in the virpil config and that fixed it..

I'm getting strange behavior in joystick gremlin with both my control panel 2 and cm2 throttle. For example, the landing gear lever does not always return the same physical button to gremlin even though the virpil configuration (and tester program) show the correct values. Anyone have any idea what is going on?

thanks, I'll open up the throttle and see how hard to swap some out might be.

is there a straight forward DIY way to replace some of the on-off-on momentary toggles with latched toggles on either the CM2 throttle or control panel #2?

Does this fix the necksafer problem with eye tracking?

@trev5150 Maybe you could help us all understand your position by articulating your argument in more intelligent terms that are relevant to the discussion, rather than just in rant form? I'll make it easier for you, in fact, I'll even help make your point more clear so that others can better understand your position. Which assumption(s) below are you challenging? TelemFFB is Software by Walmis which is protected under the GPL license Moza created a derivative work from Walmis' software Moza must credit the original work and release source code for their derived work under the terms of GPL License

Well, I tried. A Mark Twain quote comes to mind here, but I wont bother... From the license itself.... 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) So why is Moza prohibited from publishing the source code?

maybe you could explain what the relevance is of "code based libraries based on the embargoed IP from the patents that just expired" to the issue that Walmis brought up? Walmis is not asserting a patent was infringed on, he's stating he owns the copyright to the source code and has chosen to release that source code under GPL (not making it "proprietary", that was your word not his). GPL requires that the source code for all derivative works must also be released into the public domain. Walmis asserts that there is evidence that the source code was copied , and that the derivative work by Moza was not placed in the public domain as required. He didn't threaten legal action, although it would be within his legal to right to do so under copyright law since he is the copyright holder, and since gpl is a license not a contract - which is an important distinction in many countries where IP is concerned. This brings us to the question - is copyright law in once country enforceable in another country? Maybe, but there's a lot to unpack there, and its beyond the scope of this conversation. Looks like to me that Walmis has chosen just to call them out with the hopes that either 1) Moza will release their source code into the public domain so that we may all benefit (the original intent of GPL), or 2) that people think twice before purchasing Moza FFB hardware given the likelihood that they infringed on his license. I tried my best to give a thoughtful response to your 3 posts, so that you might have a better understanding of the issue. Hopefully, that has happened:)

You clearly dont know what you're talking about:)

I've changed my approach somewhat to avoid chasing settings all of the time. I put the settings into 2 categories - things I change and things I don't:) Things I've decided not to chase anymore and I just leave them... DCS PD = 1.0 DCS Graphics Settings - don't have them in front of me, but I have set and forgot most of these now DLAA only NVCP = Everything default except "prefer max performance" is set PimaxPlay Resolution = Best Pimax Refresh = 90hz Quadviews = set according to my liking (dont have those in front of me, but 100% in the middle, 10% at the edges OXRTK - no longer use PimaxXR - no longer use Things I will tweak not much any more. If a mission or something in DCS is performing poorly, I'll just drop to 72hz and leave everything else where it is. Honestly I rarely have to do this. This means more time flying and less time chasing settings. I don't run a frame rate monitor anymore, and I don't compare version or driver performance differences. Honestly, the crystal is good enough for me going forward for some time I think. I'd rather someone fix cockpit interactions in VR (for all flightsims, pointctrl isnt bad for dcs) rather than send me a new headset.

I've gotten necksafer to work with the latest versions of everything, however once necksafer kicks in the foveated rendering seems to stop working. Most of the FOV is blurry as if they eye tracking is no longer synched with the view or something. Can this be addressed?

For me this issue goes beyond the shuttle on the carrier. I also get bad spikes for a short time (mainly in sway) in multiple aircraft... when I spawn into an aircraft on the ground (occasionally) when an aircraft goes from a standing still to starting motion (all the time) when attaching to the shuttle as described in this thread (This actually worked in the f18 just now when I tried, yay!) The first two can be masked with filtering but then you lose the fine details in the motion like the landing thump and the "violence" of the cat shot itself. Do others see these spikes as well when not strongly filtering? Maybe its time for a motion platform sub forum:)

thanks, do you know how that setting interacts with VR Pre-rendered frames? VR Pre-Rendered Frames: Low Latency: