RX1 {l Wrote}:The rather long loading time is not related to the details of the track. The polygon count is around 100.000 tris (130.000 in blend file, but not all of that is exported). As far as I remember Cocoa Temple for example is around 250.000 tris.
The reason for the longer loading time is related to the complexity of the driveline in combination with the length of the track and the required number of checklines. If I delete all additional drivelines and keep only the main one, the track also loads in one or two seconds. Like I described before:RX1 {l Wrote}:Dirvelines - loading delay:
Because of the pipes and alternative lines, my track needs many additional drivelines. […] I am not sure, but maybe this is related to the following message which STK writes, when loading the track: "[info ] CheckLine: Object crosses line, but wrong height ...". The more drivelines I have, the more of these messages it generates. It would help if I would understand what exactly this message means. I suspect it might be related to checklines that are not touching any driveline.
I think the long loading time has nothing to do with the checklines at all, but the message you mentioned lead me to the real reason:
When loading a track, void DriveGraph::computeChecklineRequirements() is called and it traverses the whole node tree to find the last checkline a kart had to cross before a given quad. This is done recursively but no check is done, if a certain node has been visited before. This function will literally travel all(!) possible ways. So if you have a lot of alternative drivelines it can take some time.
For a quick fix I added a check if a node was already visited: the current version runs about 3 to 4 seconds on my system for your track, with the change it runs less than 10ms.
I don't know if this can have any side effects because I'm not familiar with this part of STK. More specifically, I don't know if grouped checklines have the same number internally. If that was not the case, my new version is not guaranteed to produce the exact same result than the current one. Although the result of the current version would also seem to depend on the order of the successors. So some testing would be good.
I'm not sure this is the right place for those details, but I don't know another way to reach RX1. You don't seem to be on Discord?
If you can compile your own client, you could try my fix, or you could send me the most complex version of your track and I could see how long it takes to load.