Page 1 of 1

Track online performance

PostPosted: 21 Sep 2020, 16:55
by RX1
Hello everyone,

I'm trying to figure out how it happens that some STK tracks that are running well offline, are either running slow or "lagging" in online play. The most prominent examples are Black Forest, Candela City and Cocoa Temple, but I also experienced these performance issues with my own track Toy Block Raceway (see https://forum.freegamedev.net/viewtopic ... 18&t=14214) when playing with five players and more. While Toy Block Raceway was my first track and initially intended as a learning project, I want to avoid such issues in possible future projects.

Here are some properties, which I suspect to be relevant for online track performance (I used my track as example):
  • Polygon count:
    I started working with LOD models to decrease poly count for revision 3, which is not online, yet. The average count of polygons rendered in game was decreased by about 1/4 of the previous version, now ranging from about 15 000 to 30 000, while previously it were about 23 000 to 39 000 polygons. Unfortunately the LODs are actually slowing down the track (overall, not just in networking). I noticed that there are tiny delays (a few frames) when LOD instances switch the displayed model. I guess because the track is compactly built with a lot of direction changes and many separate objects, there must be lots of LOD model switching going on. Otherwise I don't know what is wrong. It looks like resetting the LOD instances to object type none and sticking with the higher poly count gives better performance in this case.
  • Number of objects:
    I don't know how synchronization works in STK network games. So maybe this matters: Toy Block Raceway is literally built of blocks. Instead of modeling a landscape from a single surface plate, we used small separate blocks to build the tunnels, walls, ramps and scenery. Maybe joining many of them into one object would increase the online performance or does only the poly count matter?
  • Movables:
    For networking I excludeed most movable blocks by scripting. Only 14 movables are left in networking mode. Standard tracks like STK Enterprise and Volcano also have movable objects and those tracks are running very well online. So this can't be a problem, can it?
The next track I want to build might be rather compact as well. I don't want to run into the same issues again.


Best regards

RX1

Re: Track online performance

PostPosted: 25 Sep 2020, 03:35
by QwertyChouskie
The slowness with LOD models is known, see https://github.com/supertuxkart/stk-code/issues/3805 and also https://github.com/supertuxkart/stk-code/issues/3780

As for the difference between online and offline play, online play is constantly re-winding and re-playing physics actions based on received network data. As such, anything physics-related is made hundreds, if not thousand of times more CPU-intensive. The higher the ping, the more of these rewind/replay operations are necessary, and thus the more the performance hit. This is why these tracks can perform quite terribly even when running on graphics level 1.

All static objects should be merged at run-time (see https://github.com/supertuxkart/stk-cod ... aee6ab1fa7), but maybe there are some extra non-static objects? Also, I wouldn't be surprised if the objects removed by scripting aren't actually fully removed and are thus adding a performance penalty.

Re: Track online performance

PostPosted: 25 Sep 2020, 12:53
by RX1
Thank you QwertyChouskie, for the explanations and the links.

QwertyChouskie {l Wrote}:All static objects should be merged at run-time (see https://github.com/supertuxkart/stk-cod ... aee6ab1fa7), but maybe there are some extra non-static objects? Also, I wouldn't be surprised if the objects removed by scripting aren't actually fully removed and are thus adding a performance penalty.

All non-movable and non-scripted blocks have type none in my tracks case. So those are merged at run-time, as far as I understand. If I got it right, it doesn't matter if my Blender model uses separate blocks (Blender objects) or if everything is just one huge object. That is an important fact to know for future projects.

So in my case the problem probably rather are all those direction and mode specific objects, that are not even displayed. By working with LOD to decrease the displayed polycount I actually made the situation worse? :|
In the last few days I still assumed that actually switching between the different LOD models caused the slow downs. So I tweaked the display range of the LODs and had the impression that I improved the performance. I thought the track now runs pretty much as fast as the previous version, while keeping most of the lowered polycount. Anyway, I'm going to keep and upload the new version with the LODs and see how it's running online. Hopefully future developments will solve some of these issues.

Certainly I'll avoid massive use of non-static (and scripted) objects in future tracks, but I often have unusual ideas and tend to take things to the limit of what is possible. ;)

Re: Track online performance

PostPosted: 26 Sep 2020, 04:55
by QwertyChouskie
By all means, keep experimenting with what's possible, as it makes for cool tracks, just understand that sometimes there will be a bit of a performance hit. :)