Jump to content

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


Thomas P.

Recommended Posts

1 hour ago, Diddly Feelerino said:

Since the new ROCs are physical (i.e. can be interacted with, physically), whereas the scatter objects are merely cosmetic, could the sudden deluge of physical objects and colliders be causing the lag? Especially as a craft gets closer to the surface...

In that case you'd expect to see an increase in frametimes proportional to the amount of objects. Which considering the (relatively) small amount of parts/object(s) of the lander would mean very little change in frametimes and poor performance all around.
The kerbal on EVA is technically a vessel/craft too so I don't get why everything is fine when I move that vessel around, but everything goes down the drain when that other vessel is around.

You did remind me that I forgot to check how much CPU the KSP thread was using.. I'll see if I can check that later.

In the meantime I figured I'd send the same lander again, but this time without solar panels to check if the KopernicusSolarPanel module had an impact. Framerate still tanked so that wasn't it, but now I have more kerbals and two vessels to test with later. 

Edit: I probably sound annoyed in previous posts. If so, it isn't aimed at Kopernicus itself or any person. Just wanted to say that.

Edited by Jognt
Link to comment
Share on other sites

22 hours ago, edwin.robert said:

I can't find SS 0.10.2, i see 0.10.3 and 0.10.1.... I looked on Github and can't find it. Is it alright with the .2 or .3?

you are right, for some reason I have it in the changelog but I never released it... weird

here's a link to an "unofficial" release, I have no way of knowing if it will work, if this won't work you might try v0.10.1 or v0.10.3 but I can't assure you they will work either

Link to comment
Share on other sites

19 hours ago, infinite_monkey said:

My game is crashing quite often lately, so I went through the logfile. It is getting spammed with the same error message, and I found no repy to this post:

Kopernicus as well as the stock game had been updated a lot of times since that error and I didn't happen ever since.

Link to comment
Share on other sites

So uhm, about that framerate thing.. :/

I did some more testing and found it indeed isn't specifically linked to ROCs, ROCs and terrain scatter just add to the problem.

I still do not know an exact cause, but when I installed MemGraph into my test install I noticed that with Kopernicus KSP is generating excessive amounts of garbage.
And by excessive, I mean excessive.

I loaded the save both with and without Kopernicus+dependencies (+memgraph&dependencies):
Stock: 752KB garbage per frame;
Kopernicus: 10.000/18.000 KB garbage per frame;

Funnily enough, going within unpack distance for the lander (and experiencing the subsequent FPS crash) reduced the amount of garbage to a more 'reasonable' 2000KB per frame.
The garbage creation differed in amount depending on CB and what was loaded in, but it was consistently higher than stock.
Increasing the GC heap did not improve performance, so I don't think GC itself is the cause of the slowdown.

I am going to guess that whatever is causing the garbage is also attributing to the FPS drop mentioned by people both here and in the GitHub issues.

Screenshots: https://imgur.com/a/Utxf79b
Save: https://www.dropbox.com/s/hx1k0yytdbmy4ce/persistent.zip?dl=0
Log: https://www.dropbox.com/s/zo8vuz5j6imgid1/output_log.txt?dl=0

Oh. A funny quirk I also noticed from the screenshots is that all the scatter is mirrored in orientation with Kopernicus. I doubt it's related though.

I really hope this helps to get this figured out. Not just for me, but for everyone using Kopernicus.

Pinging those with interest: @Diddly Feelerino @Starwaster

Edit: Just in case it's not clear; Considering the amount of refactoring that was done I would be surprised if there weren't any bugs. It's a massive piece of work, and I appreciate the effort that has gone into it.

Edit 2: Maybe it's related to the foreach in FixedUpdate() in ring.cs?

Edited by Jognt
Link to comment
Share on other sites

On 7/22/2019 at 4:25 PM, SuppaTenko said:

Is it possible to add surface features like cryo-volcano or crystals with Kopernicus? If so - can you link me to instructions, examples or mods which do it? 

It depends on what your goal is. Kopernicus  can scatter static, collidable objects around the surface. Apparently with Science, too.

To my knowledge, the only interactable, animated surface features come with the BG DLC and rely on "prefab" assets. You can, however, redistribute and rename these. Look in SquadExpansion/Serenity/Resources/rocsdef.cfg for their definitions. Have some trees on Minmus:

Spoiler

+ROC_DEFINITION:HAS[#prefabName[kerbinBaobabTree]]
{
	%Type = MinmusBaobabTree
	%displayName = Minmus Tree
	%Frequency = 5

	!CELESTIALBODY {}
	CELESTIALBODY
	{
		Name = Minmus
		Biome = Lowlands
		Biome = Greater Flats
	}
}

+EXPERIMENT_DEFINITION:HAS[#id[ROCScience_KerbinBaobabTree]]
{
	%id = ROCScience_MinmusBaobabTree
	%title = Minmus Tree Scan Report

	!RESULTS {}
	RESULTS
	{
		default = This tree should not be here.
	}
}

jZ7fgDS.jpg

 

Edited by HansAcker
Link to comment
Share on other sites

6 hours ago, HansAcker said:

Look in SquadExpansion/Serenity/Resources/rocsdef.cfg for their definitions. Have some trees on Minmus

And I put some Geysers on Kerbin before installing Kopernicus.

What I haven't been able to do is put features on a world *created* by kopernicus. They seem to work ok on worlds modified by Kopernicus, but not new worlds.

Link to comment
Share on other sites

10 hours ago, HansAcker said:

It depends on what your goal is.

It's simple. I want to help with development of one small planet pack. Ability to add collidable surface objects is fine too. But I also want to add some notable features to planets to give players more motivation to go there. I have some small modeling skills and want to add something hand-made.

Thank you for your example. Now I have more understanding.

Link to comment
Share on other sites

17 hours ago, Jognt said:

So uhm, about that framerate thing.. :/

<snipped>

Pinging those with interest: @Diddly Feelerino @Starwaster

Edit: Just in case it's not clear; Considering the amount of refactoring that was done I would be surprised if there weren't any bugs. It's a massive piece of work, and I appreciate the effort that has gone into it.

Edit 2: Maybe it's related to the foreach in FixedUpdate() in ring.cs?

Quite a few modders around here will tell you to avoid foreach like the plague, at least when it's being done every FixedUpdate / Update. But is that code even executing for a body which has no rings? (or even if it does; it would be a foreach on an empty list)

Link to comment
Share on other sites

Hey guys,

it seems I have a major problem with the most recent Kopernicus (1.7.3-1). I got myself a new laptop with strong graphics (gtx 1660ti) and therefore pimped up my KSP visuals via various mods. Everything runs very smoothly (100+ fps) and looks beautiul, with one exception: When I approach Duna for landing (near the surface), fps suddenly drop to 6 and remain there. Also after landed. I even started a new save and sent a rudimentary rover (5 parts) to Duna via Hexedit, issue still persists. All other bodies I visited so far were running fine.

After a long search via uninstalling mods mod by mod I found that the most recent version of Kopernicus seems to be culprit. I checked that by installing an older version of Kopernicus (1.7.0-1, randomly chosen), that worked fine again, the 5 part rover was standing very smoothly on Duna. I cannot use that with my main save though since I am playing with OPM, that makes the save break when loaded with the older version of K. 

All my mods are up to date (or at least compatible), and as said, everything it running smoothly without Kopernicus or with an older version of it (or on another planet than Duna). I would like to send you the log file and the Kopernicus log zip but can't find any upload button?

Any advise appreciated! :)

Link to comment
Share on other sites

24 minutes ago, pawelz said:

Hey guys,

it seems I have a major problem with the most recent Kopernicus (1.7.3-1). I got myself a new laptop with strong graphics (gtx 1660ti) and therefore pimped up my KSP visuals via various mods. Everything runs very smoothly (100+ fps) and looks beautiul, with one exception: When I approach Duna for landing (near the surface), fps suddenly drop to 6 and remain there. Also after landed. I even started a new save and sent a rudimentary rover (5 parts) to Duna via Hexedit, issue still persists. All other bodies I visited so far were running fine.

After a long search via uninstalling mods mod by mod I found that the most recent version of Kopernicus seems to be culprit. I checked that by installing an older version of Kopernicus (1.7.0-1, randomly chosen), that worked fine again, the 5 part rover was standing very smoothly on Duna. I cannot use that with my main save though since I am playing with OPM, that makes the save break when loaded with the older version of K. 

All my mods are up to date (or at least compatible), and as said, everything it running smoothly without Kopernicus or with an older version of it (or on another planet than Duna). I would like to send you the log file and the Kopernicus log zip but can't find any upload button?

Any advise appreciated! :)

Advice: Read the past few pages

Link to comment
Share on other sites

20 minutes ago, pawelz said:

I checked that by installing an older version of Kopernicus (1.7.0-1, randomly chosen)

Did you try it on a KSP 1.7.0 install? Kopernicus is version locked so if you tried it in your 1.7.3 game, kopernicus didn't actually run ;)

21 minutes ago, pawelz said:

I would like to send you the log file and the Kopernicus log zip but can't find any upload button?

There is none, you need to upload files to a third-party filehoster or cloud service (dropbox, google drive, one drive..) and share a download link for us.

In general, there are are some reports about performance issues recently, just look through the last one or two pages of this thread, especially @Jognt is doing some intensive research on this.

Btw: I wasn't able the replicate the issue so far...

Link to comment
Share on other sites

19 minutes ago, 4x4cheesecake said:

Btw: I wasn't able the replicate the issue so far...

That's interesting, thank you for checking. Could you elaborate on how/where you tested?
Could you perhaps check the persistent save I uploaded earlier? The screenshots with memgraph were taken with that save by going to the tracking station and loading up Bill on the Mun.
If you're not seeing the same memgraph numbers, my mind is probably going to explode.. :confused:

 

46 minutes ago, pawelz said:

Hey guys,

it seems I have a major problem with the most recent Kopernicus (1.7.3-1). I got myself a new laptop with strong graphics (gtx 1660ti) and therefore pimped up my KSP visuals via various mods. Everything runs very smoothly (100+ fps) and looks beautiul, with one exception: When I approach Duna for landing (near the surface), fps suddenly drop to 6 and remain there. Also after landed. I even started a new save and sent a rudimentary rover (5 parts) to Duna via Hexedit, issue still persists. All other bodies I visited so far were running fine.

After a long search via uninstalling mods mod by mod I found that the most recent version of Kopernicus seems to be culprit. I checked that by installing an older version of Kopernicus (1.7.0-1, randomly chosen), that worked fine again, the 5 part rover was standing very smoothly on Duna. I cannot use that with my main save though since I am playing with OPM, that makes the save break when loaded with the older version of K. 

All my mods are up to date (or at least compatible), and as said, everything it running smoothly without Kopernicus or with an older version of it (or on another planet than Duna). I would like to send you the log file and the Kopernicus log zip but can't find any upload button?

Any advise appreciated! :)

Yes, there have been a number of reports of horrible framerate problems with Kopernicus. At the moment it's still unclear what exactly is the cause and more importantly what may fix it, but hopefully someone has an "aha!" moment.
For now you can reduce the impact of the performance hit by disabling Terrain Scatter and/or disabling the new Breaking Ground ROCs via a savefile edit. (own risk! so i suggest going with disabling just the terrain scatter)

 

1 hour ago, Starwaster said:

Quite a few modders around here will tell you to avoid foreach like the plague, at least when it's being done every FixedUpdate / Update. But is that code even executing for a body which has no rings? (or even if it does; it would be a foreach on an empty list)

Good point. I am not nearly skilled enough in C# to know what/how. Even trying to piece together what's going on in the first place is a learning experience by itself.

I wish it was possible to analyze the code in realtime to see how much time the game's thread spends in certain methods, but writing that debug code itself is also out of my league <_<

Edited by Jognt
Link to comment
Share on other sites

42 minutes ago, Jognt said:

That's interesting, thank you for checking. Could you elaborate on how/where you tested?
Could you perhaps check the persistent save I uploaded earlier? The screenshots with memgraph were taken with that save by going to the tracking station and loading up Bill on the Mun.
If you're not seeing the same memgraph numbers, my mind is probably going to explode.. :confused:

I basically did the same thing you've shown in the video: I put a small vessel on the mun, a Kerbal on EVA ~200m away and tested this scene with different setups:

  • Stock
  • Stock + Kopernicus
  • Stock + Kopernicus + SVT

(Of course, dependencies are installed as well)

Graphic settings were set to max incl. maximal amount of ground scatter (while running SVT, colliders were enabled for ground scatter as well).

Result was pretty much the same each time, the game was running smooth at 60 FPS, just a few times it "slowed" down to 57 FPS but nothing really bad happened. The slightly lower FPS only happened to the modded installs though (both).

I can try your savegame and provide some memgraph screenshots tomorrow.

edit: I should mention that I always cap the FPS at 60 through the game settings.

Edited by 4x4cheesecake
Link to comment
Share on other sites

@4x4cheesecake

Are you using any non-stock planetary systems with Kopernicus? I don't believe just installing Kopernicus is going to be sufficient. You probably are going to need another planetary pack such as SigmaDimensions + rescaled Kerbol or JNSQ. Real Solar System has yet to be officially updated for 1.7.3 and I suspect it will also have to have surface features (ROC) defined for it and when it does we'll probably see issues there too.

Link to comment
Share on other sites

1 hour ago, 4x4cheesecake said:

I basically did the same thing you've shown in the video: I put a small vessel on the mun, a Kerbal on EVA ~200m away and tested this scene with different setups:

  • Stock
  • Stock + Kopernicus
  • Stock + Kopernicus + SVT

(Of course, dependencies are installed as well)

Graphic settings were set to max incl. maximal amount of ground scatter (while running SVT, colliders were enabled for ground scatter as well).

Result was pretty much the same each time, the game was running smooth at 60 FPS, just a few times it "slowed" down to 57 FPS but nothing really bad happened. The slightly lower FPS only happened to the modded installs though (both).

I can try your savegame and provide some memgraph screenshots tomorrow.

edit: I should mention that I always cap the FPS at 60 through the game settings.

Hmm, interesting. My FPS is usually capped at 80 and with vsync disabled but I uncapped it during the tests.
60 -> 57 fps sounds like the usual per-frame fluctuations.

Looking forward to the memgraph results and how my persistent.sfs faires on your machine. What CPU do you have if I may ask?

I'll do some more tests tomorrow if the temperature here is survivable (heatwave..). I've got a few things I want to check as well.

Thanks for the help!

Edited by Jognt
Link to comment
Share on other sites

16 minutes ago, Starwaster said:

@4x4cheesecake

Are you using any non-stock planetary systems with Kopernicus? I don't believe just installing Kopernicus is going to be sufficient. You probably are going to need another planetary pack such as SigmaDimensions + rescaled Kerbol or JNSQ. Real Solar System has yet to be officially updated for 1.7.3 and I suspect it will also have to have surface features (ROC) defined for it and when it does we'll probably see issues there too. 

I've tried to recreate the issue shown in this post and @Jognt explicit mentioned that this is just the stock system + kopernicus. This test would identify kopernicus as the culprit of the issue, especially when it can be replicated by others. Since it looks way better in my test compared to the scenes shown in the video, it might be something really weird. Will be interesting to compare the memgraph readouts.

Link to comment
Share on other sites

26 minutes ago, 4x4cheesecake said:

I've tried to recreate the issue shown in this post and @Jognt explicit mentioned that this is just the stock system + kopernicus. This test would identify kopernicus as the culprit of the issue, especially when it can be replicated by others. Since it looks way better in my test compared to the scenes shown in the video, it might be something really weird. Will be interesting to compare the memgraph readouts.

Besides the memgraph readout I’m _very_ curious how KSP performs with my save. Sounds like it would perform nominally, though I hope you'll forgive me if I hope that it performs similarly to local. 

Edit: and yes, that video is a fresh 1.7.3 KSP install with just Kopernicus, memgraph, and dependencies. 

Edited by Jognt
Link to comment
Share on other sites

I'm having an issue regarding distant stars not having their brightness disk rendered, despite a non-zero "infinite distance" radius value:

brightnessCurve
{
	key = 0 0.105 0 25
	key = 0.01 0.2 0.5 0.5
	key = 1 0.6 0.5 0.5
	key = 5 3 0 0
	key = 10 3 0 0
	key = 50 2 0 0
	key = 200 2 0 0
}

Could this be caused by RSSVE, or are my brightnessCurve keys just too small? I'd like for the star to be a distinguishable point on a 1920x1080 display.

Link to comment
Share on other sites

1 hour ago, Starwaster said:

@4x4cheesecake

Are you using any non-stock planetary systems with Kopernicus? I don't believe just installing Kopernicus is going to be sufficient. You probably are going to need another planetary pack such as SigmaDimensions + rescaled Kerbol or JNSQ. Real Solar System has yet to be officially updated for 1.7.3 and I suspect it will also have to have surface features (ROC) defined for it and when it does we'll probably see issues there too.

A bit of rescaling and resizing is enough for my physics speed to take seven times longer when under a certain altitude above ground arouind Mun - landing and landed the same. No "new" planets needed it seems.
I also deactivated Terrain Scatter and set the slider to 0% for good measure - not been to any ROCs yet.

Interestingly the issue is - so far, didn't do too much yet in this save - not happening on Kerbin, or at least not consistently because my first launch from Woomerang was sluggish as slugs as well, now it is as smooth as a modded KSP can be.

Link to comment
Share on other sites

Small update. No conclusions, just datapoints:

  • When the FPS drops, my CPU and GPU usage drops by quite a bit as well, so whatever it is, it's not bottlenecked by processing power, I'm guessing it may be getting stuck in a loop or something?
  • When I dropped my graphics settings to 1080p and turned off lots of things, memgraph reported per frame garbage creation of 20MB on the Mun in my uploaded save. Setting everything back to normal/higher settings made it drop back to 10-15MB.
  • Enabling/disabling vSync did nothing (a bit of a stretch, but I 'had a theory')
  • I also tried setting the max physics delta time to it's rightmost position in the slider to see if that did anything, no impact on performance, still in the "feels like 5 fps" zone with a constant yellow clock.

If I have new findings, I shall return. o7

Edited by Jognt
Link to comment
Share on other sites

19 hours ago, Jognt said:

Besides the memgraph readout I’m _very_ curious how KSP performs with my save. Sounds like it would perform nominally, though I hope you'll forgive me if I hope that it performs similarly to local.

You're save actually shows the same performance issue for me. I could post quite a few screenshots of memgraph and other fancy stuff but that wouldn't help in anyway...we already know all these graphes from you^^ So I've decided to setup a profiler for kopernicus instead and do some more investigations. Well, I have honestly almost no idea what I'm doing here, so don't expect too much :D

So, let's take a look at this screenshot from the profiler:

Spoiler

ysSrHym.png

Exactly in the moment your vessel becomes unpacked (getting closer then 200m), the CPU usage increases massively and you can also see, that it is specifically the "FixedUpdate" method which takes all the resources.

Now, let's look at the code:

There is exactly one method which is called, as soon as a part becomes unpacked and this method will replace the stock part buoyancy, with the kopernicus part buoyancy. The new buoyancy component indeed runs a "FixedUpdate" method. In this FixedUpdate, three other methods are called: GetOcean, GetAltitudeFromOcean and GetBaseFixedUpdate. By commenting out one by one, I've figured out that the performance issues are gone while "GetOcean" was removed.

Since I don't like to log anything in a Update method, I've set the private fields of "KopernicusBuoyancy" to public, installed the "Kerbal Object Inspector" and noticed that the "_ocean" field is always "Null", even though it should contain a valid entry after the first FixedUpdate:

Spoiler

s2GGzSa.png

Since the field is always null, KopernicusBuoyancy will try to create an entry on each FixedUpdate. The more parts are unpacked, the worse the lag becomes (That's probably the reason why the issue didn't appear in my install. The vessel I've used had just 8 parts).

Well, have to stop here, it's way too warm today for these kind of things, but I wanted to share my results so far...maybe someone more experienced stops by and want to do more debugging^^

Link to comment
Share on other sites

27 minutes ago, 4x4cheesecake said:

You're save actually shows the same performance issue for me. I could post quite a few screenshots of memgraph and other fancy stuff but that wouldn't help in anyway...we already know all these graphes from you^^ So I've decided to setup a profiler for kopernicus instead and do some more investigations. Well, I have honestly almost no idea what I'm doing here, so don't expect too much :D

So, let's take a look at this screenshot from the profiler:

  Hide contents

ysSrHym.png

Exactly in the moment your vessel becomes unpacked (getting closer then 200m), the CPU usage increases massively and you can also see, that it is specifically the "FixedUpdate" method which takes all the resources.

Now, let's look at the code:

There is exactly one method which is called, as soon as a part becomes unpacked and this method will replace the stock part buoyancy, with the kopernicus part buoyancy. The new buoyancy component indeed runs a "FixedUpdate" method. In this FixedUpdate, three other methods are called: GetOcean, GetAltitudeFromOcean and GetBaseFixedUpdate. By commenting out one by one, I've figured out that the performance issues are gone while "GetOcean" was removed.

Since I don't like to log anything in a Update method, I've set the private fields of "KopernicusBuoyancy" to public, installed the "Kerbal Object Inspector" and noticed that the "_ocean" field is always "Null", even though it should contain a valid entry after the first FixedUpdate:

  Reveal hidden contents

s2GGzSa.png

Since the field is always null, KopernicusBuoyancy will try to create an entry on each FixedUpdate. The more parts are unpacked, the worse the lag becomes (That's probably the reason why the issue didn't appear in my install. The vessel I've used had just 8 parts).

Well, have to stop here, it's way too warm today for these kind of things, but I wanted to share my results so far...maybe someone more experienced stops by and want to do more debugging^^

 

Thank you so much!

Im guessing the next question would be “why doesnt _ocean behave?”? 

Ps. Way too warm here today aswell. I wont be doing intensive things like ‘thinking’ until it cools down :D 

Edited by Jognt
Link to comment
Share on other sites

40 minutes ago, Jognt said:

 

Thank you so much!

Im guessing the next question would be “why doesnt _ocean behave?”? 

Ps. Way too warm here today aswell. I wont be doing intensive things like ‘thinking’ until it cools down :D 

So the Lag actually seems to be connected to the No-Ocean-Collider Issue I posted about three pages back.
I just tried out the workaround for it on the Mun and it flows buttery smooth now! Lag is completely gone.
So workaround for lag until next Kopernicus Update:

Whenever you upscale any object, add this line into it's body:

		%Ocean
		{
			maxQuadLengthsPerFrame = 0.03
		}

This forces Kopernicus to initialize "Some" Ocean-instance based on default values (if the object doesn't have an ocean, there won't be one).
Therefor these FixedUpdate-calls for each part no longer tries to de-reference a Null pointer and everything runs as intended.

Thanks for the bugtracking guys, this lag really drove me crazy.

EDIT: !EXCEPT JOOL! Don't add an ocean object to a gas giant, it will cause an exception on loadup. All solid bodies swallow the fix though, no more lag.

EDIT 2 : There is actually an ocean added. In case of the moon it sits well below the surface though. Are there any bodies with negative heights? if not it shouldn't be a problem.

Edited by SkyRex94
Link to comment
Share on other sites

31 minutes ago, SkyRex94 said:

So the Lag actually seems to be connected to the No-Ocean-Collider Issue I posted about three pages back.
I just tried out the workaround for it on the Mun and it flows buttery smooth now! Lag is completely gone.
So workaround for lag until next Kopernicus Update:

Whenever you upscale any object, add this line into it's body:


		%Ocean
		{
			maxQuadLengthsPerFrame = 0.03
		}

This forces Kopernicus to initialize "Some" Ocean-instance based on default values (if the object doesn't have an ocean, there won't be one).
Therefor these FixedUpdate-calls for each part no longer tries to de-reference a Null pointer and everything runs as intended.

Thanks for the bugtracking guys, this lag really drove me crazy.

EDIT: !EXCEPT JOOL! Don't add an ocean object to a gas giant, it will cause an exception on loadup. All solid bodies swallow the fix though, no more lag.

EDIT 2 : There is actually an ocean added. In case of the moon it sits well below the surface though. Are there any bodies with negative heights? if not it shouldn't be a problem.

Awesomesauce; will give this a go!

PS - Sorry for the lack of activity lads; been stuck in an intensive class for the past week (will be a bit "free-er" next Thursday).

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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.

×
×
  • Create New...