Thomas P.

[1.7.3-2 + Backports] Kopernicus & KittopiaTech

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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? 

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites

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 :) 

Share this post


Link to post
Share on other sites
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 by Jognt

Share this post


Link to post
Share on other sites
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 by scottadges

Share this post


Link to post
Share on other sites

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

@Kopernicus:FINAL
{
	useOnDemandBiomes = False
}

 

Share this post


Link to post
Share on other sites
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 by scottadges

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
36 minutes ago, Galileo said:

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

Thanks!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Galileo

Share this post


Link to post
Share on other sites
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 :(

Share this post


Link to post
Share on other sites
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 by OhioBob

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.