[1.8.1 - 1.9.1] Kopernicus Continued

[Al2Me6]

1 hour ago, R-T-B said:

Makes me wonder if it's GPU-specific then (I use AMD GPU, but usually, we have the bugs, not vice versa).  Either way, odd, and it doesn't help that I as a dev can't reproduce of course.  It's a very real bug I am sure though.

My machine has an RX580, so it's not that. I don't see it very often though - twice or so on Kerbin and maybe once on the Mun?

There's also this:

 

[R-T-B]

1 hour ago, Al2Me6 said:

My machine has an RX580, so it's not that. I don't see it very often though - twice or so on Kerbin and maybe once on the Mun?

There's also this:

 

Yeah it feels more like a stock bug but we'll be keeping an eye on it regardless.

[Vabien]

I use an RX 580 so it's definitely not a gpu issue

edit: Lmao didn't notice the reply. Likely a stock bug but we'll see.

 

Edited July 28, 2020 by Vabien

[Hohmannson]

7 hours ago, OhioBob said:

I get the bug all the time.  It's not every planet, however.  When it occurs, the only way I've been able to get rid of it is to close KSP and restart.  And that's usually just a temporary fix.

I didn`t seen it on GEP(primary). Did you? If it does not show on stock textures, maybe it is a key to problem.

[Shawn Kerman]

1.10.1 is now out, can't any bugfixes can could affect kopernicus ( other then Comet spawning) so a silent recompile should do the trick for now.

Edited July 28, 2020 by Shawn Kerman
re-wording

[Nigel239]

32 minutes ago, Shawn Kerman said:

1.10.1 is now out, can't any bugfixes can could affect kopernicus ( other then Comet spawning) so a silent recompile should do the trick for now.

Could you maybe help me find the 1.10.1 update? I can't seem to find it myself sadly

[Hohmannson]

1 hour ago, Nigel239 said:

Could you maybe help me find the 1.10.1 update? I can't seem to find it myself sadly

If it is about Kopernicus, afaik it will appear here https://github.com/R-T-B/kopernicus/releases , not ready yet.

[Hpl]

he meant ksp 1.10.1, which just came out

[R-T-B]

I just updated 1.10.1 on my bleeding edge branch.  Grab it if that's your fancy.  It has some swanky new multistar math, which while cool, also has some limits I'd like to discuss here before considering it for mainline.

Warning technical details follow, skip ahead to the bottom if easily bored:

It seems there are several assumptions done within the stock game engine that assume a single star.  This makes implementing multistar properly (without crazy bad math) hard to implement.  Let me try to explain.

KSP only allows a single star to be active at any given time.  Kopernicus tries to get around this with an elaborate "light shifter" system that "pulses" each star during a frame once, and tallies the ECs, heat flux, etc on the panel during that pulse, and then at least for ECs, the net result of ECs from every star pulse is the total.  The call for the light portion (the portion solar panels care about) rather than the flux/heat portion is called "ApplyPhysics), and unfortunately, it's way way too slow.  So slow in fact that the physics don't get applied in the same frame, and we get a Sun with the properties of a Red dwarf, or vice versa, or all sorts of crazy combinations and the math goes nuts, leading to thousands of or sometimes (I've seen this) even negative EC production.

Fortunately, the heat part, ApplyFlux, works quickly and fine.  This means that:

At least as of now, I can't do multistar light support.  Light accepted at the panel (and thus, contributing to EC) will be limited to the tracked body.  Flux/heat/"that thing that melts you", as the game engine considers it, works fine and will apply like it always did, from all stars.  But the panels will only get ECs from the tracked body.  So track a smart body and don't run out of EC!

Also fortunately, autotracking still works, because it can wait a few frames to decide what star to select without consequence.  So the panels still do auto pick the best body, if needed.

 

Bottom line:  For sanity reasons, and maybe even what is technically possible, right now Kopernicus limits panels to only accept light to the tracked star.  How big of a deal is this to most of you?  It may/may not be permanent, depending on the amount of effort required to fix major bugs in KSPs logic around stars (it really can't grasp more than one in terms of ECs).

5 hours ago, Nigel239 said:

Could you maybe help me find the 1.10.1 update? I can't seem to find it myself sadly

The link the other guy gave you is now good, I updated.  It's the "_1101_" zip file (lol that sounds like binary code).

Edited July 29, 2020 by R-T-B

[Nigel239]

7 hours ago, R-T-B said:

I just updated 1.10.1 on my bleeding edge branch.  Grab it if that's your fancy.  It has some swanky new multistar math, which while cool, also has some limits I'd like to discuss here before considering it for mainline.

Warning technical details follow, skip ahead to the bottom if easily bored:

It seems there are several assumptions done within the stock game engine that assume a single star.  This makes implementing multistar properly (without crazy bad math) hard to implement.  Let me try to explain.

KSP only allows a single star to be active at any given time.  Kopernicus tries to get around this with an elaborate "light shifter" system that "pulses" each star during a frame once, and tallies the ECs, heat flux, etc on the panel during that pulse, and then at least for ECs, the net result of ECs from every star pulse is the total.  The call for the light portion (the portion solar panels care about) rather than the flux/heat portion is called "ApplyPhysics), and unfortunately, it's way way too slow.  So slow in fact that the physics don't get applied in the same frame, and we get a Sun with the properties of a Red dwarf, or vice versa, or all sorts of crazy combinations and the math goes nuts, leading to thousands of or sometimes (I've seen this) even negative EC production.

Fortunately, the heat part, ApplyFlux, works quickly and fine.  This means that:

At least as of now, I can't do multistar light support.  Light accepted at the panel (and thus, contributing to EC) will be limited to the tracked body.  Flux/heat/"that thing that melts you", as the game engine considers it, works fine and will apply like it always did, from all stars.  But the panels will only get ECs from the tracked body.  So track a smart body and don't run out of EC!

Also fortunately, autotracking still works, because it can wait a few frames to decide what star to select without consequence.  So the panels still do auto pick the best body, if needed.

 

Bottom line:  For sanity reasons, and maybe even what is technically possible, right now Kopernicus limits panels to only accept light to the tracked star.  How big of a deal is this to most of you?  It may/may not be permanent, depending on the amount of effort required to fix major bugs in KSPs logic around stars (it really can't grasp more than one in terms of ECs).

The link the other guy gave you is now good, I updated.  It's the "_1101_" zip file (lol that sounds like binary code).

Ahh you legend! thankyou! Will be sure to use this mod and try to help you find any unwelcome bugs

[MechBFP]

21 hours ago, R-T-B said:

Bottom line:  For sanity reasons, and maybe even what is technically possible, right now Kopernicus limits panels to only accept light to the tracked star.  How big of a deal is this to most of you? 

In my opinion this is a non-issue. Its simply not worth the effort to fix something that really has no practical benefit the vast majority of the time. If a ship literally needs light from both stars to function, it is badly designed. Its a gimmick more than anything.

[splet]

On 7/27/2020 at 11:42 PM, R-T-B said:

Yeah it feels more like a stock bug but we'll be keeping an eye on it regardless.

On that subject, I've noticed the same checkerboarding/terrain glitching while testing a save of GamesLinx's Beyond Home. I saw Armstrong mentioned earlier, but after a bit of exploration both in the Kopernicus configs and in the actual mod, it appears the checkerboarding happens most often on bodies that are based upon Jool's moons.
Said testing was done in sandbox with cheats on (mainly since I aim to construct a full-ish suite of third-party actual sciencedefs for the mod), but I first noticed the issues when approaching Gateway with no cheats enabled.

I was and still am running a recent-ish build of Kopernicus 1.9.1 with several part-mods, EVE, and scatterer as recommended by Linx in his forum post. It might be worthy of note that my copy of EVE is the one built for 1.8.x, but it seems to be working just fine in 1.9.1.

Out of the bodies I've checked,

Rhode (based on Kerbin) had no problems at all.
Lua (based on Laythe) had few problems at its KK launchsite but had checkerboarding and terrain glitches when landed and revisited.
Armstrong (based on Tylo) had consistent checkerboarding and terrain-shadow artefacting.
Gateway (based on Laythe) had consistent and alarming checkerboarding, so bad that it actually completely erased parts of the PQS sphere terrain.
Rock (based on Moho) had zero problems at all. Then again, I did slam into it extremely hard.

All checkerboarded bodies appear completely normal from orbit and appear extremely ugly as soon as real terrain loads in.

I would check more of them, but am currently in the process of moving houses; my current hunch is that most, if not all modded bodies based upon Jool's moons, or at least Laythe and Tylo, have this issue for little to no discernible reason.

Edited July 29, 2020 by splet
clarifying what i meant by gateway's checkerboarding error

[R-T-B]

1 hour ago, MechBFP said:

In my opinion this is a non-issue. Its simply not worth the effort to fix something that really has no practical benefit the vast majority of the time. If a ship literally needs light from both stars to function, it is badly designed. Its a gimmick more than anything.

 

I keep telling myself that but am also in discussions with @OhioBob about the math, so maybe we can have our cake and eat it too.  We'll see.

[OhioBob]

3 hours ago, MechBFP said:

In my opinion this is a non-issue. Its simply not worth the effort to fix something that really has no practical benefit the vast majority of the time. If a ship literally needs light from both stars to function, it is badly designed. Its a gimmick more than anything.

If a shortcut is needed, I think it might be better to have solar panels illuminated only by the star whose SOI it is in rather than by the star it is tracking.  Generally the light received from a star outside the current SOI is so weak that it's inconsequential.

The principal exception I can think of where both stars might contribute a significant fraction of light received is if we are in a circumbinary orbit.  That is, we are orbiting both stars of a close binary pair.

@R-T-B, with the method in current use, what happens with fixed panels that don't track any star?  Which star do they receive light from?  That's something I didn't think to check during my tests.

Edited July 30, 2020 by OhioBob

[R-T-B]

1 hour ago, OhioBob said:

@R-T-Bwith the method in current use, what happens with fixed panels that don't track any star?  Which star do they receive light from?

That's a really good question.

Technically, they are in a seperate "if" branch, so I didn't alter their code at all.  If they are functioning right though, one would very much wonder how, and maybe we could glean something from them.  Or if they are broken, I should probably fix that.  Either way, very good question that I am going to test out right now.

[Hohmannson]

2 hours ago, splet said:

most often on bodies that are based upon Jool's moon

You are right. I managed to change Armstrong`s template to Ike and checkers are gone. Completely gone. I see some shadow flickering on surface, (those triangles seems to outline actual terrain geometry) but i think it is because of my dirty "fixing". Looks like you`ve discovered a workaround, thank you! 

P.S. They were seeing checkers on JNSQ Moho in 1.8.1 - possibly because Moho got its terrain revamp only in 1.9, and JNSQ Moho was templated Moho. In 1.9 it got the revamp and checkers are gone. And i think we see checkers on Jovian moon-templated celestials because they do not have their terrain revamp yet. Maybe we`ll see it on Eeloo-templated things too.

Edited July 30, 2020 by Hohmannson

[R-T-B]

2 minutes ago, Hohmannson said:

You are right. I managed to change Armstrong`s template to Ike and checkers are gone. Completely gone. I see some shadow flickering on surface, (those triangles seems to outline actual terrain geometry) but i think it is because of my dirty "fixing". Looks like you`ve discovered a workaround, thank you!

Thank you for confirming it is Joolian moon-templates that seem to do this worst.

I'm unsure why.  The only thing I can think of is that maybe they feature the atlas shader and others do not?  (Laythe got atlas in 1.10, maybe others).

Edited July 30, 2020 by R-T-B

[Hohmannson]

37 minutes ago, R-T-B said:

Laythe got atlas in 1.10

I was tinkering with it on 1.9.1, the latest of Prestja branch. I assume that custom bodies with new shader, templated to bodies that doesn`t have that new shader in stock yet(all Jovian moons in 1.9.1 and Eeloo(not tested for Eeeloo)), are mostly subject to that "kerbal chess program" glitch. Will go Vasto(laythe-templated) later, i think it will be checkered on 1.9.1, and on 1.10.1 the checkers will go away.

[R-T-B]

2 hours ago, Hohmannson said:

I was tinkering with it on 1.9.1, the latest of Prestja branch. I assume that custom bodies with new shader, templated to bodies that doesn`t have that new shader in stock yet(all Jovian moons in 1.9.1 and Eeloo(not tested for Eeeloo)), are mostly subject to that "kerbal chess program" glitch. Will go Vasto(laythe-templated) later, i think it will be checkered on 1.9.1, and on 1.10.1 the checkers will go away.

That would be interesting to know.

[R-T-B]

Release 7, fixing nearly all (if not all) multistar panel EC issues is out.  Major shoutout to @OhioBob for help with the math, and my team of testers at Kopernicus Bleeding edge for helping me test the code.  The bleeding edge also has these same fixes, obviously.

Download in OP or here:

https://github.com/prestja/Kopernicus/releases

 

Edited August 15, 2020 by R-T-B

[prestja]

15 hours ago, R-T-B said:

I'm unsure why.  The only thing I can think of is that maybe they feature the atlas shader and others do not?

Not Atlas, but a different shader altogether, specific to gas giants.

[R-T-B]

1 hour ago, prestja said:

Not Atlas, but a different shader altogether, specific to gas giants.

The moons?  That's what we were discussing.

[Hohmannson]

13 hours ago, R-T-B said:

That would be interesting to know.

I was right, Splet was right. 1.10.1, your Kopernicus runs fine, Laythe-templated planets are not bugged anymore(laythe got the shaders), tylo templated ones are still checkered. I assume, vall-pol-bop-eeloo are too. For Beyond Home, changing the template is safe, so i managed do "fix" all the pack. Other packs may be not that easy. Linx issued an announcement about cursed templates in Kopericus discord. It is interesting, i am not sure what shady squad mechanism is breaking them. It will fix itself when all stock bodies will got revamps, but i think you should know.

Edited July 30, 2020 by Hohmannson
typo fix

[prestja]

5 minutes ago, R-T-B said:

The moons?  That's what we were discussing.

My bad. You're right, moons templated off of Moho will have a different shader (Atlas) than those from say Vall.

[Souptime]

EDIT: Oop nevermind

Edited August 1, 2020 by Souptime