For those that don't read all the P3D forum posts, two LM developers recently posted interesting comments explaining how two often-discussed topics, volumetric fog and core affinity, work:

 

Firstly, a clear description from Beau of the difference between volumetric fog and the old FSX method:

Volume fog is applied based on visibility layers and it shifts from the actual color of a pixel (on the terrain for example) to the fog color each vis layer based on the amount of light simulated to have passed through that layer on its way to that point based on the fog density in the layer. This is different than the old fog where you visibility to every point on screen was fogged out based on the density of fog in the vis layer that the camera is currently in. Thus even with dense fog on the ground you could see the runway clearly if you were high enough to be above the fog. The ground obstruction was hacked by drawing a generic cloudy texture at the top of the fog layer below you. If you have 3 or for layers defined you would get a fairly ugly looking stack of those textures. 

 

http://www.prepar3d.com/forum-5/?mingleforumaction=viewtopic&t=8207

 

Secondly, an explanation from Zach as to why it's not a good idea to modify the affinity mask at runtime.  Although this "spreads the load" across all cores, it is likely to reduce performance.  There is really no problem with one core being maxed out at 100%: any real-time application needs a main coordinating thread, which will tend to be the bottleneck, so you want that to be at 100% (unless limited by GPU load or a frame limiter):

There are arguments against this goal. The reason that changing the affinity mask at runtime changes the utilization is because the application locks each of its threads to a single core, to ensure that it runs no more than one thread on any given core. When the mask is changed at runtime, those locks are removed, and the OS starts shuffling the threads around to different cores trying to balance the load. Switching a thread from one core to another has a significant overhead, and despite the OS's best efforts, it can't do better than give each thread its own physical core. The way the default mask works ensures that only external applications will ever contend with P3D for CPU resources, while it can and will compete with itself after the mask is changed at runtime.

 

http://www.prepar3d.com/forum-5/?mingleforumaction=viewtopic&t=8225.1

 

Hope this is of interest,

Jacob

Thanks for the hints.

Spirit

Good stuff, thanks for posting.

 

Greg

I am very glad they're giving us detailed explanations like these about how Prepar3D works.

Yeah this is great, we have been ingrained for years to tweak tweak tweak, and tweak some more, so it's hard for us to get out of that mindset to hack around an outdated architecture to work on modern PCs more effectively.  Now that Prepar3D is being reworked around modern hardware and techniques we don't require tweaks.  I definitely don't miss the days of spending more time tweaking my FSX.cfg than actually flying.  

 

I'm just happy seeing performance increases with each new drop of Prepar3D updates and hopefully they can feel comfortable about jacking up that LOD radius

 

In summary, I think they are telling us to stop mucking with config files (unless directed to like the cloud fix thing)

Your telling simmers not to be tweakers?  Not gonna happen no matter what LM says, ha!

The bottom line fact is though that they are listening to what we say and do and they ARE responding. It may not be the fastest dialogue but it IS a dialogue. Compared to MS this is a ray of sunshine.

 

Personally I get a little nervous when some of our self styled gurus start to argue with them lest they stop that dialogue but they seem to be able to handle themselves nicely and keep the focus on what they want to accomplish with their product.

 

Vic

The bottom line fact is though that they are listening to what we say and do and they ARE responding. It may not be the fastest dialogue but it IS a dialogue. Compared to MS this is a ray of sunshine.

 

Personally I get a little nervous when some of our self styled gurus start to argue with them lest they stop that dialogue but they seem to be able to handle themselves nicely and keep the focus on what they want to accomplish with their product.

 

Vic

 

Don't really like that either it amounts to people with no coding experience or knowledge how the internals of the program work telling the devs how to do their job.  Do it enough and they may just slam the door...

Yes, I've tried to explain the CPU loading to people that think it should be 100% across all cores, but unfortunately they either don't understand why or choose to not believe based on a conviction and/or false assumptions about how flight simulators are coded ... I've presented numerous articles (going back to Ace's dev team) about how Quad tree works and how synchronization MUST happen and it can only happen on a single governing thread.  But for whatever reasons, some persist that the code is not efficient and must use all cores at 100% even though they have no real world programming experience with the flight simulator paradigm.

 

It's certainly ok to "not know" how something works internally, but it gets a little old when one doesn't know, but still has the same conviction and keeps repeating that conviction over and over and it spreads to others that believe in the conviction and snow balls.  Not really helping anyone to perfectly honest.

 

The only changes I've made to my Prepar3D.cfg are to hide "brake", "pause", "overspeed" message ... that's it, nothing else.  I don't use nVidia Inspector either, everything via the nVidia Control (which in most cases is all "Application" controlled").

 

It's ok to not know, I'm a software engineer with 30+ years experience and there are still MANY things I don't know about software and hardware and probably may never know ... it's just too complex and big a field to pretend to know everything.  I'm always learning as I go, probably why Software development has kept me interested all these years.

 

Cheers, Rob.

What are now Lockheed Martin's latest recommended Affinity Mask settings?

What are now Lockheed Martin's latest recommended Affinity Mask settings?

 

With 2.3 you shouldn't tweak so also no AM settings. What you get by default, is recommended and best.

 

 

With 2.3 you shouldn't tweak so also no AM settings. What you get by default, is recommended and best.

 

Tthat wasn't my point - there still an Affinity Mask setting.  Does Lockheed Martin now recommend AM  = 111.....  on all processors?

O dear......Sigh

Rob.

Could you please list those tweaks to hide the annoying red messages? I would love nothing more to not see the Camera change red text/brake/overspeed messages!

Thank you so much.

Is there also a way to hide the messages that appear with a green bar when you open/close doors?