[1.8.1 - 1.9.1] Kopernicus Continued

[hemeac]

@R-T-B, Not sure if this is related, but @Iodyne noticed that 1-P Geito in the Minor Planets Expansion (based off the Gilly template) also has the lighting off by 90 degrees (link: Minor Planets Expansion).  They've linked to their log file.  I can confirm I see it both in the 1.9.1-4 release as well as your 1.10.0 Prelease 4 which is shown below.  Here's my log file: KSP Log

Spoiler

 

[krenshala]

Just fired up 1.10 with the prerelease4 and latest OPM version, and at least in the tracking station i'm also seeing the 90 shadow being off on the gas giants (but not the rings around them), except for Jool (which has the shadow facing correctly).

BTW, thank you all for reviving the one mod required to load the two mods (Kop + OPM) I was missing.

edit - hemeac's comment makes me wonder about Eeloo ...

Edited July 17, 2020 by krenshala

[Drupegod02]

Does this mod work in 1.10? Because i want to install Outer Kerbin, SpudMoon, and Kerbin Rings. Will there be any problems?
 

 

 

 

[Iodyne]

I think it's important to note @hemeac I that the lighting issue is only for the in the map and tracking view but not in flight (unless zoomed out very far). So something to do with the scaled-space representation. I didn't see anything similar for any of the other bodies in OPM & Minor Planets Expansion (MPE).

[Hpl]

35 minutes ago, Drupegod02 said:

Does this mod work in 1.10? Because i want to install Outer Kerbin, SpudMoon, and Kerbin Rings. Will there be any problems?
 

 

 

 

@R-T-B's build does, but im not sure if you can play it instead of test it on its current state

with that i mean it can be buggy(?)

[R-T-B]

Yep the shadow bug is alive and well, sadly.

I spent all day tracking it down.  It turns out the issue has been there since Kopernicus 1.8 but only on non-jool templated gas giants, and with each release, it's been getting bigger and affecting more body types.  Kinda scary eh?  lol.

After an exhaustive day of poking through the code, I found the culprit.  It's old normal maps Kopernicus depends on that are being removed from KSP to make way for the atlas shader.  Without them, it doesn't know where to place the shadows.  They've been doing this slowly, hence the progressive growth of the bug.

That's a laymans version, but it's basically what's happening.

I will have a fix tomorrow, too tired now.  I advise anyone bothered by it to apply a simple normal map in the Koperncisu config (this fixes it) or even easier, just install either EVE or scatterer to take over shadows.

But for today, no more fixes, because I am braindead from figuring that out.  Instead, have a baby fix for a nullref in the science archives.  At least it's progress!  I also reverted some bad fixes that just made bodies like Eeloo and Gilly get worse rather than fix anything, so that's good, right?

---------------------------------------------------------------------------------------------------------------------------------------------------------

Prerelease 5 has the following fixes:

1.) Fix a mild nullref in the science archives that was probably harmless, but why not fix?

2.)  Make shadows on non-gas giants behave again (hopefully).

Known bugs:

The gas giant shadow bug is presently still bugging out. You are advised to use Scatterer or EVE to get proper shadows on gas giants, rather than 90 degree rotated ones. This will be fixed soon(tm).

Thank you for your early testing!

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

On 7/17/2020 at 5:00 PM, Hpl said:

@R-T-B's build does, but im not sure if you can play it instead of test it on its current state

with that i mean it can be buggy(?)

It's actually very playable, but it has a bug with gas giant shadows that needs scatterer or EVE to get them pointed the...  right direction lol.  Other than that, it's really usable.  That's pretty much the last bug.

On 7/17/2020 at 4:35 PM, Iodyne said:

I think it's important to note @hemeac I that the lighting issue is only for the in the map and tracking view but not in flight (unless zoomed out very far). So something to do with the scaled-space representation. I didn't see anything similar for any of the other bodies in OPM & Minor Planets Expansion (MPE).

Yep it's scaled space only.  Weird.

Edited August 15, 2020 by R-T-B

[R-T-B]

Prerelease 6 for 1.10 just dropped with the gas giant shadows finally fixed!  That's pretty much the last major bug!  Prove me wrong... hehe.

Prerelease 6 has the following fixes:

1.) Finally fixed the nasty gas giant shadow bug. It should fix all bodies completely in all scenarios. Please completely delete your entire kopernicus directory and then replace it with this one when installing, as new files were added (a reference normalmap to aid with shadows when none is available, mainly).

Thank you for your early testing!

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

Since this has been well-tested privately throughout today, I will be pushing it to the 1.9.1 branch as well and drafting a release there shortly.  I feel that getting this fix out in a timely fashion outweight discussing it with Prestja, which I'm sure he'll approve it anyhow.   We can always refine it later if need be.

So yeah, watch for a new 1.9 release soon as well.

EDIT:

Here she is:  Release 5 for 1.9.1:  Same shadows fix as above (it was bugged too just didn't affect any bodies but very specifc types of gas giants).

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

Edited August 15, 2020 by R-T-B

[Poodmund]

Why bundle a normal map texture for gas giant use if one isn't specified when you could just leverage the vanilla one?

[kubi]

Something got totally messed up with my 1.9.1 install.

https://drive.google.com/drive/folders/1AeSytzclHST2eVSCCPjZV8YXPfsbKK7C?usp=sharing

Thought that it is Trajectories that I've installed, but not.

Tried 1.9.1-5 first today, rolled back to 1.9.1-4 (logs are about -4).

There were some fresh updates through CKAN (science alert, clickthrougblocker and planetary base systems), but none of those should interfere.

----- edit ----

Or, it might be that -5 messed up something.

Tried with a clean install. First -5, it was faulty. Then -4, it is fine now. But needed to do a quite big cleanup...

Edited July 18, 2020 by kubi

[boniny4]

does that work for 1.10?

[R-T-B]

7 hours ago, Poodmund said:

Why bundle a normal map texture for gas giant use if one isn't specified when you could just leverage the vanilla one?

It's not ideal and was/is intended as a stopgap until I could internally generate one using a new Texture2D line internally with Unity.

That said, I'm not as familiar with Kopernicus as I should be at times, so forgive me if I sound idiotic here:

There's a vanilla one?  If you mean the previous one for gas giants, that's the whole issue.  They (squad) are pulling the vanilla normal maps for gas giants out in 1.10 with the new shader, or at least the ways we used to reference them aren't working anymore.  Jool templated bodies will no longer function in 1.10 using that normal map, and in 1.9/1.8, any non-jool templated gas giants are already broken.  This is a future proof way of handling it, if clunky.

I welcome a better PR.  But last night I was just wanting a fix for users and that worked, had a headache and decided to ship it in the interim.

1 hour ago, boniny4 said:

does that work for 1.10?

My  branch does.  It's more beta but pretty bug-free now... 

https://github.com/R-T-B/Kopernicus/releases

6 hours ago, kubi said:

Something got totally messed up with my 1.9.1 install.

https://drive.google.com/drive/folders/1AeSytzclHST2eVSCCPjZV8YXPfsbKK7C?usp=sharing

Thought that it is Trajectories that I've installed, but not.

Tried 1.9.1-5 first today, rolled back to 1.9.1-4 (logs are about -4).

There were some fresh updates through CKAN (science alert, clickthrougblocker and planetary base systems), but none of those should interfere.

----- edit ----

Or, it might be that -5 messed up something.

Tried with a clean install. First -5, it was faulty. Then -4, it is fine now. But needed to do a quite big cleanup...

Keep in mind you MUST completely wipe/replace the Kopernicus folder on -5,   If this is problematic, I'll probably make a release soon that does not require that.

This line tells me that didn't happen:  EDIT SCRATCH THAT.  See below.

Quote

Exception: The file 'Kopernicus/Config/System.cfg' was modified directly without ModuleManager

Edited July 18, 2020 by R-T-B

[R-T-B]

Oh doh!  There was an incorrect system.cfg in our build system.

If anyone downloaded -5 this morning, please redownload, the release was botched (so much for a quick fix, I guess).  It won't run like that, and it was all our/my fault.

Note the actual fix is well-tested, as said.  It's just our build system that screwed up somehow.  Something to do with linux vs Windows having different line endings, I guess.

It's fixed now.  Just redownload from same link.

@kubi, sorry for triggering a late spring-cleaning.

Edited July 18, 2020 by R-T-B

[R-T-B]

Just FYI, I am moving discussion of my bleeding edge branch to here:

This is just to streamline discussion.  I would advise discussion here to focus on bugs in /usage of the stable branch, that is, the one on 1.9.1 linked in the first post of this thread (Prestja's, not mine).  With me supporting both 1.9.1 and 1.10 now, I feel it's better to move to a new thread for my experimental branch.

In that vein, most fixes will now be tested on my branch first before being pushed to the mainline (Prestja's branch, here).  That means we'll all get better quality control.  If you want frequent bug fixes, often same day, my "bleeding edge" branch is for you.  If you want to install and forget, get this one.  Talk about them in their appropriate threads.  Simple, right?

Edited July 18, 2020 by R-T-B

[Artemis17]

Hello guy,

Is it compatible with KSP 1.10 ?

Otherwise is it possible to update it to the latests KSP version ? because I'm working on a graphics mod and I need Kopernicus to add ground textures.

Finally , was it hard to code ?

Maybe i'll try to update it if you haven't enough time for that.

Thank you.

[R-T-B]

1 hour ago, Artemis17 said:

Hello guy,

Is it compatible with KSP 1.10 ?

The bleeding edge branch linked above is currently in testing for 1.10.  It's working acceptably, but still may have an occasional bug or two.  There will be no stable release likely for 1.10, just betas.  We will make a stable release most likely for 1.10.1.

Quote

Finally , was it hard to code ?

We're just maintainers.  Kopernicus is the culmination of years of work by legandary coders, wrapped in more work by also legendary coders, and then put through the wringer of KSP updates and handed over to us mere normal coders.

So yeah, a little, but not my work really, many peoples. Teamwork makes the dream work, heh.  We're just largely rewriting the solar system prefab/builder from the very boot of the game, you know... 

Edited July 18, 2020 by R-T-B

[Poodmund]

16 hours ago, R-T-B said:

That said, I'm not as familiar with Kopernicus as I should be at times, so forgive me if I sound idiotic here:

There's a vanilla one?  If you mean the previous one for gas giants, that's the whole issue.  They (squad) are pulling the vanilla normal maps for gas giants out in 1.10 with the new shader, or at least the ways we used to reference them aren't working anymore.

I would suggest unpacking the 1.10 game assets, at least all the Texture2D assets, to see exactly what the game supplies with regards to the gas giants/Jool. There are a good handful of assets... off the top of my head, a tileable normal map that displays when close, Jool's scaled space texture, two band maps and a swirl map.

[kubi]

17 hours ago, R-T-B said:

It's fixed now.  Just redownload from same link.

@kubi, sorry for triggering a late spring-cleaning.

Thanks!

... but still not good

The System.cfg files are different now (-5.ori 8911 ->-5.new 8359 bytes).

However, in -4 there was an extra file, Kopernicus/Plugins/Kopernicus.pdb (2907648 bytes) that is missing from -5. Not sure if it is the issue though.

 

 

[SaturnTR]

When will version 1.10 be released

[James Kerman]

Welcome to the forum @SaturnTR, while asking for an update is not against the forum rules, so long as the request is polite and non repetitive, the great content creators and maintainers sometimes have real life pressures and responsibilities as well so it is usually best to wait patiently for an update, particularly with this mod as it is more complex than most.

[Thomas P.]

On 7/18/2020 at 4:51 PM, R-T-B said:

There's a vanilla one?  If you mean the previous one for gas giants, that's the whole issue.  They (squad) are pulling the vanilla normal maps for gas giants out in 1.10 with the new shader, or at least the ways we used to reference them aren't working anymore.  Jool templated bodies will no longer function in 1.10 using that normal map, and in 1.9/1.8, any non-jool templated gas giants are already broken.

Yes, there is a vanilla normal map. The reason why it is broken in 1.10 is because of the change you did to remove the new gas giant shader: You changed Kopernicus to not get the ScaledSpace object from the template body, but instead generate a barebones version yourself.

https://github.com/R-T-B/Kopernicus/blob/dev110/src/Kopernicus/Configuration/Body.cs#L321

Normally when you template a body, you inherit all of it's configuration, including the normal map. So no planet pack ever had to set a custom one, except if they wanted to change it. But now, you changed the ScaledVersion node to behave as if no template was used at all, so that the user would have to specify every value themselves. This includes the normal map. But the existing planet packs expect that the body will inherit the normal map from Jool.

I can't imagine any reason why it would break in 1.9 or even 1.8 too. Especially since 1.8 had a stable Kopernicus release for some time now and noone ever reported this issue. To me it sounds like you (accidentally) verified the issue with a Kopernicus build that had the scaled version change backported.

[R-T-B]

1 hour ago, Thomas P. said:

I can't imagine any reason why it would break in 1.9 or even 1.8 too. Especially since 1.8 had a stable Kopernicus release for some time now and noone ever reported this issue. To me it sounds like you (accidentally) verified the issue with a Kopernicus build that had the scaled version change backported.

No, user testing report, confirmed by myself as far back as 1.8 official from you with Kopernicus example config for untemplated gas giant.  It's all on my github issues page, actually.  In 1.8/1.9 it only occurs with non-joolian templated gas giants, which are used in some packs.  I stated this above.

Quote

Yes, there is a vanilla normal map. The reason why it is broken in 1.10 is because of the change you did to remove the new gas giant shader:

I'm aware, but I can't use the Joolian normal map anymore (and we only want to apply the Jool shader if we have options for it, coming later).  We tried and it looks weird, likely due to changes in 1.10.  We need a plain flat normal map.  Plus this would still be an issue for untemplated gas giants.

Anyways, I still feel this is the best futureproof way forward, respectfully.  The only thing I'd like to change is generating the flat texture internally rather than relying on an external file.  But everything I have stated is citably correct, see these issues:

https://github.com/R-T-B/Kopernicus/issues/13

https://github.com/prestja/Kopernicus/issues/16

  

1 hour ago, Thomas P. said:

To me it sounds like you (accidentally) verified the issue with a Kopernicus build that had the scaled version change backported.

Impossible, it was reported on 1.9 before I even backported any of my code.  We keep our branches separate for a reason.

You may note that I have implemented or personally done nearly all the bugfixes in Kopernicus as of late.  I know we had a dispute back when we started that early fork, but I think it's time to bury that hatchet (if there is one) and I have nothing but respect for you.  I would remind you I am getting more familiar with the code daily, and I did not ask for this, I was recruited by Prestja out of basically nowhere to help.  A little patience and understanding that I am here to help and not steal thunder would go a long way.

https://github.com/R-T-B/Kopernicus/issues?q=is%3Aissue+is%3Aclosed

https://github.com/prestja/Kopernicus/issues?q=is%3Aissue+is%3Aclosed

If I'm misinterpreting your feelings here (and I hope I am), my apologies in advance.  I just want to make my intentions clear.

Edited July 19, 2020 by R-T-B

[R-T-B]

1 hour ago, Thomas P. said:

Normally when you template a body, you inherit all of it's configuration, including the normal map. So no planet pack ever had to set a custom one, except if they wanted to change it. But now, you changed the ScaledVersion node to behave as if no template was used at all, so that the user would have to specify every value themselves. This includes the normal map. But the existing planet packs expect that the body will inherit the normal map from Jool.

Oh, and while I have you...

Do you have a better idea of how to do this?  I tried some code snippets from Sigma but they all failed in testing with the Jool shaders still appearing.  I really hate basically doing a non-template for Jool, but at the moment, I have no better ideas.

Edited July 19, 2020 by R-T-B

[R-T-B]

9 hours ago, kubi said:

Not sure if it is the issue though.

Nope, that's just an extra file the compiler spits out that does nothing.  The files being different is due to line endings changing, and is needed.  I had a bad version with different line endings in there causing the Kopernicus hash check to fail (we check that files hash to ensure users don't mess with it, this time I messed with it, oops).

[dzin]

 

Hi,

should I use Kopernicus 1.9.1-5  from prestja/Gihub or KopernicusBE_191_Release1 from R-T-B/github for KSP1.9.1?
What differences?


P.S. THANKS for both of You for maitining this

[Thomas P.]

53 minutes ago, R-T-B said:

No, user testing report, confirmed by myself as far back as 1.8 official from you with Kopernicus example config for untemplated gas giant.  It's all on my github issues page, actually.  In 1.8/1.9 it only occurs with non-joolian templated gas giants, which are used in some packs.  I stated this above.

[...]

Plus this would still be an issue for untemplated gas giants.

The example for a gas giant that doesn't use a template is old and outdated. It should include the normal map. I think noone except me ever touched it, and I probably just forgot it when I wrote the config back then. Or KSP didn't require it.

If a planet author decides to not use a template, they need to provide the missing data themselves, so also the normal map. Thats how it has always been. It is a feature, not a bug. By adding fallbacks to catch this you are making your life harder than it needs to be.

53 minutes ago, R-T-B said:

You may note that I have implemented or personally done nearly all the bugfixes in Kopernicus as of late.  I know we had a dispute back when we started that early fork, but I think it's time to bury that hatchet (if there is one) and I have nothing but respect for you.  I would remind you I am getting more familiar with the code daily, and I did not ask for this, I was recruited by Prestja out of basically nowhere to help.  A little patience and understanding that I am here to help and not steal thunder would go a long way.

I was just trying to give a more in-depth explanation to the issue. I didn't knew that you used my old example for a gas giant without a template, so I didn't know where the issue on 1.8 and 1.9 came from. So I just assumed it was because of your change, because on 1.10 it actually does have that effect (with every body). I wasn't trying to attack you or anything like that, sorry if it came over that way. I just want to try to help where I can.

40 minutes ago, R-T-B said:

Oh, and while I have you...

Do you have a better idea of how to do this?  I tried some code snippets from Sigma but they all failed in testing.  I really hate basically doing a non-template for Jool, but at the moment, I have no better ideas.

I looked into this a little bit before, but I don't want to well, actually... you, and let you find your own ways. But I have an idea:

The most important thing that I noticed in regards to the new shader is that Kopernicus doesn't fail. This is important, because Kopernicus will deliberately stop loading and report an error if it encounters a shader type that it can't parse. I added that to make it easier for me to detect if new shaders were used after KSP updates.

Earlier in this thread, and on github, people noted that the 1.9 Kopernicus loads on 1.10 without changes. This indicates that Kopernicus actually never sees the new shader, and that the Jool template still uses an old, known shader. Because ignoring Jools scaled space object removes the shader, it seems that it is applied by some script that is added to the scaled space object, and does it's work after Kopernicus finished loading.

Kopernicus puts a list of the scripts that are attached to the scaled space object into the logfile that it creates for the planet. So you can check this by looking at any random logfile from Jool on 1.10. What I found is a script called MaterialBasedOnGraphicsSetting. I guess that the new shader is only used if the shader quality is set to "Ultra", and that that script is responsibly for applying it. Maybe "High" too. But everything else will use to the old 1.9 shader, which is applied by default. This would explain a lot of things:

• Kopernicus doesnt fail, because the old shader is known, parsable and applied by default.
• Every gas giant that was created from Jool looked like Jool, because every body got a copy of that script, with a copy of Jools high-quality material.
• You were able to fix it by removing Jools scaled space object, including that script from the body.

Now you have two options:

1. Just remove the script during templating. This would remove the new shader from Jool, but also from all other bodies. They fall back to the default one.
2. Remove the script, but before that, force it to run already during templating, and not after Kopernicus is done. Kopernicus already forces the shader quality to "Ultra", because of how the terrain shaders are handled, so Jool, and every planet that templates off it get the new shader by default. This would also cause Kopernicus to refuse loading until support for the new shader was implemented.

Personally I would go with Option 2, but since that is quite a bit more annoying (because you need to add support for the new shader), Option 1 might be a good idea for bleeding edge builds until you have all the building blocks in place.

I would also warn you from trying to enable the new shader only for Jool. Don't try to be (overly) backwards compatible with stuff outside of your control (the stock bodies). It will only make your life harder in the long turn. It is way easier to adapt planet packs to the new default shader, than it is for Kopernicus to guess the wishes of the installed planet pack(s) and adapt itself to that.