EVERYBODY - READ THIS *** VSYNC *** (UPDATED)

[Lenticular]

It is very strange. I can't understand what could be waiting for the video blanking signal (VSYNC) that would upset anything else in Condor.

I personally do not think this is the problem. I think VSYNC is causing some other side-effect which is masking the real culprit.

If this was genuinely a high frame rate/no VSYNC issue, everyone would be seeing it, but we're not. I have never had this issue across two versions of Condor and multiple updates.

Good for you that you don't have a problem with that, because if you have it, you will be very frustrated.

Let me replay the worst flight I have had with that problem. It was one of Pit-Rs events (very nice ones), I think it was in Matamata. After the flight I compared my track with the track of a fast one (maybe the winner or the second one), we both used the same plane, Ventus3-18. I crossed the start line five minutes before him, at round about 80 % of the distance I was together with him in the same lift, he was maybe 200 m below me. Then he left the lift and flew straight to the finish. I needed 3 more lifts to finish and arrived 15 minutes later. If I didn't had that problem I would minimum be able to fly nearly as fast as he to the finish. I can't be so bad, that I loose maybe 3 minutes (5 minutes but 200 m more height) in the first 80 % but 15 minutes in the last 20 % only cruising home. And if the ball on the pda shows you are high enough to finish, but it's moving all the time up (or down, I don't remember, haven't used it the last 3 years), and you go down with MC again and again but finally need lifts again to finish, then it's not my skill, like someone dared to say, but a very frustrating problem outside my responsibility.

It was the moment where I was thinking about deleting Condor from my machine. With vsync on I came out of that deep valley, but changed everything and only do what I really like now

Here another one who have had that problem, and I remember one more, but don't want to search for that thread

https://www.condorsoaring.com/forums/vi ... 29&t=21012

I'm sorry for those with these problems apparently everywhere. I *do* see this problem, but only on certain 3rd party sceneries that were converted to C3.

I never saw this on C2, and I don't see it with certain sceneries in C3 (including the stock scenery).

Therefore, as per my previous post, the issue is buried somewhere else.

The fact your glider had seemingly *significant* performance difference to the other guy strongly hints at another, unrelated problem.

There is no planet on which a set of instructions would result in a different calculation result, unless something else was going awry.

I haven't heard anyone discuss timing sources or other computational problems that can arise, that can break physics.

Let me start with a real simple question: why can the scenery determine if this issue is present?

Try Truckee 2.2 converted from C2 to C3. I get 100% rope break with that scenery. WHY? Other scenery works...what is special about this one?

Answer that question, and you get much closer to the real source of the problem.

[wickid]

I described the source of the problem a few pages back...

[janjansen]

I described the source of the problem a few pages back...

Indeed + I provided instructions how to reproduce the problem pretty reliably (confirmed by 3 pilots now) on Slovenia. I think that part of the discussion can be closed. Arguing that you can notice framerates that can not be rendered, not even going there.

What remains a little bit open is a reliable solution that doesnt necessitate syncing to 60Hz, for those with higher or VRR monitors. Wiek, do I remember right you have a 120Hz one? I know you dont have anything else to do these days , but maybe at some point if you are bored you could try the steps I described and then see what happens at refresh rates other than 60. On my system, 75Hz is "unsolvable" (even with v-sync) and anything above that, I cant test.

[wickid]

I have no issues V-synched at 144Hz

[janjansen]

ANy chance you can put your monitor @75Hz?

[6266]

Answer that question, and you get much closer to the real source of the problem.

Let me try, maybe I'm wrong, but I have a theory.

We have learned that on every frame the physics, f.x. the sinking, is calculated. And these calculations are not in sync with the moving of the plane, when more frames are calculated then the screen is able to show (so the plane sinks without moving = higher sinking, the tow plane moves but not the glider = rope break). F.x. Marcs test, FPS 120 works fine, independent how the 120 be achieved, if with vsync or high graphic settings. FPS 180 breaks the rope, because the plane doesn't move in sync to the 180 calculations per second.

You say you get 600 FPS and you don't have problems. That means the physics are calculated 600 times a second. That is really fast. Maybe (here I'm only guessing, therefor it's only a theory) the program isn't able to calculate 600 times a second and there is an exit in this case not to calculate every frame. Due to the very high FPS calculation happens in another way, maybe 60 times a second. Then the problem is gone, because moving of the plane is in sync with the frames on the screen.

If the theory is valid, you will have a lot of landscapes working fine. And then you use a landscape where you get a lower FPS, fx. for to use Marcs numbers 180. The program is now able to calculate the physics, but it's too fast for the screen and the problem is there.

Have you ever controlled the FPS when you got the problem in a "bad" landscape? I guess it's far below 600.

As I said, it can be wrong, but it sounds as a logical explanation for me ...

[Lenticular]

I get the rope break with the ropebreak.fpl file, but if I go into external view and launch, it works.

[6266]

what FPS do you have in both cases?

[Lenticular]

Answer that question, and you get much closer to the real source of the problem.

Let me try, maybe I'm wrong, but I have a theory.

We have learned that on every frame the physics, f.x. the sinking, is calculated. And these calculations are not in sync with the moving of the plane, when more frames are calculated then the screen is able to show (so the plane sinks without moving = higher sinking, the tow plane moves but not the glider = rope break). F.x. Marcs test, FPS 120 works fine, independent how the 120 be achieved, if with vsync or high graphic settings. FPS 180 breaks the rope, because the plane doesn't move in sync to the 180 calculations per second.

You say you get 600 FPS and you don't have problems. That means the physics are calculated 600 times a second. That is really fast. Maybe (here I'm only guessing, therefor it's only a theory) the program isn't able to calculate 600 times a second and there is an exit in this case not to calculate every frame. Due to the very high FPS calculation happens in another way, maybe 60 times a second. Then the problem is gone, because moving of the plane is in sync with the frames on the screen.

If the theory is valid, you will have a lot of landscapes working fine. And then you use a landscape where you get a lower FPS, fx. for to use Marcs numbers 180. The program is now able to calculate the physics, but it's too fast for the screen and the problem is there.

Have you ever controlled the FPS when you got the problem in a "bad" landscape? I guess it's far below 600.

As I said, it can be wrong, but it sounds as a logical explanation for me ...

There is nothing logical about it, and no, the prior explanations do NOT answer why the simulation breaks.

Here's what we know:

* It works at frame rate higher than refresh rate regardless of VSYNC
* It works at insane FPS (600) - there is no reason to believe the physics, or anything else, is being skipped due to high frame rate, as all high frame rate means is that all calculations are being completed insanely fast
* There is no logical explanation why high calculation rate should break anything; on the contrary, this problem should get WORSE as frame rate increases based on current explanations, but it does not
* The explanation that physics are calculated but the aircraft does not move because the rendering did not occur is absurd. In my decades working with and writing simulators, I have never heard the drawing of a model on the screen materially affecting anything about the physics.

Let me break down the last point:

The physics calculate the tow plane accelerating. It calculates the strain on the tow rope. It then calculates the acceleration of the glider.

It updates all their positions based on the last time step.

Why does the physics care whether the position got drawn?

OK... so it skips a frame because it is faster than the drawing rate (refresh rate).

So what?

Our physics continue from the previous time step. It again computes all the above, and updates the positions.

It goes to draw...skips.

Third physics iteration. Third attempt at drawing...OK, it draws.

How the heck does this break the physics?

So the physics loop ran 3x faster than drawing. How can the physics break?

It defies logic, unless the way it is written is totally busted, in which case this problem highlights a deep design problem with the basic physics engine.

X-Plane intentionally runs the physics at a user-defined rate, which can be in sync with drawing (1x frame rate), or up to 10x faster than drawing. Nothing breaks.

DCS runs the physics at 4x the frame rate. On my system, it runs at 250 FPS, meaning the physics are running at 1000 Hz. Nothing breaks.

I go into external view, I still get insanely fast FPS (200+) but now it starts moving. I jump back in the glider, and fly perfectly fine; the tow rope never breaks, and everything is fine.

The issue is getting the glider to move that first iteration.

The rope breaks INSTANTLY, the instant it connects to the glider. BOOM.

THAT is where the problem lies in all of this. What happens in the first or second iteration of the physics at the moment the tow rope is connected? What is the very initial condition of the rope? Something is busted right there.

[6266]

https://www.condorsoaring.com/forums/vi ... 15#p188344

My theory bases on this post, that taken as true it's logical in my opinion.

But it doesn't matter. I have had that problem and I have a solution. If it's logical or not, it works

[janjansen]

since none of us have access to the source code, speculation on the exact root cause is moot. .All we can do is document/experiment to find out when it occurs and when it doesnt, and share that info with users so they can avoid issues and with Uros if/when he wants to solve it (should he need that info, its possible he understands the issue perfectly).

[Lenticular]

VSYNC ON is the only thing that really kills perf in the sim for me. Solid at 60 Hz.

It seems to fix the issue mentioned. I'd love to know why, but that may be a question to which I never get an adequate answer.

I'd be really curious what the effect is if someone had a 240 Hz gaming monitor that locked at 240 Hz. I certainly have the performance to try it, but not the monitor.

[wickid]

VSYNC ON is the only thing that really kills perf in the sim for me. Solid at 60 Hz.

V-Sycnh doesn't kill performance. It runs Condor at a framerate your monitor can display. There is no point running Condor at over 60FPS if your monitor can't display it. All the extra frames just get trown away. It makes your CPU and GPU run hotter than needed, increases the electricity use ect, ect.

[Lenticular]

VSYNC ON is the only thing that really kills perf in the sim for me. Solid at 60 Hz.

V-Sycnh doesn't kill performance. It runs Condor at a framerate your monitor can display. There is no point running Condor at over 60FPS if your monitor can't display it. All the extra frames just get trown away. It makes your CPU and GPU run hotter than needed, increases the electricity use ect, ect.

You're arguing with the wrong guy. I write software for a living and know how it works, and yes, there is a point running physics faster than 60 Hz. It is just a stupid gamer argument not to.

There are adverse effects of VSYNC you are clearly unaware of. Condor is so fast it is not obviously affected, but I can assure you, the behavior is the same.

It still stands that this is a completely asinine solution to a weird problem that would be better being fixed properly. I suspect it is too fundamental to the architecture which is why it isn't.

[Tom]

I normally run Condor in VR, if I choose to switch back to 2D i use one of two screens one is a ultrawide 2560x1080 60 hz or a curved 1440p at 144Hz.

I normally only use vsync on the Ultrawide to stop screen tearing, or if using a tug to stop the current issue with tow rop breaking.

on the 1440 hz i dont bother with vsync again unless its to avoid the tow rope breaking issue at the moment.

One disadvantage of VSync is that in trying to synchronize the frame rate and screen rate, it creates a delay for mouse and keyboard commands. It is especially a big problem when playing highly competitive games where a single click can result in a win or loss for you.
When playing a game with high-intensity scenes, the frame rate suddenly drops below the refresh rate of the monitor during an intense scene. VSync, in an attempt to synchronize the frame rate with the refresh rate, further drops the frame rate to suit the monitor's preferences. It results in the performance being downgraded instead of an improvement.

I kinda break it down to:
If I am on my UW screen tearing is much more noticeable on ultra wide screens so i tend to turn it on. Also if using an aerotow as mentioned I also turn it on.
If on my 1440P I tend to leave it off again unless using aerotow.
VR Headsets in most cases use their own form of vsync.

Just be aware that as I pointed out above using vsync can introduce it's own stutters etc although in Condor input lag isnt as critical for example as a competitive fps game.