Kosta, i've read your blog and found the comparisons interesting. I agree with you.
I realize that LM put effort improving this platform since the first Prepar3d. However, when i look into graphics and performance... I can't understand why this engine is so bad, so difficult to deal with, and honestly, it's performance output is far from today's technology.
I mean, take a look at the outerra engine http://www.outerra.com/. It's amazing how fluid it is. My system is a bit old, but not weak. I managed to crank everything to maximum on the Demo version and i get more FPS than prepar3d v2 with medium-high settings.
Many here also know the Luminous engine http://www.youtube.com/watch?v=eHSGBh1z474; Unreal engine 4; etc. Look at what those guys managed to get with a good platform!
Beau mentioned shadow calculations per pixel and stuff. Well, how do other companies manage to do them much better and not so performance demanding then?
I remember back in 2006 or 2007 when Crytek released the first Crysis. Man, that was awesome, and still is! Now think about the improvements they made until the most recent crysis game... It demands a LOT of both CPU and GPU work, but you can't compare those graphics with Prepar3d. I also remember on BF3 the fighter jet mission. Even though some parts we're not in real time and they had a background sky, it looked and performed incredibly.
So, how can i accept an answer that says it's 'difficult, complex, there are many calculations, that's why it lacks performance'?. I don't think so.
The Achille's tendon of prepar3d still is autogen. And now we have a second one with lighting. Both impact performance excessively.
What i wanted most is that LM managed to create a new ENGINE from scratch, thus getting rid of this forever buggy Microsoft platform, and improving also the flight dynamics.
Now, about back compatibility: I rather wait to have future add-ons that WORK and are USABLE than stay 80% of my simulation time tweaking settings. This engine was never stable and it always performed badly. Keeping compatibility is only justified from the business/market perspective.
And that DOES NOT sound like "we never forget who we're working for".
Anyway. If you take a look at some recent games, game engines and stuff, you might end up asking: why the h*** am i STILL asking for a mere, SIMPLE RAIN DROP effect on my windshield in Prepar3d v2?
Regards
Bad performance at heavy addon airports
Quote:
Quote from Kosta on December 28, 2013, 11:30
Any comments on this? I know it's holidays, just that the thread is on the 3rd page, I hope we can get an answer to this.
At this point to me P3D V2 is for the time being going to primarily be for me a VFR & low altitude flying sim where it really excels. I think it is very doubtful you're going to get good performance out of PMDG stuff out of big terminals. Using the rest of my hexacore CPU more efficiently is the part that's really missing. And I agree: SLI will not help this beast in its current form if you already have the GPU to run V2 on. I say this as I see frames quite limited w/ the maxed out Core1, yet relatively low GPU utilization in these sorts of high demand scenarios. How can a 2nd strong GPU help in this? And once frames drop under about 23 or so in V2 it starts showing for certain. I'd really like to think otherwise, but it just doesn't look good yet for airline flights w/ complex airplanes. The other issue I'm finding is the radius of sharp textures appears lower than in FSX, at least to my eyes. Lower and slower flying is quite lovely though, so if I keep V2 it will be primarily for this.
What I'd really like is a way to make FSX look much more like V2. I have fabulous performance in FSX already, plenty smooth, great frame rates. Visually though, w/ the big exception of water, V2 just looks much better and that's compelling in itself until I get well up at altitude at which point textures verge on blurry in V2. So truly, the only reason to change to V2 is for the visuals, a wee bit smoother, but ultimately for me it's the visuals.
-
jabloomf1230
- Posts: 262
- Joined: Thu Nov 01, 2012 7:40 pm
Quote:
Quote from mensar1 on December 28, 2013, 12:49
Anyway. If you take a look at some recent games, game engines and stuff, you might end up asking: why the h*** am i STILL asking for a mere, SIMPLE RAIN DROP effect on my windshield in Prepar3d v2?
...
The rain drops on the windshield can be made available as a feature of the aircraft. Besides, when it was available, it was a real performance killer.
-
jabloomf1230
- Posts: 262
- Joined: Thu Nov 01, 2012 7:40 pm
Quote:
Quote from ncp10 on December 29, 2013, 03:37
Visually though, w/ the big exception of water, V2 just looks much better ...
That seems to be true of the default P3d2 water textures and animations. But if you use the add-on REX 4 water textures, the water looks quite realistic (see below). You have to have tessellation at Ultra and mesh at 1 m in P3d2 to get the full effect. Of course, at high altitude, the image quality of the water is somewhat irrelevant.
http://www.rexdirectexperience.com/img/gallery61.jpg
Yes, P3D is sure able to do some very neat water effects, due to complete makeover. As you noticed, high altitudes don't justify it though. And we need better optimized object placing and/or multithreading for that.P3Dv2 ain't bad, but it's missing this one very important "feature", if one can call it that (performance).
I would finally like to know what LM's comments on that are.
I would finally like to know what LM's comments on that are.
-
Beau Hollis
- Lockheed Martin
- Posts: 2452
- Joined: Wed Oct 06, 2010 3:25 pm
There have been many threads devoted to 64-bit so I won’t say much on that. It’s in our long term roadmap but we are still focusing on getting the 32 bit version optimized. As for threading, autogen work is already threaded out. In addition v2 already threads out much more work than was threaded out in v1. It may not always look that way from CPU utilization stats because a good deal of threaded terrain work is now done on the GPU.
Performance always has been and will continue to be something we are always working on be it directly or indirectly. Performance is a broad topic covering the entire application, the entire range of application settings, and the entire range of supported hardware. There are countless interdependent features sharing various hardware and software resources (CPU, GPU, RAM, vRAM, HD, User input, Operating System, etc). We have to carefully consider the impacts across the entire performance spectrum before making a decision to move work into a background job or onto the GPU.
Is it possible to do this work asynchronously via threading or GPU computation?
If so will it actually run faster once you factor resource contention and synchronization?
Will it causes some use cases to run slower? (The answer to this is almost always yes)
How much work is it and what is the risk for adding bugs?
Etc. Etc. Etc.
Even if there are some members of this community who happen to be subject matter experts in computer programming with a specialization in graphics and rendering, they wouldn’t be able to answer any the above questions without a working knowledge of our baseline spanning more than 4 million lines of code. While I’m sure they are well-intended, request to thread out x or move y to the GPU aren’t really helpful to us and tend to confuse the community further as the ensuing responses get more bogged down in technical details.
We greatly appreciate the community running tests and sharing data points with us, as any data may be helpful to us on our quest to improve the platform. Please be careful about jumping to conclusions though. If someone improperly self-diagnoses an issue and posts about it as a known problem, it could be very misleading to our customers. We may have to start removing posts containing false or misleading information even if the post constrains some valuable information, is constructive, and is made with good intentions.
You’re performance comparisons for example cover a narrow use case, on a narrow range of hardware and specific settings. While you’re data is useful it doesn’t support making general statements about performance of the application or even the autopen system. We have made significant performance improvements across a broad range of features. On some hardware and usage situations we have seen v2 run much faster than v1 while doing over twice as much work. Obviously those are isolated use cases so we don’t publish those kinds of performance results as they would be misleading. We do more work now than we used to so many use cases and hardware profile may run slower than V1/FSX on what appear to be similar settings, especially on lower-end GPUs. Many users have raved about our performance. It will always be a work in progress but it’s certainly not a missing feature.
Quote:
Alright, if object-placing is such a big problem, and it can be done on the CPU only, I guess you better make sure you use more than one core for that.
We actually do most of the heavy lifting for loading, paging and batching/instancing autogen in background jobs already. Because the viewpoint is constantly moving and rotating, new batches/instance groups are being requested every frame. The results of background jobs have to be synchronized back to the primary thread, put into buffers, and copied to the GPU. For what it doing, it actually performs quite well. In the case of trees it generally performs better than v1/fsx while buildings work more or less the same way they used to. The real issue as we have stated several times is that we are loading and drawing a great deal more autogen now than we used to because the pop-free method doesn’t work with progressive LOD loading. We decided to take the performance hit to reduce popping. As most of our users are GPU bound, the extra CPU usage has very little impact on overall performance. The end user has the option via cfg settings to disable pop-free or lower the settings to achieve the desired level of performance.
Quote:
I don't know how the hundreds of other games handle that, which actually also probably have millions of object placements, and still benefit from the GPU optimization?
Sorry but that's simply not true. The only games that might have millions of 3d objects would be arcade space-shooters with heavy instancing of a small number of unique models. Most games use model-complexes, LODs, impostors, and mat-painted sky-boxes to make the scene look much more complex than it actually is. All this content hand-made by artists and is already batched and grouped optimally for the renderer before being loaded at run-time. Much of the optimization falls on the content teams and is done on a per-level/area basis. Most games also force a full reload between areas for this reason. In addition: They probably don't have the whole world. They almost all have max draw distances of less than 3-20km and don't have a camera that can move at Mach speeds. They probably don't support add-on content, or if they do, they certainly don't allow add-on content to use a 10 year old model format with built in scripting and state management.
Quote:
mensar1’s last post..
This post is full of opinions and unfair comparisons to other games/engines. It’s insulting, and offers no constructive feedback whatsoever. The only reason I haven’t removed it is because I will respond to a few of the points since most everyone who cares to read it already has.
First off, Prepar3D is a simulation platform, not a game. We have users that do nothing but cockpit training and others who don’t use an aircraft model at all. The reason there are so many settings it to support the broadest set of training use-cases possible. As-such, you shouldn’t max out all the settings even though some very high end machines can handle it. Settings should be tailored to your current use case and content which is why we provide a way to save out setting profiles in-app. Our philosophy is that if you have a super-computer we want to let you use it. These aren’t real stats, but lest say it might be 3 times as expensive to make the shadows look 20% better. That’s a terrible trade off if your GPU bound and would likely make the sim unusable. Most games wouldn’t let you get into that kind of usage scenario so they don’t provide those kinds of settings. Some of our users do have crazy high end GPUs, and expensive CPU-side simulation requirements that get them CPU bound, so it’s a free visual boost for them.
As I stated above, next-gen games do much of the performance tuning in the content development and are able to cut tons of corners in both visuals and simulation based on the type of game it is, user movement restrictions, size of world, etc. As a platform, we can’t do that. Several of our developers, me included, have prior experience working with other engines like Crytek and Unreal. Both are amazing platforms and I have nothing negative to say about them, but I know from experience that it is very easy to bring those systems to a crawl with poorly optimized content and over-use of their respective scripting languages. There are indie games developed on UDK that have very simple looking graphics and perform badly, but I would never blame Epic for that.
Super detailed simulations of a virtual cockpit may take up half the frame time by design because that’s what’s needed to meet the training requirement or because the add-on developer doesn’t have the time/money to optimize it further or replace xml scripting with a c++ add-ons. We can’t really do much about that.
In any case, this thread has gotten way off topic, so I’ve decided to lock it and move on to other post where users are in need of support. Thanks to everyone for all the useful data you have collected about various airports and add-ons and how they affect your performance for your given settings and use-case. We will compile it all and make use of it as we continue to tune performance.
Performance always has been and will continue to be something we are always working on be it directly or indirectly. Performance is a broad topic covering the entire application, the entire range of application settings, and the entire range of supported hardware. There are countless interdependent features sharing various hardware and software resources (CPU, GPU, RAM, vRAM, HD, User input, Operating System, etc). We have to carefully consider the impacts across the entire performance spectrum before making a decision to move work into a background job or onto the GPU.
Is it possible to do this work asynchronously via threading or GPU computation?
If so will it actually run faster once you factor resource contention and synchronization?
Will it causes some use cases to run slower? (The answer to this is almost always yes)
How much work is it and what is the risk for adding bugs?
Etc. Etc. Etc.
Even if there are some members of this community who happen to be subject matter experts in computer programming with a specialization in graphics and rendering, they wouldn’t be able to answer any the above questions without a working knowledge of our baseline spanning more than 4 million lines of code. While I’m sure they are well-intended, request to thread out x or move y to the GPU aren’t really helpful to us and tend to confuse the community further as the ensuing responses get more bogged down in technical details.
We greatly appreciate the community running tests and sharing data points with us, as any data may be helpful to us on our quest to improve the platform. Please be careful about jumping to conclusions though. If someone improperly self-diagnoses an issue and posts about it as a known problem, it could be very misleading to our customers. We may have to start removing posts containing false or misleading information even if the post constrains some valuable information, is constructive, and is made with good intentions.
You’re performance comparisons for example cover a narrow use case, on a narrow range of hardware and specific settings. While you’re data is useful it doesn’t support making general statements about performance of the application or even the autopen system. We have made significant performance improvements across a broad range of features. On some hardware and usage situations we have seen v2 run much faster than v1 while doing over twice as much work. Obviously those are isolated use cases so we don’t publish those kinds of performance results as they would be misleading. We do more work now than we used to so many use cases and hardware profile may run slower than V1/FSX on what appear to be similar settings, especially on lower-end GPUs. Many users have raved about our performance. It will always be a work in progress but it’s certainly not a missing feature.
Quote:
Alright, if object-placing is such a big problem, and it can be done on the CPU only, I guess you better make sure you use more than one core for that.
We actually do most of the heavy lifting for loading, paging and batching/instancing autogen in background jobs already. Because the viewpoint is constantly moving and rotating, new batches/instance groups are being requested every frame. The results of background jobs have to be synchronized back to the primary thread, put into buffers, and copied to the GPU. For what it doing, it actually performs quite well. In the case of trees it generally performs better than v1/fsx while buildings work more or less the same way they used to. The real issue as we have stated several times is that we are loading and drawing a great deal more autogen now than we used to because the pop-free method doesn’t work with progressive LOD loading. We decided to take the performance hit to reduce popping. As most of our users are GPU bound, the extra CPU usage has very little impact on overall performance. The end user has the option via cfg settings to disable pop-free or lower the settings to achieve the desired level of performance.
Quote:
I don't know how the hundreds of other games handle that, which actually also probably have millions of object placements, and still benefit from the GPU optimization?
Sorry but that's simply not true. The only games that might have millions of 3d objects would be arcade space-shooters with heavy instancing of a small number of unique models. Most games use model-complexes, LODs, impostors, and mat-painted sky-boxes to make the scene look much more complex than it actually is. All this content hand-made by artists and is already batched and grouped optimally for the renderer before being loaded at run-time. Much of the optimization falls on the content teams and is done on a per-level/area basis. Most games also force a full reload between areas for this reason. In addition: They probably don't have the whole world. They almost all have max draw distances of less than 3-20km and don't have a camera that can move at Mach speeds. They probably don't support add-on content, or if they do, they certainly don't allow add-on content to use a 10 year old model format with built in scripting and state management.
Quote:
mensar1’s last post..
This post is full of opinions and unfair comparisons to other games/engines. It’s insulting, and offers no constructive feedback whatsoever. The only reason I haven’t removed it is because I will respond to a few of the points since most everyone who cares to read it already has.
First off, Prepar3D is a simulation platform, not a game. We have users that do nothing but cockpit training and others who don’t use an aircraft model at all. The reason there are so many settings it to support the broadest set of training use-cases possible. As-such, you shouldn’t max out all the settings even though some very high end machines can handle it. Settings should be tailored to your current use case and content which is why we provide a way to save out setting profiles in-app. Our philosophy is that if you have a super-computer we want to let you use it. These aren’t real stats, but lest say it might be 3 times as expensive to make the shadows look 20% better. That’s a terrible trade off if your GPU bound and would likely make the sim unusable. Most games wouldn’t let you get into that kind of usage scenario so they don’t provide those kinds of settings. Some of our users do have crazy high end GPUs, and expensive CPU-side simulation requirements that get them CPU bound, so it’s a free visual boost for them.
As I stated above, next-gen games do much of the performance tuning in the content development and are able to cut tons of corners in both visuals and simulation based on the type of game it is, user movement restrictions, size of world, etc. As a platform, we can’t do that. Several of our developers, me included, have prior experience working with other engines like Crytek and Unreal. Both are amazing platforms and I have nothing negative to say about them, but I know from experience that it is very easy to bring those systems to a crawl with poorly optimized content and over-use of their respective scripting languages. There are indie games developed on UDK that have very simple looking graphics and perform badly, but I would never blame Epic for that.
Super detailed simulations of a virtual cockpit may take up half the frame time by design because that’s what’s needed to meet the training requirement or because the add-on developer doesn’t have the time/money to optimize it further or replace xml scripting with a c++ add-ons. We can’t really do much about that.
In any case, this thread has gotten way off topic, so I’ve decided to lock it and move on to other post where users are in need of support. Thanks to everyone for all the useful data you have collected about various airports and add-ons and how they affect your performance for your given settings and use-case. We will compile it all and make use of it as we continue to tune performance.
Beau Hollis
Prepar3D Software Architect
Prepar3D Software Architect
