[INDEV] [1.9] To Boldly Go (0.4.1) | An external application designed to procedurally generate an entire galaxy for KSP.

[MajikalExplosions]

I suddenly realized that I feel like it would be interesting if we added random color generation(realistic, of course) and/or heightmaps.

Maybe?

[seanth]

15 hours ago, MajikalExplosions said:

Looks like I have some catching up to do

Also - GalaxyGen.bas line 2356 is wrong(the comment says mass but it should be radius)

Good catch. Not sure how that error crept in.

As a side note, you could report code bugs right on github. Issues tab-->New issue

Last night I just started getting brightnessCurves working in a way that I think I can use in a procedural way. Thx to the people on the Kopernicus discord server for weighing in on the mystery of brightnessCurves.

6 hours ago, MajikalExplosions said:

I suddenly realized that I feel like it would be interesting if we added random color generation(realistic, of course) and/or heightmaps.

Maybe?

Once the code base is not in qb64 it will be much easier to generate de novo heightmaps. In python I could do it using PIL or any number of pre-existing tools. But in QB64 I have not even considered it. I'm sure there are similar tools for Java

[Alphard]

How do you use the exe? All I could found was some wildly different version on youtube. What do that custom/auto and input seed mean?

[seanth]

On 7/13/2018 at 11:12 AM, Alphard said:

How do you use the exe? All I could found was some wildly different version on youtube. What do that custom/auto and input seed mean?

The exe should be fairly straight forward to use:

1. It first asks you to name your galaxy. This has no impact of the generation of the galaxy, but will result in a meaningful file that will be generated at the end.
2. Next it will ask whether you want a automatic or custom galaxy. A automatic galaxy will choose the settings without your input. A custom galaxy will generate a galaxy using your input as guidance. More on custom galaxies below.
3. The seed is any series of numbers you want. This exists so it will be possible for other people to generate exactly the same galaxy as you if they use the same seed.

AUTOMATIC:

• If you chose "automatic" the application will display the numbers of stars, planets, moons, and astroids generated
• If you are happy with the results, type "y" and the galaxy.cfg, "Galaxy Gen" txt file, and "wikiEntry.html" files are generated. More on these at the end.

 

CUSTOM:

• There are additional options if you chose "Custom"

1. You can choose the galaxy age, 0 to 5. 0 is very young and 5 is very old. The age of the galaxy determines the numbers of the different star types: Blue Giants (O), Blue-while Giants (B), White (A), Yellow-white (F), Yellow (G), Orange (K), Red dwarfs (M), and Brown dwarfs (L-Y)
2. You can choose whether you want planets generated or not. This is useful if you are just testing what sort of star types you want. If planets are generated, moons will also be generated.
3. You can choose whether you want astroids generated of not. Astroids, in this case, are not the astroids that appear in the normal KSP game. These are just chunks of rock that orbit stars like planets.
4. Next you can choose what sort of galaxy type you want to have: An ellipse, a disk, or clusters
   • An elliptical galaxy is more spherical in the distribution of stars
   • A disk galaxy has the stars distributed in more of a flattened disc
   • The cluster option creates groups of stars that clump together to sort of make mini galaxies.
   • I admit I always make disk galaxies, so there may be bugs in making the other types. If you find one, be a hero and report it on github.
5. "Advanced settings" will essentially override the "galaxy age" setting. You get to explicitly define how many of each star type you want.
6. If you are happy with the results, type "y" and the galaxy.cfg, "Galaxy Gen" txt file, and "wikiEntry.html" files are generated.

OUTPUT FILES:

• "galaxy.cfg" -- This is the actual galaxy file that the Kopernicus mod will use to place the stars, planets, etc.
• "Galaxygen_Info-<your galaxy name>.txt" -- This file will record the generation options you used when making the galaxy, including your seed. This file is very useful to help me recreate problems people might encounter.
• "wikiEntry.html" -- This is a wiki file that lists the star characteristics of all the stars generated. It's modeled after the wiki entry for Kerbol, but upcoming releases will include additional information such as the star's absolute magnitude, apparent magnitude from Kerbol, location of teh frost line, and where the habitable zone is (min/max).
• "TBG-ResearchBodies.cfg" -- A file that will be generated that will allow players to use the ResearchBodies mod to discover and research distant stars, planets, and moons. This will appear in the next release (which is currently being tested)

[Alphard]

The problem with the exe is that it never shows anything else than seed after custom/automatic and this always repeats.

[seanth]

11 hours ago, Alphard said:

The problem with the exe is that it never shows anything else than seed after custom/automatic and this always repeats.

That is super strange. I've never encountered that bug before. Could you DM me any details you think might be important to help me figure out what is going on so I can try and help you out?

[Alphard]

6 hours ago, seanth said:

That is super strange. I've never encountered that bug before. Could you DM me any details you think might be important to help me figure out what is going on so I can try and help you out?

After many launches, it suddenly works. But thanks, hope it doesn't occur again.

[seanth]

Dearest Cugi,

Oooooh, this is going to be a long one. tl;dr:

Spoiler

 

A good approach to generating good brightness curve is:

    sunAU = (radius of your star in meters/‎261600000)*13599840256

brightnessCurve values:
   

key value 2 = 0.74*(key value one)^1.01

    or just use

            key = 0 <some small value like 0.01. More on this in a later post>
            key = 1 0.74
            key = 5 3.76003099
            key = 10 7.57236814
            key = 15 11.4047007
            key = 20 15.2500763
            key = 26 19.8771814

 

 

——————————————————

For some time I have been struggling with star brightness. After some updates to Kopernicus star brightness was so overwhelming that the view from KSP or in he map view was just white with glare. I've desperately wanted to focus on planet generation, but the issue of star brightness has been a ongoing problem.

Sooooo, I recently decided to lean into it. I realized that several design goals I had could be wrapped into one if I really looked closer at how bright stars appear in KSP:

• Have only stars with a certain apparent magnitude be visible in Kerbin's night sky.
• Integrate the ResearchBodies mod with TBG so stars that are too dim need to be discovered.
• Have star flares scale correctly as you zoom into them in map view.

The problem is that, as far as I know, no one knows _exactly_ how the brightnessCurve works. The Kopernicus mod ties into how KSP is written, and KSP uses the Unity game engine and relies on the C# language. The brightnessCurves look like this:

                brightnessCurve
                {
                    key = -0.01573471 0.217353 1.706627 1.706627
                    key = 5.084181 3.997075 -0.001802375 -0.001802375
                    key = 38.56295 1.82142 0.0001713 0.0001713
                }

and are technically animation curves used by Unity (https://kerbalspaceprogram.com/api/class_sun_flare.html).

I don't use Unity, but if I understand correctly the first value in each key is a time index, the second is a magnitude, and the last two values are tanget values describing the curve. Values three and four appear to be optional as a backward-compatible feature of Unity. But how does this apply to brightnessCurves for stars? This is the mystery of our faith.

There are old IRC transcripts where people that have worked on Kopernicus have tried to puzzle things out, and the concensus is:

• The first value is "distance" but 0 means far away
• The second value is "brightness"
• The brightness is partly modulated by another value for a star: "sunAU"

Now "sunAU" is a weird parameter. Reading it, I assumed it stood for "Sun-Astronomical Unit". An astronomical unit(AU) is defined as the distance between Earth and the Sun. In KSP, I assumed it would be the distance between Kerbol and Kerbin (13,599,840,256 m). This was confirmed by seeing that KSP's stock sun had a sunAU set to 13599840256. But how to adjust this for other stars? Technically an AU shouldn't change, but the KSP API documentation implied that the sunAU was related to the brightnessCurve, so it probably should change from star to star.

One of the developers that has looked into brightnessCurves the most is @Sigma88. At one point he shared the following:

• Quote

   

  • 15:42 <Sigma88> my suggestion is to multiply the sunAU by this number: 
  • 15:42 <Sigma88> (radius of your star) / (radius of stock sun) 

   

   

Which seems reasonable to me. If you had a new star 2x the radius of Kerbol, your multipler would be 2.0, so your new star sunAU value would be

    13599840256m*2 = 271996805124 m

That's the easy part: simple to code into TBG. Next came the tedious bit.

In my day job, I do a lot of analysis of data looking for ways to model it. There aren't a lot of brightnessCurves out there that just work for stars that range from tiny red dwarfs to giant blue giants. I needed some way to generate things that would apply for all the stars in the main sequence. To get there, I started hand crafting a brightness curve for a blue giant. I would alternate actual values with zero "brightness values" so I would have visual cues in KSP's map view to tell me when I would transition from one key to another.

                    key = 1 100
                    key = 2 0
                    key = 5 100
                    key = 6 0
                    key = 10 100
                    key = 11 0
                    key = 15 100
                    key = 16 0
                    key = 20 100
                    key = 21 0
                    key = 26 100

Using a piece of paper for scale on the screen, I adjusted the values so the flare around the stars would be consistent in size at each key, and arrived at a curve like:

                    key = 1 0.8
                    key = 5 3.5
                    key = 10 7
                    key = 15 11
                    key = 20 15
                    key = 26 22

The initial plan was to do this for each of the OBAFGKM star types and use each curve type as needed, but as a test I tried the curve I had made with a red dwarf and it Just Worked™. This was great news, but I wanted an equation that would give me the "brightness" part of the key using that first initial "distance" value. Some simple analysis later and I had:

    "brightness" = 0.74*"distance"^1.01

The values derived from the equation were not exactly the same as what I had manually gotten, but are close enough that I'm happy to use them.

                    key = 1 0.74
                    key = 5 3.76003099
                    key = 10 7.57236814
                    key = 15 11.4047007
                    key = 20 15.2500763
                    key = 26 19.8771814

This has worked beautifully in terms of how star flares look as you zoom in and out of them in map view. They scale smoothly and logically in relation to the star body. It doesn't address overall star brightness as seen from Kerbin though. For that, I need a key with a distance of 0, and the brightness would have to be related to the apparent magnitude of the star as seen from Kerbin.

That is a whole other in-depth discussion though. Next time I'll talk about the Law of Cosines, star luminosity, apparent magnitude, and seeing stars in Kerbin's night sky.

Yours,

-me

[seanth]

15 hours ago, Alphard said:

After many launches, it suddenly works. But thanks, hope it doesn't occur again.

AH! I figured it out after looking closely at your screenshot. You were capitalizing the "A" or "C" at the "(CUSTOM/AUTO)(c/a)" stage

What a weird bug, but as the original designer said "please do not use capitalization for anything other than the Galaxy name."

[seanth]

Updated release.

0.3.1 changes:

• better coronae scaling as you zoom in on them
• whether you see a star from Kerbin depends on the star's luminosity and distance from Kerbin
• optional integration with ResearchBodies

 

Another letter to Cugi and a video showing stars in Kerbin's night sky soon.

 

Edited September 5, 2018 by seanth

[seanth]

Dearest Cugi,

In my last missive, I talked about generating brightness curves for stars in TBG, but I left out a critical component. Mainly, what value to use when the first key value is 0 (i.e. very far away from the star). I thought I would very briefly talk about how I dealt with that, and what it means in terms what stars can be seen from Kerbin.

KSP defines the locations of objects (stars, planets, moons, ships, etc.) using polar coordinates. This means that an object's location relative to the body it orbits is described by an angle(argumentOfPeriapsis) and the distance from the body (semiMajorAxis).

As an example, when you being a new game in KSP, Kerbin's location is defined as:

Quote

semiMajorAxis = 13599840256 // The altitude of the highest point in the orbit
argumentOfPeriapsis = 0

When generating stars in TBG, each star, including Kerbol, has a location relative to a galactic core object ("Core"). We have the distance of each star (semiMajorAxis) to the Core, and their angle. What we lack is the distance from Kerbol to each star.

We can solve this relatively easily if we convert the star's polar coordinates into cartesian coordinates that will give us X and Y values. Once we have cartesian coordinates for all the stars, it is simply a matter of using the distance formula to solve for the distance between Kerbol and the other stars.

What, you ask, does this have to do with what stars can be seen from Kerbin? 

The human--and presumably the Kerbal--eye has a minimum brightness level it is able to detect without the aid of telescopes. Dating all the way back to at least Ptolemy astronomers have grouped stars by their apparent magnitude as seen from Earth. You can figure out the apparent magnitude of any star if you have its distance from the observer and the star's luminosity.

There is a pretty good relationship between star mass, temperature, and luminosity, so TBG already calculates the luminosity of each star starting from mass. As explained above we now have the distances between other stars and Kerbol, so we can solve for the apparent magnitude. This matters because, the best human eyes can't see objects with an apparent magnitude greater than around 6.5. I decided to give the Kerbals better eyesight, so their cutoff is 7.0. I may make this a user editable value in case people want to have more stars appear in the night sky.

Boring so far, right? Here's where it gets sort of cool.

In the apparent magnitude scale, the lower the value is, the brighter it appears. Kerbol, as seen from Kerbin, has an apparent magnitude of -26.83. For those interested in playing around with some values, or seeing how things are calculated, I put together a spreadsheet that does many of the calculations that TBG does.

Through trial and error, I found that the smallest setting that the lowest value in the brightnessCurve that can be seen from the surface of Kerbin is 0.005. Note that this is not the apparent magnitude of the star. How to correlate apparent magnitude to a value that can be used with with the brightnessCurve?

Long story short I settled on the equation 

Quote

skyBrightness = e^(-3.897121 - 0.1868262*apparentMagnitude) 

where e is 2.718282.

As a test, if you set the first key set of the brightnessCurve for all stars to:

Quote

key = 0 3.0

All the stars will appear to be the same size as Kerbol when seen from Kerbin.

So now I had a way to link apparent magnitidue to apparent size of a star in the sky. Any star with an apparent magnitude of greater than 7.0 gets a value less than 0.005, making it unseen. 

The end result of this is that unless small stars--like red dwarfs--are very close to Kerbin, they won't be seen in the night sky. This also allows TBG to automatically generate files that work with ResearchBodies, allowing players to discover distant and/or dim stars.

 

[killbotvii]

Sorry to bug you, but I feel as though I''m not understanding this. I followed the instructions in the OP, but no gamedata folder is generated at the end. What's further confusing is that in your July 14th post, you don't mention the gamedata folder either. I guess my question is, what am I supposed to do after I generate a galaxy? Look at a pretty text file and html file?

[The_Right_Arm]

The gamedata folder is an automatic thing created by the game itself.  The purpose of that folder is adding mods to the game.  To add a mod, simply paste the folder for said mod in the Gamedata folder of your KSP build.  The html and txt files go in the main To Boldly Go folder, which contains the mod and everything needed to run it, and the To Boldly Go folder goes in the Gamedata folder.  Hope that isn't too confusing, it is a bit of a mess of folders.  Let me know if you need more help and I can get you some pictures and show you how to set it up step by step.

[seanth]

I might have some time tomorrow to make a video showing step-by-step how to install and use To Boldly Go, but what @The_Right_Armsaid is correct.

Now, this image might be slightly different than what you find when you download the most recent release from github, but that's because there are some minor changes that will be appearing in the next release (will be uploaded tomorrow or Friday):

The exe makes the galaxy.cfg file, which is the important bit. That's the file that the Kopernicus mod uses to know how and where to place all the stars, planets, and moons.

[MajikalExplosions]

It's been a while, but I spent the latter 1/3 of summer learning Python, so I might be able to finally get a Python port started.  I don't quite understand the actual calculation part, but I think I can help with the more basic parts.

[seanth]

1 hour ago, MajikalExplosions said:

It's been a while, but I spent the latter 1/3 of summer learning Python, so I might be able to finally get a Python port started.  I don't quite understand the actual calculation part, but I think I can help with the more basic parts.

Cool. What's your thought on what a python UI might be like? I keep thinking about using something like cherryPy so a python version of TBG would use a web browser as the UI 

 

[killbotvii]

@seanth @The_Right_Arm Thank you guys very much! I apologize for my snippy attitude in my original post.

[seanth]

Minor update that hopefully improves star colour, and maybe gas giant textures.

If anyone is running TBG with ResearchBodies, I'd love to hear about how they integrate with the new patch.

[Dryo]

There are major bugs in this version like the dark side of Kerbin and Mun being lighted by the stars / star clusters and etc...

The black holes gravity might have to be adjusted, it is shooting spaceships out of the game map.

[seanth]

2 hours ago, Dryo said:

There are major bugs in this version like the dark side of Kerbin and Mun being lighted by the stars / star clusters and etc...

The black holes gravity might have to be adjusted, it is shooting spaceships out of the game map.

Can you post what version of Kopernicus and TBG you are using? And can you elaborate on where you experience weird gravitational things happening?

 

[Lisias]

On 6/13/2018 at 12:29 PM, seanth said:

I'm currently working on the "Janet" branch and am focusing on planet-related stuff (like tidal locking, planets in habitable zones getting atmosphere's with oxygen, etc). The current code is in QBasic, but I have dreams of moving things to python.

I may be able to help on this. I'm a experienced Python developer and a KSP enthusiast, and was wondering exactly about this when I read your post.

Learning Python is not that bad, learning to program in a "pythonic" way can be - but who cares?  A GUI can be a challenge, I usually prefer to use the embedded TK toolkit, besides being a bit ugly - every Python runtime already had it, make things simpler.

Let me know if you are still interested.

Edited September 29, 2018 by Lisias
hey! that was fast! the guy quoted me before I fix my grammar! =D

[seanth]

1 minute ago, Lisias said:

I may be able to help on this. I'm a experienced Python developer and a KSP enthusiast, and was wondering exactly this when I read this post.

Learning Python is not that bad, learning to program in a "pythonic" way can be - but who cares?  A GIU can be a challenge, I usually prefer to use the embedded TK toolkit, besides being a bit ugly - every Python runtime already had it, make things simpler.

Let me know if you are still interested.

I am. In fact, I started doing some very basic porting of things to python. I can make a branch of Janet if people are interested in helping with a python version.

[Lisias]

15 minutes ago, seanth said:

I am. In fact, I started doing some very basic porting of things to python. I can make a branch of Janet if people are interested in helping with a python version.

"Janet"?

Either way, yeah. A branch would be the first step.

[Dryo]

22 hours ago, seanth said:

Can you post what version of Kopernicus and TBG you are using? And can you elaborate on where you experience weird gravitational things happening?

 

Kopernicus version: March version

TBG version: 1.4.3 KSP version

Maybe? It happens in stars around the black holes, there are a few stars far from the black holes which aren't affected by the bug.

[seanth]

48 minutes ago, Dryo said:

Kopernicus version: March version

TBG version: 1.4.3 KSP version

Maybe? It happens in stars around the black holes, there are a few stars far from the black holes which aren't affected by the bug.

Could you post some images of the lighting problem and the seed for your universe? I tested lighting on the dark sides of Kerbin and the Mun and didn't see any problems. I want to make sure I can replicate the errors you are experiencing