Jump to content

[Early development, 0.24] Kopernicus Planetary System Modifier

BryceSchroeder

By BryceSchroeder
in KSP1 Mod Development

 Share

Recommended Posts

Borisbee

Borisbee

Posted
Posted

Hey Teknoman117, could you maybe explain how the lightColor field works for Atmosphere? I can't quite figure out what the 3 fields are for, they certainly don't seem to be RGB. Moving them around makes wird things happen. Changes the color, and even the gradient in which they appear. Here's a picture to show what I mean

JGreGRU.png

I got that color combination by pure luck moving around the sliders randomly. Is there a way to specify a gradient for the lightsource? Or do I just need to play around with the settings until I get something that is usable? I know you can make a gradient for scalespace, but I'm dealing with the atmosphere from ground.

Thanks

Edit: Oh and yea I know that slider isn't part of Kopernicus, but I was just using it to test colors.

Link to comment
Share on other sites
Teknoman117

Teknoman117

Posted
Posted (edited)

To tell you the truth I myself am still trying to figure out exactly how the atmosphere coloring works =P. I thought that the provided gradient changed things but it seems I am mistaken (does it only do scaled space?).

The provided controls for atmospheric color in kopernicus are as follows:


// Goes under body, remove the '@' if you're creating an atmosphere where there previously wasn't one (i.e. new planet)
@Atmosphere
{
    // effectively the ambient lighting color for all objects on the ground of this body (provides a slight tint)
    ambientColor = r,g,b,a     

    // sets the waveLength property in the AtmosphereFromGround component of the scaled version
    // From my picking around in the KSP assemblies, it seems this is fed to the shader in this way:
    //
    // shader.invWaveLength = Color( 1 / r^4, 1 / g^4, 1 / b^4, 0.5);
    //
    // Obviously the code for the shader is not available, and I don't feel like picking through ARB shader IL so we'll need
    // to figure this out experiementally.
    lightColor = r,g,b,a          
}

// Goes under body, remove the '@' if you're creating a scaled space where there previously wasn't one (i.e. new planet)
@ScaledVersion
{
    // Existing planets don't define a Material specialization, so use '@' when you're overriding your own or someone else's planet config
    Material
    {
        // Sets the atmosphere gradient, if one already exists, you need to put !Gradient on the line before Gradient because
        // gradient fields obviously don't support merging.
        //
        // Gradient is a list of points along a line where you define colors.  A Texture is then computed from the gradient and 
        // substituted for the rimColorRamp texture.
        Gradient
        {
            0.0 = r,g,b,a
            n.m = r,g,b,a
            1.0 = r,g,b,a
        }

        // If you have a texture for the gradient, you can specify to use the texture instead of a manual gradient
        rimColorRamp = path/to/texture (strip GameData/ prefix and file extension)

        // I think these have to do with how large the horizon appears
        rimPower = float  
        rimBlend  = float
    }
}

Edit: Actually typing this out game me sort of an epiphany ... as the shader is receiving the inverses of the color, technically, the lower each value the more of that color there is. But because its the inverse, and each channel is raised to the 4th power, numbers approaching zero cause r,g,b to approach infinity and cause the system to break down and strange graphical artifacts.

This generates an pinkish atmosphere: lightColor = 0.609,0.788,0.743,0

It also appears that the magnitude of the inverse color (square root of the sum of the squares of the elements) is inversely related to how quickly the atmosphere fades to dark. Smaller values for each channel of the lightColor property overall cause a brighter atmosphere.

Edited by Teknoman117
added how color is fed to shader
Link to comment
Share on other sites
Borisbee

Borisbee

Posted
Posted

Ok thanks that explains some things better. The way things work now is the gradient is what you see from scaledspace, so it's what applies the thin layer over the planet so it looks like there's atmosphere there, and it works rather well as far as I can tell. The lightColor is what you see from the ground, and determines the color of the sky and how fast it fades. I started getting curious because it seemed tough to get a very light color to have a slow fade high in the sky, but I guess you kind of explained why that would happen. It needs to be a brighter color in order to go higher. You're right in that tweaking the values too much can cause very wonky things to happen, like the cutoff being very abrupt instead of gradually fading.

In the end, it would be pretty awesome to be able to specify a gradient much like the scaledspace, where you can set exactly the color and how high/low you want it to fade but I think that can wait until way down the road. Other much more important things to be done first like the PQS system. Words can't describe how happy I'll be when we can start doing PQS editing without having to deal with kittopiatech, letting us use all the PQS mods and opening up much more creativity in planet creation.

At one point I was going to hardcode the planet I was toying around with, but I wasn't quite able to get my custom hardcoded planet and the config planets to both load. It was either one or the other.

Link to comment
Share on other sites
Yargnit

Yargnit

Posted
Posted

Hey Teknoman117, just noticed you were back again. So excited to see you back to finally see true new planets possible ala your original Kopernicus instead of the duplication thing everyone's been having to do. Even though Kopernicus based copies are much more stable than Planet Factory ones were, the true Kopernicus planet was just on a whole other level. And as much as I really want to dive into planets, I can't bring myself to do so until I can implement them 100% properly.

Let me know if you'd need some more testing/bug hunting done. :) Glad to have you around again & can't wait to see Kopernicus come to fruition. :D

Link to comment
Share on other sites
  • 2 weeks later...
Borisbee

Borisbee

Posted
Posted

That's awesome. I actually tried to do this myself but I struggled with the code and could never get both the config and the hard coded planet to load together. My goal was to actually just be able to hard code planets so that you could fine tune every detail. Do you have any interest in working more on this sort of thing? I have been struggling with trying to get oceans to work properly, but all my work has been done in a kittopia fork instead of Kopernicus as I found the Kopernicus code a bit above my level of understanding unfortunately.

Link to comment
Share on other sites
_Augustus_

_Augustus_

Posted
Posted
I'm going to look around see if I can learn this strange new enviroment.

I was stuck to Original PF for to long.

Look at some KopernicusTech packs, KopernicusTech is very similar to PF but minus the bugs and plus more customization.

Link to comment
Share on other sites
  • 2 weeks later...
Cdr_Zeta

Cdr_Zeta

Posted
Posted

Hello,

The above link is no worky...does this work in KSP v90? I see some using it but I am hesitant; looks like I may stay with PF till this gets sorted but I will check back as I want to try this and see memory savings...no 'starbox' or can that be added as a 'starbox' as some have done (without Kopernicus)?

I will look at Kopernicus Tech...

Cmdr Zeta

Link to comment
Share on other sites
Teknoman117

Teknoman117

Posted
Posted

I've tested and merged the fix from Thomas. I'll put together a new release in a bit.

It is interesting that the custom stars don't have celestial bodies, I was fairly certain that was a necessary component considering most of the ways of accessing the list of planets in the game (FlightBodyGlobals and such) return arrays of celestialbodies. Either way, I'll take a look at it when I have a chance.

Link to comment
Share on other sites
eddiew

eddiew

Posted
Posted

Hi there,

I've been having issues in a new career with Outer Planets Mod (uses Kopernicus) whereby all my craft that return home are listed as 942.5km from KSC and recovered at 59% value. OPM lists this as a known issue, and points the finger at Kopernicus, so I was wondering if there's been any update/fix/workaround for that?

I'd love to have some extra planets in the mix, but as a heavy SSTO user my game plan revolves heavily around high recovery values, so this issue is a bit of a breaker for me...

Cheers

Link to comment
Share on other sites
_Augustus_

_Augustus_

Posted
Posted (edited)
Indeed, I've already requested the merge into master, but only the star alternation fuction. (And the SolarPanelFixer, btw.) The reason is simple: All the StarSystems-operations (i.e. moving Kerbol) can be done with a MM.cfg, so there is no need for it. ;)

Could you make the config then? Make the config that makes a new Kerbol and moves stuffz, turns Kerbol into a black hole, and adds the two stars, in addition to making a compiled version of the KopernicusTech plugin, and I will be the happiest boy in the Blacky Karman system!

By that I mean I will go on a rampage of adding new stars and planets. I have some fun ideas already.

Edited by _Augustus_
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...