Jackaroo05

What features would you like to see in P3Dv5?

Recommended Posts

On 5/22/2019 at 10:35 AM, Ray Proudfoot said:

I understand that. I’m hoping someone answers my question as it will be interesting to know how far away from needing a 128-bit OS and P3D we are. Not in my lifetime I suspect.

Not your lifetime no.

Share this post


Link to post
Help AVSIM continue to serve you!
Please donate today!

Only kidding, mine neither.. although its never safe to make predictions about compute improvements this kind of RAM doesn't seem likely. 4TB of RAM is a simply massive amount (please don't laugh if you are reading this in 2100).

There are 3 big reasons

1. Law of diminishing returns. We aren't very far from enough memory now to display a highly complex FS scene at 4K with approaching the fidelity of the eye. Yes it can get better but storing more and more textures is not really the limiting factor now. My video card can address 11GB of RAM. Doubling this would not drastically improve the quality of the scene. Do we need to load the O2 in 4k textures from 15miles away? No. We need better software/parallel computing/raytracing and raw RAM/texture rasterising speed.

2. Cloud graphical computing. Compute power is moving to the cloud, why having everyone with a 1000TB graphics card and only using it 0.5% of the time when we can run just when we need it. Like it or hate it the cloud platform subscription model is on the way https://www.forbes.com/sites/moorinsights/2019/05/09/google-cloud-doubles-down-on-nvidia-gpus-for-inference/#5e523db86792

3. Video RAM. A 64BIT system can in theory store 4TB in both RAM and System RAM. That means in reality you can have 8TB of program memory loaded.

 

Share this post


Link to post
Posted (edited)
On 5/20/2019 at 4:38 PM, Pete Dowson said:

and

I don't know of any BGL compression. BGLs are programs written in "Bruce's Graphical Language!"

 

I believe the vector data (cvx) is compressed but I could be way off the mark. I read this in another thread.

On 5/20/2019 at 4:38 PM, Pete Dowson said:

I think pretty much all performance and smoothness improvements has to come from making much better use of newer hardware

Absolutely, but this sometimes requires changing the engine architecture and data formats.

As I noted some point previously there are times where I fly across a complex region and my 8 core 9900K has maxed out every core at 100%. GPU is 50-60%

As I don't develop P3D and they won't give us even a the smallest nugget of architecture detail I can only guess wildly at why this might be happening.

You raise the idea of lookahead, I agree and have suggested this too, but I think it could be easier than you might think. I've raised my thoughts with LM (and here).

In summary the terrain loading logic appears to rudimentary:

  • [main thread]
    • collect resources to render scene
    • record point of aircraft every x seconds
    • check if point is y points from an unloaded terrain square 
    • queue load of
      • vector/terrain texture on terrain cores/threads 
      • autogen on additional core/threads
  • [x terrain threads]: Process. Load textures/vectors into Video/RAM, decompress textures/vectors.

It is obviously more complex but it something like this, problem is this

  • doesnt account for direction of travel/view
  • doesn't cull loads if loading isn't keeping up

You can check this by stressing the engine

  • bump up various values in the config (TEXTURE_SIZE_ESP) such that you are nearing the limit of VRAM 
  • turn off V-SYNC
  • slew at 500kts across ORBX/complex scenery

As the view turns into a blurry mush, pause and look behind you, the scenery is dutifully loading away 10/20/30 miles behind you cell by cell.

Utterly pointless, 8 cores maxed out at 5GHZ drawing 200watts to render scenery behind me for 10minutes!

Trillions of wasted FLOPS. I cannot set P3D to graphical levels it can just handle because when I fly more than 15 miles from starting point the engine starts overstressing the CPU. Catch 22. You are forced to fly around at 50% fidelity so that the engine doesn't fall over.

I believe this could be improved with additional checks like:

  • prioritise terrain loads closest to the AC in the queue 
  • prioritise terrain loads with a viewport bearing closer to 0degrees
  • cull terrain loads > than X points distance (where x is a constant, strangely this doesn't seem to exist or it is huge)
  • pause terrain loads where viewport bearing > than 180degrees + queued terrain loads exist where viewport bearing <180degrees

I assume its more complex but this is the general issue I see with terrain/blurries even with the fastest PC you can get.

There is another aspect to this around V-SYNC and video RAM but I have waffled on enough and sorry for all the bullet points 😂

Edited by DellyPilot

Share this post


Link to post
25 minutes ago, DellyPilot said:

I believe the vector data (cvx) is compressed

I expect so. And BMP DDS and other graphics fles, maybe optionally. but not the conreollng part, the BGLs.

27 minutes ago, DellyPilot said:

this sometimes requires changing the engine architecture and data formats.

Yes to the architecture -- splitting taks off for GPUs, differemt threads etc. But source data structure on disk is only read and cached or stored. The conversion to whatever is needed is done when loading. That can be done separately without affecting any main processes. And compressed data is sometimes faster because the loading time savings are more than the decomprression overhead in one of the cores.

31 minutes ago, DellyPilot said:

there are times where I fly across a complex region and my 8 core 9900K has maxed out every core at 100%.

That's excellent! I'd love to see such a spread. What clock speed is the 9900K running at? On all cores?

I tend to only get a decent spread when initial loading or loading a new scenario for a complex airport.

Maybe I need to wind up some sttings.

34 minutes ago, DellyPilot said:

As the view turns into a blurry mush, pause and look behind you, the scenery is dutifully loading away 10/20/30 miles behind you cell by cell.

Whilst I tend to agree with you, is that not because you are looking at it? If you'd passed it already wouldn't is still be loaded, at least till it ran out of memory? Seems to be your observation shows it cleared it to make room for what is to come, so had to reload it now yo decided to look back.

Pete

 

 

Share this post


Link to post
43 minutes ago, Pete Dowson said:

is that not because you are looking at it? If you'd passed it already wouldn't is still be loaded, at least till it ran out of memory?

 

 

I don't believe so. The viewport appears to have no bearing on loading. If you look out the left wing can just see them to your far left loading up.

You can also test this further by using a chaseplane outside view to zoom off into the distance and it will remain all blurry, but you can find the cells that are trailing behind the plane and being reloaded, viewport direction has no impact on this loading.  

As to your first comment the 100% load on CPU is not a good thing at all as none of it is contributing to framerate, this is pure autogen/vector terrain load. For example, maxing everything 4k high stress, orbx, weather etc, high view distance/LOD and flying from Zurich to London I have to pause at Dover for about 5-10minutes for the catchup.

When I do this I do not bother looking backwards, I just leave it. 100% CPU fans blasting. Eventually Kent loads up.

I thought I was being really clever by assign a button to reload scenery.. but it is bugged out! Once you reload scenery, the load mechanism is even more broken, what you then see is if you fly on another 15 miles no more terrain loads up, I think this might be because they forgot to cull all the terrain queues, who knows, but regardless of that bug reload is way faster than waiting for catchup which proves how bad the engine is, a full reload should never be faster than slewing to any new location.

I think the big factor here is ORBX scenery, it is so significantly heavier than anything before it and LM are simply not using it in any of their testing. This really frustrates me that ORBX and LM don't work together to improve the engine.

 

Share this post


Link to post
Posted (edited)
11 hours ago, DellyPilot said:

I think the big factor here is ORBX scenery, it is so significantly heavier than anything before it and LM are simply not using it in any of their testing. This really frustrates me that ORBX and LM don't work together to improve the engine.

Let me stop you right there.

There are a lot of ORBX developers inside the LM beta testing team (they have one of the largest amount of members), it is their responsibility to test their products and provide feedback to LM engineers.

Interesting enough I don't see any of them making any reference to problems with TE GB, TE Netherlands, Germany regions, etc. Via the LM beta forums.

It was Rob Ainscough (who doesn't work for ORBX or LM) who performed intense testing using these regions and reported back hard evidence and data, which was useful to produce the Hotfix you and many others are enjoying.

But quite frankly, it is not the responsibility of Rob A., Me or anyone else in the beta team to ensure ORBX products are working correctly with any version of P3D. That is why ORBX belongs to the beta team, to do their own bloody tests, and it is a shame other members of the beta team had to step in to provide feedback on their behalf for their own products.

Regards,

Simbol

Edited by simbol
  • Like 6
  • Upvote 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now