Well I am so grateful for all the insight you have given Us Rob otherwise I think most of Us would be pretty much in the dark - thanks big time - oh get some rest Buddy

I really don't think so. With 2.3 they're improving GPU performance, but they also need to look at CPU performance before we start looking at frame rates of 60 FPS.

I agree, if you look around the Internet for what various members of the beta team have posted on P3d 2.3, The improvements over 2.2 are modest and are mostly related to overcast conditions, which in 2.2 were a terrible frame rate killer. The water looks better because of LM using the most recent update to the 3rd party SDK that drives the water visuals. HDR is slightly better. Among the weather engines, only OPUSFSX/FSI is known for sure to work with the 2.3 beta. The nVidia driver series 340.x tessellation bug is still there, although there are posts from nVidia staff on their message board that the bug will be fixed in the next beta driver after 340.52.

There is also something called (something like), I think you mentioned it before, input lag.  This may also have something to do with why flight seems "smoother", but I have no basis, just thought I'd throw that out.  I don't really notice any input lag in FS or P3D, but who knows.

 

 

A better solution, based on our experience, is to run most of the terrain engine tasks on Win32 fibers. 

  Right, and MS doesn't do fibers all that well.  "Flight Simulator's fiber scheduler is cooperative, which means the fiber tasks must periodically call back into the scheduler to see if it's time to yield."  Not really the right way to do it.  They ripped it off from some Berkeley code, if you know what I mean, and try to make it work in Windows as it evolves (it hasn't been going too well, ask any linux convert). Their implementation isn't low level enough, because of all the protected memory and hardware code they have to run it on top of, to be clean.  Their are better kinds of fiber implementations too.  That's why there isn't going to be much gained by addressing the CPU anymore.  The work is in much better hands going on NVidia's interface to their Processor (GPU), which are more often used in an environment where fibers are written and used more efficiently, so I'd think their driver coders have a similar mindset, plus they are mostly free from having to protect their proc from other processes.

For example, you are considering posting a 60fps video.  Quite a few people are going to see stutter in that video even with a newer cpu and gcard and a clean OS.

 

 

Keen to know if this has been addressed?... Using NI to set AF causes the water to look very odd [blurry] at least it does with 2.2. Setting it in-game each time is a PITA.

 

Verified, this has been fixed.

 

Cheers, Rob.

I agree, if you look around the Internet for what various members of the beta team have posted on P3d 2.3, The improvements over 2.2 are modest and are mostly related to overcast conditions, which in 2.2 were a terrible frame rate killer. The water looks better because of LM using the most recent update to the 3rd party SDK that drives the water visuals. HDR is slightly better. Among the weather engines, only OPUSFSX/FSI is known for sure to work with the 2.3 beta. The nVidia driver series 340.x tessellation bug is still there, although there are posts from nVidia staff on their message board that the bug will be fixed in the next beta driver after 340.52.

Don't see it to negative, It's getting better and better with every release. Even if the improvements are modest. And I'm sure other weather engines are already working on a new version to support V2.3. And yes there is an bug with the new Nvidia drivers, but the "old" drivers are still working fine. :wink:

I agree, if you look around the Internet for what various members of the beta team have posted on P3d 2.3, The improvements over 2.2 are modest and are mostly related to overcast conditions, which in 2.2 were a terrible frame rate killer. The water looks better because of LM using the most recent update to the 3rd party SDK that drives the water visuals. HDR is slightly better. Among the weather engines, only OPUSFSX/FSI is known for sure to work with the 2.3 beta. The nVidia driver series 340.x tessellation bug is still there, although there are posts from nVidia staff on their message board that the bug will be fixed in the next beta driver after 340.52.

I also don't understand the negativity in this post. Rob has stated that stutters have been greatly reduced, the water looks much better, cloud shadows in general impact performace much less in all situations, errors have been fixed, etc. Hey, what do you expect? You certainly should learn what "think positive" means... And by the way: nVidia will also fix the tesselation bug in one of the next driver updates as they have already confirmed...

 

 

No mention of SLI yet, but that will require nVidia driver support and LM are working with nVidia.

Hello !

Can we post somewhere our interest to a profile nivida supporting SLI with p3d2.3 ?

As promised, quick video of water in P3D V2.3 beta 2 -- unfortunately Shadow Play will not record 2560 x 1600 @ 60 fps (a known issue).  I tried to record using FRAPS @ 60 fps but it was just too hard on my system with over 20 fps drop and induced lots of stutters ... so I settled on using Shadow Play  @ 30 fps with it's limited bitrate (which is only 33,397 kbps vs. FRAPS which is 1,474,560 kbps).

 

 

Cheers, Rob.

Water looks MUCH better. Thanks for posting!

Agree with all that stuff about time between frames and that you don't need 60fps for smoothness. I my case, if its a smooth 20 FPS I'm happy too. I have a very good experience with a practically constant 30fps and 1/3 refresh in FSX. However as always I am disagreeing that FPS is not important. In my case it is important I have flown in P3DV2 at 60FPS at low setting with no stutters and the FPS makes a huge difference to my eyes. This whole argument reminds of the seen in Dallas where Sue Ellen Catches JR in bed with another woman and he denies it and says to her; "Who are you going to believe? Me or your lyin eyes!"

 

I agree that FPS is very important, especially after experiencing 60 FPS and seeing what it's like. Of course I'd much rather have smooth 30 FPS instead of stuttering 60 FPS, but I think we won't reach a state of perfection until we get smooth 60 FPS.

 

There can only be "one" main managing thread that says "ok, got everything I need to render the next frame" ... this will run on a core.  It doesn't matter if you have 8 cores, 16 cores, 32 cores, 64 cores ... if the managing thread (it's the traffic cop managing all spawned threads) has to wait for 1 required thread/core to finish, it still has to wait.  This is why you will never see 100% utilization across all cores on software that is governed by a real world "clock".  The simulation is hostage to the slowest running process that must report back before the next frame can get rendered.

 

This is about the example you posted, do you mean that AI traffic has to be processed by the main thread only so that it doesn't go out of sync with the rest of the world or that it can be managed by another thread but the main thread still has some work to do to make sure it's synchronised? If it's the latter, then doesn't it mean that there will still be some benefit from multithreading since the main thread will have to do less work?

 

It can, try P3D2.2 around a small island with no Ai, road traffic or realtime weather in a small GA aircraft with few systems modeled I get way more than 60 fps in that scenario.

 

I would have loved to see Flight handle a complex aircraft into a large fully modeled airport with 30 or so Ai running along with ATC.

MS Flight! ran well because there really was not that much going on at all.

 

It's easy to get 60 FPS in Prepar3D 2.2 by turning down the settings (same with FSX), but I don't think anyone would want to run it like this.

 

Microsoft Flight would have no problem with complex aircraft and lots of AI (the airports were already modelled with great detail) because all of the autogen ran on the GPU. This is why you could crank up the autogen without getting a performance hit.

 

I agree, if you look around the Internet for what various members of the beta team have posted on P3d 2.3, The improvements over 2.2 are modest and are mostly related to overcast conditions, which in 2.2 were a terrible frame rate killer. The water looks better because of LM using the most recent update to the 3rd party SDK that drives the water visuals. HDR is slightly better. Among the weather engines, only OPUSFSX/FSI is known for sure to work with the 2.3 beta. The nVidia driver series 340.x tessellation bug is still there, although there are posts from nVidia staff on their message board that the bug will be fixed in the next beta driver after 340.52.

 

I think it's all about the scenario you are in. As you can see, Rob pretty much tripled his FPS in fog and during sunset, while those who are CPU-limited in 2.2 will probably see no difference with 2.3. Hopefully they will touch CPU performance more in future updates because Lockheed Martin said in an interview (I think it was sometime last year) that with Prepar3D 2.0 they want to move away from the tradition of being CPU-bound.

 

As promised, quick video of water in P3D V2.3 beta 2 -- unfortunately Shadow Play will not record 2560 x 1600 @ 60 fps (a known issue).  I tried to record using FRAPS @ 60 fps but it was just too hard on my system with over 20 fps drop and induced lots of stutters ... so I settled on using Shadow Play  @ 30 fps with it's limited bitrate (which is only 33,397 kbps vs. FRAPS which is 1,474,560 kbps).

 

Thank you for the video, I think that the water looks great in here. One gripe I have though is the distance at which the detailed waves stop getting drawn, I think the transition could look less harsh.

Thanks for the vid, but unfortunetly the coastline waves are still missing part...

 

 

That depends on the direction we take water in v2. If we stick with the same general water technique we have, then it probably wouldn't be difficult to pull them back in. If there is a strong enough business case to revamp the water simulation/visualization for v2, then the existing wave animations wouldn't come back. (Though I doubt you would miss them in that case).

Beau

Beau Hollis
Rendering System Lead - Prepar3D® Team

 

Source Sept'12 : http://www.prepar3d.com/forum-5/?mingleforumaction=viewtopic&t=1606

That sunset is awesome.  Now if they could get the water to suck up into the wake.  There is a picture (probably a painting?) out there somewhere of a jet just above the water with the rooster tail behind it.  google images "jet over water"

That sunset is awesome.  Now if they could get the water to suck up into the wake.  There is a picture (probably a painting?) out there somewhere of a jet just above the water with the rooster tail behind it.  google images "jet over water"

 

This one?

 

Wow.... Don't you wish patch requests could work just like that?? ? Lol!

Hi Rob,

just a modest question about the helicopter downwash effect on land and water. Are these effects still missing? Maybe you find the time for a quick look.

Thanks a lot

Spirit