Does Asobo say they have it on their radar? Thats good:)
I found that if you use the holder on the window, use the wheel on the mouse, push the map far out of the plane, make the window bigger and then pull it back, not with the heel of the mouse, but just with your head. Then the map etc. will be much larger.
I’d be happy just to see the Navigraph charts in FS2020, particularly using my HP Reverb VR !!
They worked, once (first time of use), now they don’t show up at all.
Okay thanks Stephen, this helped me pretty substantially, but I will be checking to make sure I can still see taxiway info as the other user reported difficulty there. Thanks for pointing out the scaling feature!
Interesting post. I have a Reverb G2 but after watching recent videos about the Pico4 I am considering getting one too.(4090 & 5800x3d) I fly around Scotland too but generally further South after beating up the Lake district!
Lake District another very beautiful place I’ll try that next weekend. We’re so lucky with all this modern tech!
I had another grea flight using the pico yesterday. Oban to Barra, then to Benbecula heading up to top of Harris/Lewis to see the lighthouse before heading south east ish to Inverness for an ILS landing in typical Scottish weather. The clouds and visibility in general seem much much better now. By the way St Kilda is nice trip from Harris. Very well represented in msfs.
This time I scanned my CAA vfr 1:500k charts and purchased and loaded into sky4sim. Works very well and personally I prefer the CAA vfr charts anyway. Navigraph is such an awesome product but sadly it’s unusable for me now until that miniature text is sorted.
Btw I’m using foveated rendering quality setting with openxr, no upscaling. Most sim settings at ultra, no Road traffic, tlod at 250 I think. I’m using virtual desktop godlike with lan cable to pico rather than WiFi to reduce latency. Steam vr set to 4100 ish per eye. My FPS is about 30 with occasional stutters when looking out the side window and banking. But very flyable.
A belated “thank you” Stephen, for the work-around.
I use an iPad when I am using a screen for the sim, so I can use the setting exclusively for VR.
thanks, this setting works fine
but i cannnot click anyting with the VR controllers ! eg the charts picked at the bottom.
i have to search for the mouse to be able to click
kindly look into this.
very disappointed in Asobo that they destroy VR, no highlighting, nothing. seem nobody uses VR in Asobo.
I agree it’s sad to see how even when Asobo said as I recall it they have a dedicated VR team, there seems to be very little activity from their side in that area.
This a perfect work around for now. Thanks for the tip.
The fix for this as I understand it, if Navigraph wanted to implement it, is to code the element sizing of their UI using em values rather than pixel measurements. Some devs use this as a matter of practice, which is why some apps like Flow did not suffer any VR scaling issues with the SU12 update. I don’t know if Asobo recommends this as a best practice in their SDK or not, but they probably should if they’re going to be changing things.
Overall, Asobo’s change increased the base resolution of VR panels, which isn’t necessarily a bad thing considering how small it was before. It’s also de-coupled from your desktop resolution now, which I think is a good change. The bad thing is that Asobo didn’t tell developers about this before they did it, or make it clear to developers that they should avoid using fixed UI scaling to ensure VR compatibility.
Asobo’s silence on this is also frustrating. No one’s being told by Asobo how to fix this and many 3rd party developers probably won’t fix it because they don’t have VR.
Let’s agree to disagree here.
em units are originally (and still) meant primarily for fonts. Here’s how MDN defines the unit: (source)
To recap, the em unit means “my parent element’s font size” in the case of typography. The
<li>elements inside the
emstake their sizing from their parent. So each successive level of nesting gets progressively larger, as each has its font size set to
1.3em— 1.3 times its parent’s font size.
This, in our opinion, makes the unit highly impractical for layout purposes, where we usually don’t define the width of an element as a percentage of the font size of its parent element or itself. Having this as a requirement is absurd - and we definitely won’t rewrite the whole layout just because of it. Of course, everyone is entitled to their own opinion on CSS units - but this is the opinion of our team.
That said, in a “normal” WebKit browser (which the simulator panel tech is built on) it is possible to determine the pixel ratio of the screen and make scale changes based on that. We tried this early on in development, with very unreliable results. I guess it is likely that we could find something else that we can hook up to our built-in scale functionality, but that is 100% uncharted ( ) territory.
They do not have any documentation on this at all, at least not as far as I am aware. We have to guess everything, from beginning to end.
Rest assured that we will spend some more time trying to figure out solutions for this as soon as we get a moment over to do so, but right now the focus is on restoring Navigraph functionality to the Garmin avionics - also built with technology that, while it is now “documented”, has a lot to wish for when it comes to developer guidance.
We do want to solve this! It is already in our bug tracker, and we’ll get to it eventually. In the meantime - terribly sorry for this inconvenience!
I must admit I did not read the detailed post above, but I can conclude that the original issue of tiny font size in Navigraph graphs in VR has still not been solved, regardless of the elusive solutions above.
I posted a ticket about the issue on MSFS, and this is their reply:
“Thank you for contacting Microsoft Flight Simulator Support today.
We will take this feedback forward but most likely, this is something that Navigraph needs to adjust in their code. We have no control over that application and how it behaves. When we introduce something new with the SDK, 3rd party developers need to adjust their products to work with the latest SDK.”
It appears that the ball is played back to Navigraph, even though they claimed in an earlier post it was not an issue they could solve.
Instead of leaving users in the dark, I’d suggest Navigraph/Asobo to fix this together?
BTW, this is how it looks like: https://youtu.be/c8zaU9jG318
That’s a pretty unprofessional answer, considering that there is no SDK for this. We have zero documentation, and anything can change at any time. If there were an SDK, we’d be know what was changing and would be able to adapt to it instead of making guesses.
The fact is that it did work as expected before a certain simulator update, and does not work the same way anymore. It has changed in an unexpected way, and it is for sure to be seen as a regression in the simulator, not in the panel. In this case, this regression requires us to spend time working on either a complete rewrite of the application or finding hacky workarounds. This is not the first time that this has happened, and it only highlights the fact that we are working in the dark.
Also, the “hacky workarounds” do not really cover the extent of this issue. The panel is rendered according to the environment that the simulator describes, and in this case, the simulator is no longer doing a good job of this it seems. I do not think that we can change this, since again there is no SDK.
I do understand their position on this, and it is unlikely to change. I can see why they would believe that this is not their problem - they did not ask us to make the panel and given the lack of SDK, they have no responsibility to help us. It’s unfortunate!
That said, it’s hard to see from the video but have you increased the zoom to the maximum level? And have you tried this workaround? I think the workaround does a good job of further proving that this issue should not be expected behavior.
At the current moment, we have more pressing issues that have higher priority, especially since there seem to be functioning workarounds. However, feel free to open a new topic in the wishlist section so that we can gauge the remaining interest! That way we can re-prioritize if needed.
I hope this makes the situation a bit more clear. We are always going to be on the lookout for solutions to this and will not consider it a lost cause until we have a solution!
Thank you your swift reply and following up on this. I agree with your opinion on the Zendesk reply. It appears they do not prioritise this issue particularly high, unfortunately.
The video I posted was at the highest map zoom level (it is a bit shaky since I held the headset in my hand).
I have tried the trick with the workaround (moving the window away and pulling it back), but have not really succeeded with this yet. I’ll give this another try. This might help with the font size, but I fear the slow loading of the map will remain to be an issue.
Thank you still for the awesome Navigraph charts, I hope the VR font issue will be solved eventually!
What is the value indicated in the middle, between the - and + buttons? We can always extend the range!
Are you using the Ctrl + N shortcut to toggle the panel?
If it is the interface scale you mean it is on 2.4, but this does not seem to affect map font in any way.
I never use the ctrl-n shortcut (using shortcuts is quite difficult in VR).
I would definitely try to find a way to make the shortcut work! The difference is dramatic. Unfortunately, I don’t think there is a way for us to make it possible to bind it to a joystick button, but that could probably be mapped with 3rd party software?
The maximum zoom will be increased in the next update, but like you say - unfortunately it does not work for the map.
I can confirm using the shortcut to hide/show the Navigraph window makes a world of difference looking at the loading time. Using the shortcut, I’d say it’s instant. Vs several seconds with severe stuttering when initially loading window.
Like said above, can be tricky with shortcuts in VR and trying to find the correct key combination. Especially if you’re under high workload depending on the phase of flight.
What I did was getting myself a Corsair mouse where I can map the buttons etc on the mouse as I please using Corsair’s iCUE software. The mouse even has a built-in tilt feature. Where I can map different keyboard commands or even macros to be triggered when tilting the mouse forward/backward/left/right. Plus of course the same is true also for the various physical buttons found on the mouse.
Really happy with this solution! If you’re interested, the mouse model I got is called Corsair M65 RGB Ultra Wireless V2 but I’m sure there are other brands/models with similar functionality.
It does work, at least it does when using Open XR and the G2. The trick is to left click the mouse on the panel title bar and hold, then pull your head back to bring the panel toward you. Release the mouse and put your head back where it should be. The panel will now be closer to your eyes, and the map text will appear larger. Repeat if not large enough. By the time the map looks ok to you, the panel will be right in your face. Shrink it by dragging a corner in. Then you can push it away. To do this, once again click and hold on the title bar, but use the mouse wheel NOT your head to move the panel backward. It will get larger as it grows more distant, thereby maintaining the magnification you achieved when dragging it with your head. Good luck.