This was not for the relaxation
I can fully feel with you. I've watched three figures of hours of random tourist videos to look for visual clues, details and textures for PHNL. 
Posts by Kisvakond
-
-
IMHO FS 2020's scenery solution is good for adding procedural/AI detail where there's not much detail in general, but POIs, especially airports will still need a grade of input even detailed sources like google earth doesn't provide (e.g. side walls or smaller details for side of buildings).
I had to watch countless hours of tourist videos to get even a rough idea how airport buildings look like. I highly doubt MS will provide DLC grade of airport or POI fidelity as vanilla content.
-
Flying an IFR route makes the upfront predictive work easier but with VR, where users like to do more sightseeing, predicting becomes much harder
Well, prediction does not happen about what you would like to draw, but rather how and when. Nevertheless, speed comes handy when you have to render twice as many images than you used to be.
It's also important to assess if stuff is covered by other stuff and discarding it as early as possible. -
...
Vulkan, Metal and OpenGL are just API's used to communicate with the GPU, but the real performance improvements for software comes when the programmers understand where time is spent and lost on the GPU, which is not solved by simply switching from OpenGL to Vulkan.
This is why initially, video game programmers tried to stay away from explicit APIs. They already had something that worked and did not wat to invest the effort and resources to understand how their renderer works. On most video games, the first implementations were basically wrappers (doing the equivalents of old gl or dx calls with minimum effort) which were usually disasterous, delivering the existing performance at most while also bringing in bugs. So it seemed that it's a high-risk low-reward thing, which otherwise could always be solved by telling the user the buy more powerful hardware.
This is perfectly normal human gut reaction: I want to make a game, not understanding how the computer running it, works.
Using an explicit APi is also a good way to identify CPU-side bottlenecks, because OpenGL (or DX11) is black box where we put out wishes in and somewhere, sometime, something, will happen. It does not know why we are issuing a sequence of wishes thus it tries to guess what we wanted (that can result in e.g. re-compiling shaders between two frames) and we also don't know for sure if e.g. our operations will commence in the order we put it in.
If we want it to succeed, we have to give it our main thread to make sure it can work and wait without blocking anything else.
There is a minecraft clone on github which was done via OpenGL, interestingly, all in plain ANSI C language (no C++). It took me a while to read it and understand what's happening on the OpenGL side.
Then I realized there's a devbranch forking off of it, the same minecraft clone but on Vulkan.
It's a perfect demonstration how badly I had no idea what the OpenGL calls tried to do in the black box.
BUT! After I have understood what I have to do/re-do for each single frame, these patterns were starting to re-appear in all other Vulkan demo codes and projects I was taking a look at!
-
The A320 uses different engines (turbofans) which cannot be shut down yet. So no, not with the next update anyways. Shutting down turbofan engines is high up on the to-do list though, which means that, fingers crossed, the A320, B737, B747 and Learjet 45 will get their full engine simulation with shutdown and restart soon.
A lot of the systems that depend on the engines have already been added. That means as soon as the A320 for example gets the new engines that can be shut down it will be able to reach cold and dark status. And so does the Learjet.
I understand, thank you for the info!
Balazs
-
It seems it is best for us to push out bigger updates every couple of months. A lot of the upcoming aircraft system I added I programmed in my free time or when they were gaps at work that allowed me to continue and I collected them all over a period of several months and now I think they should be "finished". And by finished I mean at least stable and not super buggy, though not complete but a good first step. Not to mention the other great stuff I worked on full time but you'll have to wait a bit longer until we reveal that.
A big batch of my code was just merged into the our internal tmd developer executable, that's pretty good but not yet the final release version. Not sure when that will be merged... but yeah one of the things is the baron getting engines that you can turn off.
Hello. Arriving late to the party, will these updates also include engine system updates for the A320 as well?
Thanks
Balazs
-
Yeah, it's a pity that Logitech only allows to combine the throttle and brake axes, especially that the factory brake pedal is so hard. Even after removing that 3 cm hard rubber piece that Logitech expects you to flatten out with around a good 40-50kg, you still have a significant difference in pedal stiffness.
Btw the Logitech G-series pedals have some mechanical deadzone , which will make fine movements tricky (as you don't feel where rudders starts to work). Not necessarily a problem in AFS2, as one does not have to use the rudder to aim with the guns, but be aware.
Oh, I forgot to mention, that the input Axis Stick number may vary on each computer/setup (hooking up the very same controllers on a different computer at home will result in different numbers). It's probably due to USB device enumeration sequence being something pretty much unpredictable. So if you have a working setup saved on a different computer/installation, you'll most probably have to try the number until you find the input stick that has your pedals and save again.
Once again, we should ask IPACS nicely, to introduce options to combine (any) axes of (any) controllers (including some basic invert/add/slider etc., options), like in e.g. DCS World. Please?
-
Hello,
After setting up the UCR and installing vjoy, do you actually see the output preview in UCR moving, as well as seeing the VJoy axis moving in the Game Controllers list?
For me, Vjoy never gets to install correctly at the first time, hanging in the installer forever, directly at the end of install. When I shut down the installer, it will say 'success', but it will not work, due some failed registry change (UCR will also notice). But if I just plain reinstall Vjoy, it will start to work.
Make sure to restart windows before launching UCR again. You can also expect that UCR might not save your plugin choice so it will not be 'remapper' (but code runner), thus again, it will not work until it's selected manually again. Homebrew drivers/installers + not overly tested GUIs + windows10 = bah
.The chosen Output Virtual Axis is basically irrelevant, just make sure it goes to vJoy Stick 1 (assuming you only have one virtual joystick). I've just picked Axis 4 to try to make sure it will not interfere with stick-like axes coming the HOTAS.
Should you see any cross-axis movement in the Game Controllers->Properties preview, just make a calibration and only move the pedals when calibrating the axis you picked as UCR Output Virtual Axis.
Hope this will get your setup going!
Cheers
-
-
That 6x performance applies to real-time raytracing performance. Based on other stats like memory size, speed and execution unit count, it can be still a remarkable improvement, but only if the host PC is able to feed the GPU to 100% (and if someone was actually planning an upgrade). The faster GDDR6 of the new cards allows shorter frame times assuming the same host system (CPU, memory etc.), also the higher CUDA core counts will yield less rendering overhead. Shorter overall frame rendering time will translate to higher frame rate with higher CPU load (that is, if the CPU couldn't have fed the 10-series card to 100% GPU load already), but for rasterized graphics, nowhere near 6x times.
Remember, all we know about these cards are only specs NV states. We have yet to see real-world performance in raster mode. Also keep in mind that when dealing with GPU manufacturers, some of the things they say turns out to be a lie. Sitting on raytracing hardware with no actual real-world applications is not the best investment IMHO.
-
IMHO relying on real time raytracing on a flight simulator is a huge gamble as this technology is not yet adopted by anybody and only pushed by Nvidia to push AMD and game devs. Knowing the performance penalty of the non-raytracing cards, AFS2 would risk one of it's key selling point, namely the decent frame rate.
Since AFS2 apparently aims for the casual VR flyers and not hardcore simmers (I'll revise my stance when all stock aircraft is system/feature complete, most of you know what I'm referring to), realtime raytracing would be a high-risk low-reward goal (VR needing twice the juice). Remember, this is a feature Vulkan can't compensate or raster cards. Flight simulators like these can't provide a visual fidelity,in general, that would benefit enough from RTRT (to counter the massive performance drop on cards you can still buy new for a fortune), which could not be done rasterized. Shading is a problem that can be and has been solved in most of video games and simulations, so finding a hardware solution to a software problem (flickering shadows) is IMO not the way to go. Not mentioning that even if one thinks that getting a Turing card is enough, the PC itself might have to be upgraded as well to feed it.
Going over to RTRT would cause a massive decline in user count.
-
Hi all,
Now that I'm testing the new releases I wanted to try out my hotas and G920 pedals for rudder. I have the issue that if I'm using the clutch pedal for left and gas pedal for right rudder, the center will be off in one direction, making the aircraft yaw and extreme rudder correction is needed to counter. It is also seen in the menu that the rudder position is confused after giving one axis as 'left' and the other as 'right', the center position being way off center (depending on which axis was given later).
In the Logitech setup program I can only combine the gas pedal with the brake pedal to make one single controller axis, the clutch does not have this option. But this is very inconvenient as even with that plastic piece removed from inside the brake pedal (to make it feel like braking with a brake servo failure), it's still much harder to push than the accelerator. I'll keep looking for a solution but any suggestions are welcome here.
Thanks in advance!
Hello all,
In the meantime I've found a workaround that can be used until IPACS comes out with a solution.
(Software option to combine two axes for rudder, pleeeease?
).By using vJoy and UCR, one can combine the two separate input axis into a single one:
After that, the rudder can be added from the virtual joystick.
Cheers
-
Finally I could try out the beta. I have an older gamer laptop (i7-4710HQ@2.5GHz, GTX860m 4GB, with 16GB DDR3 RAM and win10), so this is a 'slow' PC.
The performance increase with the Vulkan driver is more than noticeable, with the standard installation (no extra scenery) it can handle High detail pretty well,
using Vsync. Apparently the CPU is no longer throttling. I was unable to quote values because MSI Afterburner couldn't handle Vulkan, turning on the OSD rendered the whole screen blank. So I went without it. The OSD still shows twice the real frame rate both in Vulkan and in OpenGL (and OpenGL still shows 'D3D10' in MSI afterburner
). Interestingly, this version runs much better in OpenGL too (compared to the last release).However, the Vulkan version crashes pretty often, I've attached the log. Most crashes occur when looking around and when zooming in/out in the cockpit.
Nice work anyway, hopefully those bugs will be ironed out in no time!
(Ps. Is there cold&dark for big birds (737/A320) coming ?
) -
...As if an atomic bomb has been dropped the day before. Rural area's, specially photoreal....
Yeah, it's similar situation like catalog photos vs unstaged IRL photos. A little bit of 'life' is what triggers the brain into immersion, not necessary how accurately is being modelled. Bits of detail and also, movement (of stuff).
-
...On most computer systems, the CPU is not the bottleneck. Aerofly FS is mostly GPU bound and the CPU is just waiting idle. However Vulkan allows us to implement some things differently compared to OpenGL and this is why we get a small improvement of 5 to 15% in rendering speed.
On my laptop (probably on most gaming laptops) the problem is that the CPU and GPU shares the same cooler. Once the CPU load starts to peak on the core running the main thread, turbo frequency will kick in and rev up the GPU load as well. After a couple of seconds I'll hit the TDP limit, where the CPU is clocked down, the GPU load will also fall, fps falling with it. With Vulkan, the CPU load is lower (also multi-threaded?) thus even if the GPU at peak load would steal the Watt budget from the CPU, the lower clocked CPU will still be able to dispatch the same amount of frames, especially on multiple cores.
I'm playing on vsync since going over the display refresh rate is just excessive heat for me, so for even that 5-15% is a difference between a sustainable 60'ish fps or some terrible thermal throttilng with 25-30 fps drops.
-
nickhod, PM me if you need a hand for documentation. Will take look on the final version later.
-
I assume the Vulkan option also provides a future path to Mac support as OpenGL support was deprecated by Apple and a standalone Metal version would be unfeasible.
-
I have a really hi spec pc running 4k with a Titan 12gb so don't have any performance issues running 59.95 fps in any orbx scenery in AFS2 with all maxed out , so I did not really have any issues unlike xp11 which I totally love but never get past 25 fps. So Vulcan I am guessing will just push up the fps even more?.
Using Vulkan will improve your fps only if your have a CPU bottleneck while running OpenGL (the core running AFS2 maxes out at 100% while your GPU load is less than 100%. If the GPU already runs at 100% load, you might see no improvement in fps, maybe more consistent frame pacing and less CPU load. But it can really help out mid-class machines that have high-core low clock configurations (e.g. AMD processors, laptops or mobile devices), where TDP budgets, turbo clock or battery consumption is limited.
-
Its not going to 'look' any better than before, however, the performance will be better.
Well, if donut185's machine doesn't max out all visual settings currently, there might be an opportunity to trade in the fps improvement to a higher level of detail (assuming the GPU is not yet fully fed).
-
Wow, that sounds totally awesome...! Vulkan for even better performance...?!? How is that even possible!!!
Vulkan hands over total control (rendering process construction) and responsibility (error checking and resource management) to the application, making lower CPU overhead possible as well as multi-threaded rendering.
I'm looking forward to the frame rate improvement as currently I'm playing on an i7+860m laptop where I'm CPU bound.
Btw can we get a change log at some point ?
Great effort so far!
