StateFunction as LOD function?

Since the models are getting more complicated and sometimes even with the new renderer the FPS is a concern, I've thought of a way to implement level of detail functionality depending on camera distance using a state function which would swap certain models with less detailed versions or even nothing the farther from the camera they get. But is that even feasible with the way state changes currently work? Will they introduce lag spikes on model change and does having a less detailed state on make an FPS difference?

That's something I have thought about in the last few days, never thought someone else would come up with the same idea.
But I didn't have insane model detail in my route that impacts the fps heavily.

I used Object Viewer for this experiment, loading an object with around 600 face takes ~0.2 sec to load on an i5-7500, GTX 650 Ti BOOST (Without texture)

Note: I've found out that texture loading are almost guaranteed to cause lag spikes (So it's best to not load a lower res texture)

I would call around 800 faces or above a somewhat complex objects, so the lag spikes is probably unavoidable unfortunately. (Esp on lower end laptop/desktop)

Ran a test, took most detailed models I have for bve (converted from other sim for test purposes) that come in many parts in .animated file and added LODs in this way. Made no difference while LODs worked and lots of polys were removed at certain distance. (set cut-off distance low for better effect)

Think the sim needs more 3D optimizations beyond the new renderer, the models weren't over the top detailed, just somewhat above typical Openbve level...

This is on the old Trainsimframework websites, maybe if we move out of immediate mode performances will increase? (I am not sure how much the impact really is, and it seems this won't be achievable in short term either)

The largest complain for the end user (That I've seen) nowadays is just lag.
The new OpenGL 3.x render does help, but it's nowhere near close to other games that is running DX9/GL3.3

Though VRAM bottleneck could also be a reason, I can render a train at 60fps with scaled down texture. However with higher res texture I only get around 15-20fps (And the fps fluctuates alot)

With the GL3.x renderer there's actually very little intermediate mode code left.
The heavy loading is done once when a model is first introduced, and then face counts are largely irrelevant.

The biggest killer by far is number and size of textures, and there's not a lot that can be done easily engine-side for this problem. 
The slowest OpenGL / Direct3D operation is changing texture by a massive margin. This is exponential based upon the size of the texture too, as stuff has to be passed over the memory bus to the appropriate shaders etc.
That's why essentially every commercial game engine uses texture atlasing heavily: https://en.wikipedia.org/wiki/Texture_atlas

Far too much stuff also forgets the power of 2 rule, which is another total killer.

The next (possible) step I suppose would be for the engine to implement an internal texture atlas, but that's going to be a massive amount of work, and utterly pointless with some of the 2048px plus sized textures in the most egregious stuff.
Fundamentally, some of the content authors need to take a long hard look at the size and number of textures they're using, relative to the actual size they appear on a player's monitor.

Interesting, I never thought it would be able to handle over 10k polygons with 60fps on a GTX 650 Ti BOOST
Though I have concerns about iGPU users (Should an iGPU be able to run a train simulator in the first place?)

Also is there any way of further optimizing a route? So far all of my textures are sized Power of 2 (most of them are 256x512)
Would an 1024/2048 sized Texture Atlas consist of multiple buildings perform better?

LXQt wrote:Interesting, I never thought it would be able to handle over 10k polygons with 60fps on a GTX 650 Ti BOOST
Though I have concerns about iGPU users (Should an iGPU be able to run a train simulator in the first place?)

Also is there any way of further optimizing a route? So far all of my textures are sized Power of 2 (most of them are 256x512)
Would an 1024/2048 sized Texture Atlas consist of multiple buildings perform better?

Yes and no

If you're using no transparencies in the atlas texture, then *probably* yes; In this case, the sim will sort the polygons so that the minimum texture switching is required.

With transparencies in the atlas texture, then probably no- In order to render transparencies correctly, everything needs to be drawn from front to back in order.
This will likely cause switching to and from your new atlas texture as it works it's way through the scene, and hence probably be slower (as you are now uploading it multiple times & it's bigger)

Also, remember that shrinking the on-disk texture is meaningless when uploading to the GPU. All this does is make the poor mug who has to download your route happier

Hm, the train I used for the test follows power of 2 rule, has reasonable texture sizes and there's not too much of them.

Speaking of: does vertex coordinate length mean anything for performance? Conversion from Blender leaves a lot of coordinates like 6.25006789 and that's def not a level of precision needed

iirc the texture you mapped with texture coordinate also need to be power of two, while the image itself does not? (I think that's from the documentation)

Vertex co-ordinate length means absolutely nothing.
Internally, things are stored as double-precision floating point numbers, although the GPU may clip these to single-precision. In practice, it means you've got a minimum of ~8 decimal places.

Power of 2 in texture mapping also makes no fundamental difference, unless you're using 100s of them in a panel2 digitalgauge (as this clips the texture internally).
Where it can (sometimes) be seen is in edge borders, as the original BVE formats had no means to specify texture clamping properties.

This is the phenomonon known as 'texture bleeding' - The GPU has to determine the most appropriate wrapping (edge blending) mode.
In more recent versions of openBVE, this can be controlled with the SetWrapMode parameter (only just added it to the documentation, sorry....)