[1.8.1-1] [PLEASE FORK ME] Kopernicus & KittopiaTech

[VoidSquid]

So, as per my understanding, is it correct that, even with stock KSP planetary system, there is a massive FPS issue when using Kopernicus together with the new BG surface features, and the issue caused by the way Squad implemented the latter?

Or in other words: it's Kopernicus XOR BG surface features?

[Jognt]

47 minutes ago, VoidSquid said:

So, as per my understanding, is it correct that, even with stock KSP planetary system, there is a massive FPS issue when using Kopernicus together with the new BG surface features, and the issue caused by the way Squad implemented the latter?

Or in other words: it's Kopernicus XOR BG surface features?

That’ll Depend on your definition of ‘massive’. 

Id guess performance would be similar to 1.7.3-1+oceanFix. 

[VoidSquid]

35 minutes ago, Jognt said:

That’ll Depend on your definition of ‘massive’. 

Id guess performance would be similar to 1.7.3-1+oceanFix. 

Hmm... a little background then:

I've been using SVT, and hence Kopernicus, for years. Some weeks ago, after I had enabled the new BG surface features in my career save game which I started back with KSP 1.3.1, I switched to an old Mun base and noticed a considerable FPS issue. Switching to a close by rover, and driving it around, the FPS issue went worse. Some days later I was driving around a rover at Moho, same FPS issues, plus I noticed that over a couple of minutes driving around it got worse, down to maybe 2-5 FPS. Quicksave and reload helped, but as expected, FPS again got worse again after a few minutes. Plus the memory consumption grew way, way faster than before I had enabled the BG surface features (normally memory usage would start around 10 GB and over the course of hours, grow to some 16 GB, now it grew within half an hour to about 24 GB).

That's when I finally started to check the forums for what's going on. I did read about the two workarounds, namely reducing the frequency of the surface features, plus the ocean fix. But those are workarounds, not true fixes, so I decided reluctantly uninstall SVT as me being me, I don't like workarounds that much (which is total my personal issue, yes).

Now, checking this thread again, there's finally an explanation for this FPS drop behavior, namely the way Squad had implemented this feature, and the ball in their park, it's not a Kopernicus issue to solve.

You obviously are way more familiar with this issue, a question then: what's your best guesstimate what FPS drop I can expect installing the current versions of SVT and Kopernicus again? A slight drop, from say 40-60 FPS I have currently, to say 20 FPS? I could live with that. Or that massive drop to only a few FPS again? 

[Jognt]

8 hours ago, VoidSquid said:

Hmm... a little background then:

I've been using SVT, and hence Kopernicus, for years. Some weeks ago, after I had enabled the new BG surface features in my career save game which I started back with KSP 1.3.1, I switched to an old Mun base and noticed a considerable FPS issue. Switching to a close by rover, and driving it around, the FPS issue went worse. Some days later I was driving around a rover at Moho, same FPS issues, plus I noticed that over a couple of minutes driving around it got worse, down to maybe 2-5 FPS. Quicksave and reload helped, but as expected, FPS again got worse again after a few minutes. Plus the memory consumption grew way, way faster than before I had enabled the BG surface features (normally memory usage would start around 10 GB and over the course of hours, grow to some 16 GB, now it grew within half an hour to about 24 GB).

That's when I finally started to check the forums for what's going on. I did read about the two workarounds, namely reducing the frequency of the surface features, plus the ocean fix. But those are workarounds, not true fixes, so I decided reluctantly uninstall SVT as me being me, I don't like workarounds that much (which is total my personal issue, yes).

Now, checking this thread again, there's finally an explanation for this FPS drop behavior, namely the way Squad had implemented this feature, and the ball in their park, it's not a Kopernicus issue to solve.

You obviously are way more familiar with this issue, a question then: what's your best guesstimate what FPS drop I can expect installing the current versions of SVT and Kopernicus again? A slight drop, from say 40-60 FPS I have currently, to say 20 FPS? I could live with that. Or that massive drop to only a few FPS again? 

Well. The oceanFix meant I went from ~1fps to ~30-40 (lots of mods), so while I can’t put a number on any other impacts, I am quite certain you shouldn’t see that ridiculous performance hit again. 

[VoidSquid]

Thanks a lot , I'll give it a try then  

Sure, KSP 1.8 will have new surface textures... but how long will it take until all my for me critical mods will be updated and work again?

I was really happy with Kopernicus plus SVT, better have those back than a big "maybe" update  

Plus: I'm about to finish my current career, I'd like to try out JNSQ and/or maybe RSS, so it's Kopernicus anyway  

Thanks again, take care  

[Jognt]

34 minutes ago, VoidSquid said:

Thanks a lot , I'll give it a try then  

Sure, KSP 1.8 will have new surface textures... but how long will it take until all my for me critical mods will be updated and work again?

I was really happy with Kopernicus plus SVT, better have those back than a big "maybe" update  

Plus: I'm about to finish my current career, I'd like to try out JNSQ and/or maybe RSS, so it's Kopernicus anyway  

Thanks again, take care  

Cheers. If you’re going to check out JNSQ, get the master repo unless there’s a release newer than 0.7 because the current 0.7 release is missing a few bits and pieces that were added in later. 

Edited September 19, 2019 by Jognt

[VoidSquid]

Will do, thanks  

[scottadges]

On 9/13/2019 at 12:32 PM, ddavis425 said:

I'm also getting that scene switch freeze. It's about 4 seconds long and in terms of number of planets I am playing with Galileo's Planet Pack.

On 9/13/2019 at 12:31 AM, Purplefin Neptuna said:

with 1.7.3-2 release i encountered long freeze when loading the map view, and the freeze worsen when i use bigger planet packs. i think something happened when loading celestial bodies' texture.

 

On 9/13/2019 at 7:07 AM, A35K said:

Yep, similar issue here, although not really lag. When in flight, I press M to load map and the game completely freezes for like 3-4 seconds before loading the map, after which it works perfectly normally though. It's a much more minor issue than the surface lag on planets in the previous version but still slightly annoying.

I'm also getting this freezing when switching between Flight and Map view using Outer Planets Mod / Kopernicus.

I primarily use Astronomer's Visual Pack/EVE, plus Distant Object Enhancement & PlanetShine as my main graphic mods along with OPM/Kopernicus. This is on a regular sized solar system running KSP 1.7.3.

I've been doing some testing swapping out of these different graphics mods and it seems OPM/Kopernicus is where it's occurring:

Any help to resolve would be super-fantastic! Note that recent log & mod list are included in the question thread I started.

Edited September 27, 2019 by scottadges

[OhioBob]

To fix the lag issue when switching to map view, try this:

@Kopernicus:FINAL
{
	useOnDemandBiomes = False
}

 

[scottadges]

21 minutes ago, OhioBob said:

To fix the lag issue when switching to map view, try this:

@Kopernicus:FINAL
{
	useOnDemandBiomes = False
}

 

Awesome, thanks for the on-point and super-fast fix! Thanks also to @DeltaDizzy per his comments on GitHub.

If I could like posts right now, you'd be getting a whole lotta likes. 

Edited September 27, 2019 by scottadges

[A35K]

On 9/27/2019 at 5:41 PM, OhioBob said:

To fix the lag issue when switching to map view, try this:

@Kopernicus:FINAL
{
	useOnDemandBiomes = False
}

 

Sorry if it's already explained somewhere, but where should I copy this into to make it work?

[Galileo]

24 minutes ago, A35K said:

Sorry if it's already explained somewhere, but where should I copy this into to make it work?

Make that its own cfg and drop it anywhere in your gamedata folder

[A35K]

36 minutes ago, Galileo said:

Make that its own cfg and drop it anywhere in your gamedata folder

Thanks!

[pingopete]

Hey guys, so I'm working on a new project that uses textures larger than the 16384^2 pixels per texture unity limit. It's probably a bit of a long shot but I was wondering if there would be any way to integrate a cube mapping system for the ScaledSpace textures being mapped onto planets, allowing us to surpase this hard limit an achieve 64k texture resolution in KSP, properly mapped to surfaces?

It'd be miles better than the current only method which involved pasting terrain textures onto a cloud layer just above the terrain while in ScaledSpace

[Galileo]

1 hour ago, pingopete said:

It'd be miles better than the current only method which involved pasting terrain textures onto a cloud layer just above the terrain while in ScaledSpace

You would need to rewrite the PQS system. KSP2 is implementing something like that. They are using substance designer to help develop in sections as opposed to a single equirectagular maps like currently used in RSS or any other planet pack unless my interpretation is wrong.

About the cloud later, I have never seen anyone use a cloud layer to represent the surface of a body. You can't land on it for one, and the amount of detail you see wouldn't be representative of what you would actually see on the surface thanks to the current PQS system. 

Edited October 4, 2019 by Galileo

[pingopete]

47 minutes ago, Galileo said:

You would need to rewrite the PQS system. KSP2 is implementing something like that. They are using substance designer to help develop in sections as opposed to a single equirectagular maps like currently used in RSS or any other planet pack unless my interpretation is wrong.

About the cloud later, I have never seen anyone use a cloud layer to represent the surface of a body. You can't land on it for one, and the amount of detail you see wouldn't be representative of what you would actually see on the surface thanks to the current PQS system. 

Exactly it's completely broken. And ok, I guess I may just hold out then, the whole basis of this project was pushing 64k terrain or 32 at a minimum

[nwillard]

Just out of curiosity, what does "UseOnDemandBiomes" do and why is setting it to False a fix?

[OhioBob]

3 hours ago, nwillard said:

Just out of curiosity, what does "UseOnDemandBiomes" do and why is setting it to False a fix?

Using "OnDemand" means that a body's textures load only when you are in range of that body.  "UseOnDemandBiomes" is used specifically for the biome maps.  When set to false, the biomes maps are loaded into RAM at game startup.  This increases the load time at startup and uses more RAM, but the maps are always available for instance access when needed.  When set to true, the maps are loaded into RAM only when demanded.  For OnDemand to work, the maps should be in .dds format as these load very quickly.  It has been pretty common practice for most planet packs to have biome maps in .png format, which take longer to load when demanded.  It is this extra load time that can cause a delay when switching map modes.  By default, Kopernicus uses UseOnDemandBiomes = true.  Changing that to false eliminates the lag time because the maps are already loaded.
 

Edited October 11, 2019 by OhioBob

[Poodmund]

2 hours ago, OhioBob said:

Using "OnDemand" means that a body's textures load only when you are in range of that body.  "UseOnDemandBiomes" is used specifically for the biome maps.  When set to false, the biomes maps are loaded into RAM at game startup.  This increases the load time at startup and uses more RAM, but the maps are always available for instance access when needed.  When set to true, the maps are loaded into RAM only when demanded.  For OnDemand to work, the maps should be in .dds format as these load very quickly.  It has been pretty common practice for most planet packs to have biome maps in .png format, which take longer to load when demanded.  It is this extra load time that can cause a delay when switching map modes.  By default, Kopernicus uses UseOnDemandBiomes = true.  Changing that to false eliminates the lag time because the maps are already loaded.
 

For reference, the delay was still ocurring when biome maps were in .dds format also hence the recent commit: https://github.com/Kopernicus/Kopernicus/commit/449bad8920c0ff5f523354ddb34ca5bc949e5bd9

[wat4_dor]

Hi! And can be to know when Kopernicus will for 1.8?

[Guest]

Probably never, but there might be a version for 1.8.1. Right now, 1.8 is such a bugfest that it's probably not worth releasing for it. Even without that, it added a lot of new features to the planets, which need to be integrated, and Squad will hopefully release 1.8.1 before that point.

[Hadron27]

On 5/26/2016 at 10:52 AM, Thomas P. said:

Current Release

1.8 is out we need it updated reee

23 hours ago, Dragon01 said:

Probably never, but there might be a version for 1.8.1. Right now, 1.8 is such a bugfest that it's probably not worth releasing for it. Even without that, it added a lot of new features to the planets, which need to be integrated, and Squad will hopefully release 1.8.1 before that point.

We still want real solar system and such tho.

[Galileo]

5 minutes ago, Hadron27 said:

1.8 is out we need it updated reee

We still want real solar system and such tho.

Every time some one asks, it gets pushed back a week.

Edited October 20, 2019 by Galileo

[releansol]

20 hours ago, Galileo said:

Every time some one asks, it gets pushed back a week.

Just gold! made my day 

[R-T-B]

20 hours ago, Galileo said:

Every time some one asks, it gets pushed back a week.

And everytime someone recompiles it, a kitten dies?

Love you man.  Sorry about the kittens.

20 hours ago, Hadron27 said:

We still want real solar system and such tho.

In seriousness, if you have steam, you CAN just revert to 1.7.3 using the beta system tab under game properties, in case people don't know.  It'll stay there until you tell it to opt-out again.