Lower LOD (level of detail) for SPC buildings

[Justin Kerbice]

I just figured out that the quite long loading time before a launch or on a "building switch" (VAB->exit) can be caused by the gigantic and super (over) detailed Space Center buildings.

It's not very good most of the time because I just want to launch a rocket far far away from SPC and I'll take a look only at the launchpad, so if all objects around would be far less complex (kind of Kerbin City project buildings), I'm pretty sure loading time will be significantly shorter, the lag at the beginning (just when physics are "stabilized") might be reduced too.

I think add a settings INSIDE the game (not in settings main menu), to switch for buildings' LODs could be great, so when I want to drive/fly near the SPC, I set best LOD, when I want to go very far Kerbin (Jeb might have a fight with his boss, again ) I choose the lowest LOD and I don't have to wait many seconds just to see the launchpad AND if I have made a crazy gigantic rocket, performance of the game could be better.

[frizzank]

I second the use of LOD's. Also not rendering parts when they are less than 2 pixels on screen would help as well.

[Supernovy]

I thought most of the delay was caused by initialising physics. If that was true, then there would be a correlation between part count and loading time. I may have to investigate this myself.

On topic, I'm sure the space centre is pretty well optimised already, but perhaps you could go to lower resolution textures like you can do with parts.

[frizzank]

Textures are already mip mapped as far as I know. I'm sure optimizations are on the list for things to do in KSP....

[Nuke]

i dont think polycounts are an issue on modern video hardware. gpus eat polygons for breakfast. and mipmapping is a thing.

I thought most of the delay was caused by initialising physics. If that was true, then there would be a correlation between part count and loading time. I may have to investigate this myself.

On topic, I'm sure the space centre is pretty well optimised already, but perhaps you could go to lower resolution textures like you can do with parts.

physics is n^2 so more stuff == slow. rendering is not, you are just passing commands to the video card, and once they are sent you dont have to bother with them anymore. graphics' effect on performance is totally linear, while physics is exponential.

Edited March 7, 2014 by Nuke

[iStickyDuck]

Don't remove the high textures, have an option to turn them down a bit. On my PC they look beautiful and it runs without lag but on my laptop I would choose performance over graphics (so long as I can still see what I'm doing)

[DocMoriarty]

The vanilla KSC doesn't cause any noticable lag on my machine but i have some test vehicles and a test base assembly standing around there totalling in 600+ parts currently and that really lags down on loading and operating stuff there.

[Justin Kerbice]

i dont think polycounts are an issue on modern video hardware. gpus eat polygons for breakfast. and mipmapping is a thing.

physics is n^2 so more stuff == slow. rendering is not, you are just passing commands to the video card, and once they are sent you dont have to bother with them anymore. graphics' effect on performance is totally linear, while physics is exponential.

Not fully true, as it's depend on how Unity do the job first (and it can be horribly under-efficient under-optimized) then polygons + tex have to be send to gfx card memory to feed GPUs, so performances depend on buses speed/bandwidth (a parameter too many people forgot) so if your buses are not fast enough, GPUs spend their time waiting to receive data and waiting data to be taken out. Which in fact is what happen these days with crazy fast cpu/gpu (advertising effect) but motherboard/memory with performance improvement which don't follow.

And polycount matter too, just look at nvidia benchmarks data for example, you just can"t render in realtime an "infinite" polygons scene, there is a limit (which come from memory at least).

KSC itself may not be responsible of lags, but big ship + KSC may be (having KSC removed from count may help, even just a bit).

[Nuke]

thats not how a video card works. before the thing actually starts rendering anything all the data it needs is already fed into its memory. most of the bus traffic happens at loadtime. you have index buffer objects and texture objects and frame buffer objects all on the card waiting to go. what the game sends every frame is not graphics nor is it texture data. its commands to render things already in the video cards memory. most of the arguments for those commands are pointers to those objects, transform data, ect.

this happens unity or not (ive written some opengl applications). what unity does is throws in an abstraction layer so that it can support whatever native apis are used on the various platforms that unity supports, so that the same graphics calls that works on osx, works on windows, works on linux, or works on android or whatever.

the video card does have upper limits on what it can do, but i dont think ksp gets anywhere close to those limits. most of its resources sit idle frame after frame. loding may have been a thing in the 90s, but i dont think its neccisary for most games today.

[MR4Y]

I don't think the game should calculate physics for objects that are entirely static(i.e the entirety of KSC).

[Red Iron Crown]

I don't think the game should calculate physics for objects that are entirely static(i.e the entirety of KSC).

I don't think it does beyond the buildings being static rigid bodies, like the surface of the planets.

[MR4Y]

I don't think it does beyond the buildings being static rigid bodies, like the surface of the planets.

I think it does, especially after 0.21, where the game would freeze for a few seconds during SOI transition.

[Nemrav]

I think that there's probably a lot of unnoticable vertices in the building selection screen (terrain) that could be removed, but the buildings themselves aren't that intensive.. You can't notice the difference looking at the buildings or not.

[Justin Kerbice]

I think that there's probably a lot of unnoticable vertices in the building selection screen (terrain) that could be removed, but the buildings themselves aren't that intensive.. You can't notice the difference looking at the buildings or not.

I know we can think that's way, maybe someone need to study more carefully how it's done and what the GPU do in this case.

Anyway, one concern is more regarding the loading time on the launch scene (runway or launchpad) and the size of assets files in KSP_Data which are likely to hold all meshes and textures which are most of the time loaded mostly for nothing at all.

In fact there are only a few cases, on a descent hardware, where slowdown and/or lags can be witnessed, like osmetime when we're close to the shores or when there is some changes in Kerbin display (another model+texs ?) after a given altitude.