[Nightmare]

Could somebody from the SCP team fix the loading lags that cause the game to stop for a moment everytime a new ship appears? I've asked a number of people on Discord and the common opinion was that it was atleast among the most annoying things about FSO. It effects literally every mission or mod, from Retail over mods to TCs, and there's no chance to evade it even with recent hardware.
There're so many nice things in FSO, and these lags just don't seem to be necessary.

[AV8R]

While I know some people have a very serious problem with this, my system (which is an Ivy Bridge based system - so it's not exactly new) barely has an issue with this at all. When a cap ship arrives, yes I can notice a barely perceptible hesitation - but for me, it really doesn't break game play (do I wish it wouldn't do it at all, sure. But it's not a deal-breaker for me).

There have been many theories in many threads as to why this happens - but nothing concrete/definitive. Most postulate that this occurs because the textures for an entire ship are loaded at the time of its appearance (and some have a LOT of textures). This could be the case I suppose. But is it indeed true?

There used to be a optional setting with earlier versions of the FSOpen (pre-3.8?) that allowed you to "preload all bitmaps at mission start" or something like that. Wouldn't that "cure" this issue, since all possible textures for any ships in a mission would already be loaded in video/RAM memory before they ever appear on screen (and thus be instantly available when the ship does arrive)? Or does FSOpen do this by default now, which is why the setting is now deprecated? But then, if FSOpen already preloads all mission textures/bitmaps before mission start by default, then this is likely NOT the cause of the hesitation issue and one must look elsewhere.

[Nightmare]

I was told it is somehow related to the shaders. I think having non-DDS files causes lags too as they have to be converted by the engine first but that's a different issue AFAIK.

[The E]

This is something we can take a look at for the next release, obviously.

A note, however: In topics like these, please don't try to backseat dev. Uninformed speculation on causes and solutions is useless at best, irritating at worst; telling us that a problem exists is one thing, making random guesses as to what the problem is and what the solution(s) could be isn't helping.
If you want to help, then using profiling tools like the ones built into VS or TraceCompass is a good starting point.

[wookieejedi]

This is something we can take a look at for the next release, obviously.

A note, however: In topics like these, please don't try to backseat dev. Uninformed speculation on causes and solutions is useless at best, irritating at worst; telling us that a problem exists is one thing, making random guesses as to what the problem is and what the solution(s) could be isn't helping.
If you want to help, then using profiling tools like the ones built into VS or TraceCompass is a good starting point.

Seconded. Also, just to let folks who might be unaware know, the game already pre-loads all bitmaps and ship models at mission start. Both m!m and I have talked about this issue before, and I will work to keep it in the discussion loop with the next release, too.

[m!m]

Just to clear up the misconceptions, I did some profiling a while ago because the lags also annoyed me and the reason they occur is because even though the engine already precompiles the shader, that is not enough for modern GPUs. For those, everything about rendering an object is important for generating the final code that gets executed on the GPU. That means, the game will lag the first time an object is drawn in a certain configuration. For example, if a ship is jumping in it is a different "configuration" than a normal ship because we use the GPU for slicing the object in half at the warp point.

So, how do other engines deal with this? One thing I have read about is basically replicating how we would tell the GPU to draw such an object at loadtime and issuing a render command that the user will never actually see but the driver will at least generate the code (and the lag) at a time of our choosing.
However, that is much easier said than done since OpenGL drivers are weird and in most cases we don't even know which exact configuration bits contribute to when the OpenGL driver will lag.

So, yes. We would all like to "fix" this but doing so will involve a lot of guesswork and engine refactoring. Would be an interesting project though. Maybe I'll take a look at it at some point...

[AV8R]

Excellent explanation. 

[Nightmare]

Thanks for clarifying that.