A thought on graphics optimisation

[Targ Collective]

I've noticed that even ultra performance on FSR tends to be susceptible to slowdowns in built up sectors. This points to graphics memory use being too high, and I've had a few thoughts on what would be causing it and wish to offer a suggestion.

In short, I suspect that many different duplicate models are being preloaded whether or not they are in frame.

It might help resource load to load each model a minimum of once, and then call these models to the graphics card only if drawn. Further optimisation gains can be achieved by lowering poly count based on symmetry and distance.

In terms of model load time we would only lose the effort to call the model from memory, and the game would not need to keep a built up, busy sector loaded at the same time.

I'm making these suggestions based on inference so it is quite possible you have solutions for preload and distance already. Revisiting these solutions with modern technology could still be worth performance gains when you have time.

I've had to guess at where to place this - does this belong in Beta chat? I don't think so, because this isn't something being visited in beta right now, at least as far as I can tell. Technical support might be a good fit, but the game may well be working as intended with any solutions you may have for this. So I'm guessing and placing this in general discussion.

The game is awesome, but players will keep building megastations without the slightest thought for what the computer can handle. (But you know that already. )

[CBJ]

I'm afraid your analysis of what causes the game to slow down in those situations is way off the mark. The reason the graphics settings make no difference has nothing to do with graphics memory; it's that the game is not limited by the graphics in the first place. In busy sectors it's usually the CPU, or rather specific threads on the CPU, that are the limiting factor, and none of the things you mention will make any difference to that. I won't go into the details again of why there is no magic way to spread the CPU load more evenly, but suffice it to say that we are well aware of optimisation techniques, both on the GPU and the CPU side.

[Targ Collective]

Hm. That's an embarrassing thing to guess wrong, considering how many tools there are to check this stuff. Thanks for taking the time to reply and I hope your Christmas, or whatever your turn-of-the-year celebrations you may have, goes well. Here's to the new year, when it happens.

[Targ Collective]

Waitaminute, if it's CPU I think I've spotted a potential cause, no joking. Stations with lots of modules will also load massive amounts of flightpath data, which *is* CPU bound. Using a classic Plato's Cave solution to store the flightpath variables unless they are called might give performance returns, and also explain why player stations and superstructures are a known cause - NPC stations will need fewer calculations because potential flightpaths are simpler.

I'm hoping this is more useful to pursue. Having an AI model to prune and combine duplicate fly-around-me paths, and for denser builds don't-fly-into-me paths that have no fly-around-me paths, might seriously reduce CPU time.

You're game developers and have probably thought of this already, right? Please be kind. Theorycrafting possible solutions is kind of fun, though I have no idea how this would be done in practice, and if I'm useful then that's a bonus, right?