The A2A C-172 seems to work fine for me.  I had an issue with being "stuck" (going back to P3DV2.0) but actually turned out to be an issue with the mapping of "Engine Start" to one of my GoFlight modules ... very odd, but when I removed the button mapping it fixed the issue.

 

Was that stuck strobe light fixed?

Pretty spectacular videos coming out of 2.2. Lots of wow factor, especially seeing cloud shadows on the ground. 

LM is really making big strides forward, with a big credit going to Rob in his testing. 

 

Love seeing those black bears fishing in the river coming out of CYPS   B)

 

Hopefully they can fix object flow soon so that these can be used in P3D v2

 

JV stated that their contractor has fixed the issues with ObjectFlow. Nevertheless there are some other obsticals to talke down before we will see all the Orbx airports in all their glory.

 

JV has, however, chosen to communicate this in Orbx P3D 2.x Support Thread instead of a General Forum. So I wasn't aware of it either until I was pointed to this fact by a fellow simmer. Thanks, Eric!

If you set texture resolution to 7 cm you get more detailed roads. I think that is the only difference from using 1 m resolution. I have never noticed any performance issues setting resolution to 7 cm and the roads look much nicer.

This is CYPS revisited.

 

Awesome videos Rob. V2.2 looks very promising.  Is that ASN weather depiction?

Edited April 1, 201412 yr by n4gix
Removed excessive quote and video link.

 

 

Yes the secret setting was changing nVidia Inspector from 4X SGSS to 4X SS. Wes had indicated they had done some AA removal for clouds in my build, but I wasn't seeing the benefits from it ... clouds would just kill my fps. That's why I made this video with many clouds (especially cumulus) and max cloud density -- I wanted to see how AA settings were responding to clouds. You can see the slight compromise in AA here, but for a 90% boost in performance, I'm going to have to retire SGSS AA override setting for now.

 

Perhaps the ideal solution would be for a transparency supersampling option to be added to the in-app graphics options, to avoid the need for NI overrides.  That way, different settings could be stored in graphics profiles, allowing settings to be easily switched according to the weather demands (eg 4xSGSS with few clouds, 2xSGSS with moderate clouds, and 4xSS in heavy clouds).  It wouldn't need all the NI options, just 2,4,8x SS and 2,4,8x SGSS.  I see an 'SSAA' option in prepar3d.cfg, but don't think it does anything.

 

Have you discussed this at all in your communications with LM?

WBard has posted that although they are not formally saying that SLI is supported and that further work needs to be done, they will be a performance gain in V2.2 with SLI. Can you experiment with this Rob and Comment.

 

I currently run 1 GTX 780 in my machine and I am wondering is it time drop in another. Looking at the Task manager and Afterburner it appears that I get to 100% usage on the GPU and then my FPS drops. usually not lower than 20FPS with almost maxed out setting. Locked 30FPS with V-sync and triple buffer off and my screen set to 30hz the P3DV2.1 is almost perfectly smooth. Only when the GPU hits 100% do the stutters appear. The CPU never goes over 90% and is in around 50 to 70% most of the time at AF15.

 

Can you comment if adding the second GPU will delivery 50% to and get that 20FPS to 30.

 

I am hoping the with the magic NV setting and a second GPU That V2.2 will be the answer to my FS prayers :lol:

Only when the GPU hits 100% do the stutters appear.

 

Task manager and Afterburner aren't accurate tools of utilization.   I know Word Not Allowed (and others) are "believers" in the 100% CPU and 100% GPU tools, but I'll keep repeating myself, 100% utilization is never going to happen in a flight simulation type of product ... video rendering maybe, flight simulation no.  

 

People are using these tools as a measure of utilization (in some cases even as far as suggesting poor code optimization) ... it's really not a good way to come up with that type of conclusion.  These tools being used are simply not accurate enough nor adequate.  To measure actual performance you need tools to be used with the development environment and in nVidia's case they provide their own set of development tools that you actually integrate into one's code (temporary) and compile.  

 

I use CPU/GPU Process Explorer type tools simply as a means to show that something is happening, nothing more.

 

For example, AutoGen processing in 2.2 is now utilizing the GPU much more, yet in Process Explorer I see zero change in GPU utilization, yet clearly I can see the real benefits in the simulation.  Anyway, if possible (fingers crossed), lets please avoid the % CPU/GPU utilization debate in this thread (they tend to be endless and people will believe what they want to believe).  

 

But to answer your question, I have not tried SLi yet, don't want to muddy the testing waters in something that's not fully supported.

 

 

 

that way, different settings could be stored in graphics profiles, allowing settings to be easily switched according to the weather demands (eg 4xSGSS with few clouds, 2xSGSS with moderate clouds, and 4xSS in heavy clouds).

 

As far as I know SGSS AA can only operate on the entire frame (final post processing) and is not something that can be set object by object (i.e. clouds) ... this is probably why the cloud AA changes made in 2.2 didn't work with SGSS AA but did work with SS AA.

 

Cheers, Rob.

 

 

Is that ASN weather depiction?

 

No, that was just me setting up lots of clouds, specifically cumulus (because they tend to hit performance the most).  I have FSGRW but it doesn't work with V2.2 beta (Steve is aware and will have update as soon as V2.2 is officially released).  OpusFSX does work with 2.2 beat and I've used it in other testing but not this one.  I don't have ASN.

 

Cheers, Rob.

FYI, as someone pointed out, it does look like Orbx have managed to get ObjectFlow to work in P3DV2.x.  See this thread: http://www.orbxsystems.com/forum/topic/76163-objectflow-now-working-in-p3dv2/?p=700103

 

Still no luck getting the MJC Q400 "fluid" -- suggestions appreciated but I couldn't get it working fluid, the aircraft works, just a few too many "stutters" (not low frame rates, but stutters).  However, MJC folks have committed to a P3DV2.x version: http://majesticsoftware.com/forums/discussion/1066/majestic-software-q400-and-prepar3d-v2#Item_2

 

Someone also mentioned the LOD_RADIUS restriction being removed in 2.2 beta ... I've tested this and I'm sad to say that does NOT appear to be the case.  The obvious issue is that LOD_RADIUS increases will cause OOMs just as they did in FSX -- so I can understand the reason for the restriction even with the much improved VAS situation (perhaps when we see a 64bit version that restriction will be removed, all speculation on my part).

 

Cheers, Rob.

Just some quick info/video on 2.2 Beta 2.

Just wondering why are you advancing the throttle so slowly on take off?

Edited April 2, 201412 yr by n4gix
Removed excessive quote and video link!

 

 

Just wondering why are you advancing the throttle so slowly on take off?

 

Avoid some of the torque affects so I diverge less from center ... I'm not an active GA Pilot so what I get is from reading the C-172 procedures for TO, they recommend full power early enough to detect any possible engine issues ... I had plenty of runway for weight load and weather conditions so I didn't feel the need to roll on the throttle full power early in sequence.

 

Maybe those GA pilots with C-172 experience can chime in on how/if they do full throttle check prior to takeoff?

Maybe those GA pilots with C-172 experience can chime in on how/if they do full throttle check prior to takeoff?

 

In the run-up area or somewhere along the taxi, holding the brakes.  You do the run-up, watch rpms and oil, look over the panel, listen for a bit, then get to the runway.  Sometimes you can do this if you're holding short.   Finding something is wrong is not what you want on takeoff.   Full power to the wall on takeoff, using as little of the runway as needed, in case you need it, until you're high enough to be able to turn back to the runway if you lose power, but usually until you're at your desired altitude.  Right rudder to compensate for the left pull.

 

An airplane engine is like a car engine going 200+ mph even at 70%.  There is no saving wear on the engine.   A family car might be at 30% when speeding down a freeway.  Of course, you knew that

  Full power to the wall on takeoff,

JIC someone is thinking this means slam them forward, it is a quick, smooth application to full power. It *IS* possibly to choke the engine in some a/c by "slamming" them forward. The smooth application also assists in controlling the torque effect. I like to think of it as - while my right hand is moving forward my right foot is applying steady pressure on the rudder to keep it straight.

 

Vic

Actually, you can pump, sort of bicycle the rudder, left right left right, at slow speeds to make it more effective at a straight line.  It actually seems to work in FSX too.

An airplane engine is like a car engine going 200+ mph even at 70%.  There is no saving wear on the engine.

 

Not sure I agree with that entirely ... engine initial start and warmup is critical to wear and torque kills parts more quickly - think transmissions and differentials -- and I've gone thru a few   I give my race car a full 15-20 minutes warmup time to get oil and water at temp (no bypass valves in my engine) -- engine tolerances are just too tight not to do that.

 

EGT and how one leans the mix will also contribute to engine wear.

 

But I was thinking using the Taxi-way and brakes for full throttle test (after warmup) is a good process to use.  Fortunately the cost to fix my A2A C-172 engine is cheap

 

Cheers, Rob.