R-T-B / Kopernicus

Kopernicus is a mod for Kerbal Space Program which allows users to replace the planetary system used by the game.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Shading Issues on Gas Giants (except Jool)

VabienArt opened this issue · comments

All gas giants, with the exception being Jool, now have their shadows rotated 90 degrees. Using 1.9 Kopernicus on 1.10 fixes that issue (but has a green tint cause of Jool's revamp). Visual mods have no effect, and in fact just put a second shadow on the body at 90 degrees the default one.

Mod Tested: OPM

1.10 with 1.9 Kopernicus
1.10 with 1.9 Kopernicus

1.10 with 1.10 Kopernicus
1.10 with 1.10 Kopernicus

I've been investigating this issue further. The bug is related to gas giants that don't use the Jool template.

The following screenshots are both in the same version on a clean install, using 1.9 Kopernicus, showing the issue.

OPM Sarnus, with correct Shadows
Kerbal Space Program 7_15_2020 7_49_46 PM

Template Kopernicus Gas Giant, with glitched shadows
Kerbal Space Program 7_15_2020 7_50_01 PM

Sorry for the late reply, I was wrangled by work to do many things the past few days.

The bug is related to gas giants that don't use the Jool template.

Yep, that's the case it appears. It's probably because my hacky work-around to detect gas-giants in 1.10 literally works like this:

Are you a Jool Template (y/n) ->

If yes -> Is your name Jool? ->

if No -> You are a gas giant that's not Jool, apply fixes.

Obviously, gas giants not using the Jool template fall outside those bounds. I'll look into fixing this soon, should see it in next release.

Looking into it, this is an issue that has persisted since 1.9 kopernicus

1.9 Kopernicus, 1.9 KSP

Kerbal Space Program 7_16_2020 9_50_34 PM

Also I'll note that your fix just makes the body a non-template using gas giant in effect, so this persists on all gas giants. Will look in to 1.8 out of curiosity.

For proper testing, can you identify the bodies that show an issue? I'm trying to playback the bug in realtime and have 1.10, my branch, and OPM mod loaded here. What body is bugged? All of them in 1.10 (except Jool) in 1.10, and in 1.9 it probably is on all non-jool-template gas giants? Am I understanding that right?

"Also I'll note that your fix just makes the body a non-template using gas giant in effect, so this persists on all gas giants. Will look in to 1.8 out of curiosity."

Yeah, it's the easiest way to remove the shader. It may actually help, if 1.10 catches all gas giants equally, I could just rotate the shadow map, theoretically, and fix all of them. I'll investigate.

Bodies that have an issue: OPM Gas Giants (Sarnus, Urlum, Neidon), Kopernicus template Gas Giant.

https://github.com/Kopernicus/KopernicusExamples/blob/master/KopernicusExamples/Creating%20New%20Bodies/GasGiant/GasPlanet.cfg

its an issue with the Scaled version of the planet. Unsure what exactly causes the issue but my best theory is that the mesh's normals are borked.

Testing 1.8 now. Yes you understood me correctly

Good, so we're on the same page.

There's a method Kopernicus fails to call on the celestialbody if it's a generic gas giant. That method is a simple void, celestialBody.SetupShadowCasting();

I wonder if this could help us?

Edit: not that simple, still investigating.

Issue confirmed on 1.8

Ok, I think I traced the issue and yes it will occur on 1.8 as well. The issue is with the stock Joolian "geosphere" variable. It's the base mesh for any untemplated planet and I can only assume it is messed up badly. It is apparently attempting to "borrow" the base jool mesh but I can only assume it is grabbing an outdated mesh or an incorrect one. I will see what can be done to replace that mesh.

See line 77-80 on Templates.cs

Actually, the geosphere mesh is fine, it's just that it wasn't being applied in all instances. I forced it with a kludge here in my gas giant check:

42f9334

Baking a new release now, if it works in 1.10 it should work in 1.9 and I will make an appropriate pull request pending testing.

It seems to work in my limited testing with GPP, please test here on 1.10:

https://github.com/R-T-B/Kopernicus/releases/tag/prerelease-1.10.0-3

Issue not fixed on OPM and Kopernicus Template, will continue helping testing tomorrow.

Hmm. That's odd. It worked in that other pack in 1.10...

I'll look at this again, but probably not tonight, 'tis late here. It's the planet shadow being cast at 90 degrees incorrectly to be clear, right? I may have to just download OPM for testing.

And yeah don't worry, late here too. We'll pick up tomorrow.

Correct on the shadow. Poles look a little off but that might just be me seeing things. Point is its the same as before.

darn. Maybe I just fixed Jool-templated bodies then? Not much help if so.

We'll work tomorrow on it some more, sleep well man.

Couldn't sleep and got bored lol. I can confirm Jool's scaled mesh is perfectly fine. Could non-template Gas bodies use a different system? Also I looked at the KSP Code, and in 1.10 they added 'GasGiantMaterialsControls.cs' to the code. Might be useful to implement the new shaders on new bodies. You'll have to access it yourself cause sharing it is legally...not great, but it's pretty easy to find with dotPeek.

I'm aware of it (GasGiantMaterialsControls), right now I'm just working around it mostly. We have a separate issue to add support for it, which we'll probably work on once we tackle this.

There was a release last night, did you test by chance? 1.10 prerelease 4. It may force the proper template on non-joolian templated bodies, may not too... give it a go?

Could non-template Gas bodies use a different system?

That appears to be the case, and is what the prerelease 4 update attempted to address.

God damn she's holding on hard.

Issue persists. I'm out of ideas lol.

Kerbal Space Program 7_17_2020 12_25_19 PM

AHA, THE 3D MODELLER STRIKES AGAIN!

Ahem. The body needs a normal map. I gave Sarnus a normal map (I didn't have a blank one so I used plock's) and....

Kerbal Space Program 7_17_2020 12_50_26 PM

It's a bit bumpy, cause plock is bumpy, but it fixes the shadow orientation.
Gonna go find a blank normal map now.

Kerbal Space Program 7_17_2020 1_46_26 PM

Aaaaand, I fixed it.
Unfortunately I'm not too familiar with the code, but I believe if you do something like
if(!normals){
normals = gasgiant.dds
}
in scaledversionloader it should fix it.
I need to learn c# lmao.

Anyway heres an obligatory beauty shot, and the normal map I used:

gasgiant.zip

Kerbal Space Program 7_17_2020 1_59_46 PM

Meanwhile, I discovered why I could not replicate your issue:

Scatterer. It does it's own shadows. Remove it and now I can replicate your issue 100%. oops.

Anyhow, good work figuring out the normals map needs to be set, it does look like they are indeed being left unset in the code! Serious gold star work there. I'll mention you in the patch for this. I don't know if I need to use your normals map, there should be a builtin one that would be more appropriate rights-wise, but I'll be in touch if you want to donate it / there isn't an ingame substitute.

The map is free to use if you like. It's just a plain flat map so not really special. You could use a slightly bumpy map to give it some cloud depth, but IMO thats not kopernicus's job, and you should just use a placeholder.

Yeah, if that's all it is there are probably no usage rights issues. Still, to keep the bundle from needing extra external files, I'll try to pull one from in game if at all possible. Working on it now.

This actually has exposed a pretty deep rooted issue in Kopernicus. It appears all shadows are at present, on non-templated celestial bodies with gaseous atmopsheres, parsing an incorrect shadow map by default (yep, just as you claimed). It goes all the way back to the part that reads the game files, I can only guess the game at some point rotated gas giant shadow maps 90 degrees or something in the stock game?

I don't really know/understand as modeling is not my thing. I'm tempted to just try telling it to rotate the stock game "lightdirection" variable vector4 map by 90 degrees at load and see what happens. In theory, it should only change the bugged bodies, and applying a new normal map should still work as it'll recalculate.

Here's hoping. I'm working on it.

Definitely an old issue. Whatever the base game defaults to using as a normal map is broken likely, but I'm the exact opposite as you, great with 3d models, not game development. Seems this is an issue going back as far as 2017 as seen
Here
and here

yep, I've been beating my head against this all day. Squad in their infinite wisdom don't let you grab the default bump map of Jool, so I'm just going to include your glorious artwork in our package for now (heh, I'm aware it's just a flat texture map).

At least it'll fix the issue. Tired of fighting methods that don't want to release their textures, and I'm thinking squad would probably appreciate me not trying to work around them if I don't need to do so.

Well, I'm going to have to have this fix wait a day. My brain is just mush from all that earlier fighting with the code trying to figure out WTF was happening, heh.

It should be fixed tomorrow though, the problem is pretty basic and down to a defective normal map reference. Thanks for your help with this.

IIRC, shadows being rotated 90 degrees happens with png normal maps on any planet, given that the normal maps are at full opacity. Changing to opacity to half fixes it.

I'll check if it could be that easy a fix, thanks for the tip democat3457!

Oh, yeah strangely the normal maps for ksp use the Alpha (opacity) channel. Hence why I had to make my own map. Happy to help with my favorite mod, hopefully I can help more in the future. Thanks for doing this for the community. Fly safe!

I just loaded up an external normal map for now (Thanks VabienArt!) rather than horsing with opacity. It seems on some bodies they did not possess a normal map at all, leading to the odd behavior. The easiest work around is to load a static one externally, though I'm sure I could make it cleaner by generating the normal map with a Texture2D line. but for now, this will do. Issue should be fixed in next release in a few minutes. :)

Should be fixed in prerelease 6, do advise when able.

And thank you, not being much of an artist, this one was a doozy for me, lol.

It's fixed! Glad to have helped. I'll be sure to assist in the future once I learn the ways of the almighty Kraken, and C#