[Bug] Visibility update not consistent

[Kenny-Hui]

Description

After entering the game the first time and start moving the camera (Arrow key) in a 3D Cab, there will be a lag spike that freezes the game for a few second.

No idea what that is, but presumably it somehow loaded the exterior of the train as there's no more lag spike when changing to F2 camera (Caused by heavy texture loading), and I could not reproduce this lag spike either on train with none/very simple exteriors. (Outdated, see comment).

Reproduction

If the issue occurs in multiple routes/ trains, please provide one or two samples. In order to reproduce the issue and debug it, it's helpful to have the following:

Route

Any.

Train

Any.

Related information

• Operating system: Debian Testing (Trixie)
• Method of control: Keyboard
• OpenBVE Version: v1.9.1.2

[leezer3]

Now that's interesting.

We should be always be preloading the exterior textures (to stop a freeze when hitting F2), but I'd suspect its probably a visibility update here.

Will try and see if I can reproduce, but I need a slower machine.... NVME plus chunky CPU isn't a good combination for reproducing this sort of thing :)

[Kenny-Hui]

We should be always be preloading the exterior textures (to stop a freeze when hitting F2), but I'd suspect its probably a visibility update here.

I was also confused when digging through the code a few days earlier and discovered that internally it would switch to exterior mode before switching back to cab to avoid the F2 loading lag spike, but never did any trick on my side, although I didn't really look too deep into it.

This weird camera lag spike is probably only introduced very recently (Probably in the last few days). I initially thought it's a random lag spike but I am able to consistently reproduce it across different configuration, and it's only rotating the camera that affects it, maybe I can attempt reproducing it across differently nightly build...

[Kenny-Hui]

Ah I figured what happened, I was now testing on routes with runinterval, and when it updates the visibility via camera rotation it also loaded the exterior of the AI train infront.

[leezer3]

Is this a new issue then? Confused now....

https://github.com/leezer3/OpenBVE/commit/62583e2e7ed54abaef9f1211485db1dec7e43323

That's suspicious if so, something somewhere is probably checking for normal mode in that case.

[Kenny-Hui]

Essentially:

• This lag spike only happens on route with .RunInterval, as it attempts to load the train texture infront
• The Quad Tree PR probably introduced this, it has been a while now but has gone unnoticed as I don't usually play with RunInterval routes
• From my observation, the initial camera render distance would sometimes be shorter than it's intended distance, and when you move the camera, it fixes itself and loads a few chunk further, and this just happens to be where the RunInterval train is, as such this lag spike happens.
• In the process of discovering this issue, another issue is discovered that OpenBVE still does not seems to fully load the exterior train model/texture on launch.

(Using 200m visibility for this demo)

Screencast_20230811_003136.webm

[leezer3]

Interesting, thanks.

Will see what I can find.

[leezer3]

So, from an initial test, I can't reproduce your glitch from the video above,

Some thoughts however:

• Does the track vanish if you rotate the camera in the other direction? If so, this is probably just trigonometry at work, and you've likely just noticed it looking for this. (The left of field of the camera is starting to swing into the next block)
• Assuming the above is the case, I'd suspect that your pretrain is probably being introduced by this, and is probably as-designed. I'd need to chase down exactly when the train gets disposed from the renderer, but it wouldn't surprise me if it's getting disposed later than the scenery.

Basically, I'm not sure that the visibility thing is actually a real bug. Need to investigate the texture loading thing further, but it doesn't initially seem to reproduce for me with some of the NYCTA styff that prompted the initial change.

[Kenny-Hui]

I am pretty certain (at least from my observation) that the visibility part is an actual bug. Though one thing I observed is that it doesn't happen on a 2D Cab train, the entire distance got drawn with a 2D Cab train, while 3D Cab train just loads a few chunk less. (Could it be OpenBVE trying to move the camera to fit in the 2D cab, and in the process triggered a visibility update?)

It seems to be both route and train independent, where at the start of the simulation, when untouched, on any route, there will be a few chunk missing far infront on a 3D Cab train.

You can zoom in/out or even move the camera, but once you start pressing the arrow key then it gets loaded in. I've also messed around with different rendering settings (Like using the old renderer and it doesn't seems to help either)

One route where I find this to be quite noticeable is BrnoBVE's FirstBrnoTrack 2016 (http://brnobve.eu/fbt-2016/), with 600m visibility distance. After entering the game, zoom in til you see the end, then press the arrow key and suddenly things like tree started poping in infront, whereas it isn't before.

Although it's very very minor bug that should have almost no impact other than routes with pretrain with specific timing that are placed right in the unloaded chunk, that's what got my attention in the first place.

[leezer3]

So, I can reproduce with that, and I admit to being a little perplexed at the minute.

Our immediately culpable code appears to be this, which translates the relative camera yaw / pitch / roll to the absolute world numbers: https://github.com/leezer3/OpenBVE/blob/master/source/OpenBVE/Game/World.cs#L187C1-L189

It's interesting that the appearing objects are on a curve, which definitely suggests a trig issue somewhere, just got to get to the bottom of it....