Jump to content

[Early development, 0.24] Kopernicus Planetary System Modifier


Recommended Posts

@Augustus: I'll see. If Tekno merges it, and all the Bugs are fixed, I will make a StarSystems config. Are there any ideas what I could do next, before I'm going to take a look into PQS? ^^

Idk. I just want to make some new stars.

But maybe rings in atmospheres? That's an issue I've found very annoying.

Link to comment
Share on other sites

Okay, so I reviewed all the code that Thomas P. put together. I've spent the last 6 hours converting the star customization to be part of the node based configuration loading system (versus an at runtime system modification). The results - pretty darn awesome. I think I can safely say Thomas and I have killed the star systems mod XD . The star light fixer (ported from KCreator and StarSystems) works as intended, although the power curve in the sample is slightly less than realistic. The ring loader didn't need any modification (thank you Thomas for taking the time to learn the configuration system). The beauty of how Kopernicus was designed to function and our embrace of Module Manger really shine through here. As I recently convinced the outer planets mod guys to move to a purely module manager based solution for OPM, the examples Thomas put together (custom star and rings on jool) work without modification in tandem with Outer Planets Mod. A star systems config is now trivial to implement, i just need to yank the settings out of Star Systems.

-- Relevant Screenshots --

https://drive.google.com/file/d/0B2-P21mrjglsWF9HNHp5YlNQNms/view?usp=sharing

https://drive.google.com/file/d/0B2-P21mrjglsRTRJbUF2OGdYQkE/view?usp=sharing

https://drive.google.com/file/d/0B2-P21mrjglsaXI4d2NiMl8wR1U/view?usp=sharing

-- Relevant Kopernicus Configs --

https://github.com/BryceSchroeder/Kopernicus/tree/development/Distribution/GameData/KopernicusExamples/Nemesis

https://github.com/BryceSchroeder/Kopernicus/tree/development/Distribution/GameData/KopernicusExamples/JoolRings

Edited by Teknoman117
Link to comment
Share on other sites

Okay, so I reviewed all the code that Thomas P. put together. I've spent the last 6 hours converting the star customization to be part of the node based configuration loading system (versus an at runtime system modification). The results - pretty darn awesome. I think I can safely say Thomas and I have killed the star systems mod XD . The star light fixer (ported from KCreator and StarSystems) works as intended, although the power curve in the sample is slightly less than realistic. The ring loader didn't need any modification (thank you Thomas for taking the time to learn the configuration system). The beauty of how Kopernicus was designed to function and our embrace of Module Manger really shine through here. As I recently convinced the outer planets mod guys to move to a purely module manager based solution for OPM, the examples Thomas put together (custom star and rings on jool) work without modification in tandem with Outer Planets Mod. A star systems config is now trivial to implement, i just need to yank the settings out of Star Systems.

-- Relevant Screenshots --

https://drive.google.com/file/d/0B2-P21mrjglsWF9HNHp5YlNQNms/view?usp=sharing

https://drive.google.com/file/d/0B2-P21mrjglsRTRJbUF2OGdYQkE/view?usp=sharing

https://drive.google.com/file/d/0B2-P21mrjglsaXI4d2NiMl8wR1U/view?usp=sharing

-- Relevant Kopernicus Configs --

https://github.com/BryceSchroeder/Kopernicus/tree/development/Distribution/GameData/KopernicusExamples/Nemesis

https://github.com/BryceSchroeder/Kopernicus/tree/development/Distribution/GameData/KopernicusExamples/JoolRings

This needs to be added to KopernicusTech. Right now when you use the normal Kopernicus with Kittopia all planets' scaledspace resets.

Link to comment
Share on other sites

Just got a lot of notification emails from GitHub about the progress... Nice job, guys! :) I really would like to help if I were having a lot of spare time (and of course, If I could understand the Kopernicus code better :D).

This needs to be added to KopernicusTech. Right now when you use the normal Kopernicus with Kittopia all planets' scaledspace resets.

Actually, once PQS loader on Kopernicus is up and running, there's no reason for me to continue the development of KopernicusTech, since Kopernicus will be already self-sustained. Besides, Kopernicus uses a less hacky way to load planets; which is better compared with the current solution.

Link to comment
Share on other sites

I've now fixed the problem with the maximum view distance in the tracking station. It is now dynamically computed from the system configuration - essentially, it finds the farthest away any body can be from the root body (center of the KSP universe, be it the sun, a black hole, etc.), multiplies that number by 3, and then divides it by the scaled space factor.

After Thomas P. puts together the Star Systems config, I'll put together another release of Kopernicus.

Link to comment
Share on other sites

Haha, great work thanks. :D I'll put together the cfg as soon as possible. :)Oh and PS. Please call me just Thomas. :)

Wonderful. I'm going to probably expand it.

So when will PQS be available? Also, I've noticed that in the new version the planet Kopernicus doesn't spawn.

Link to comment
Share on other sites

Wonderful. I'm going to probably expand it.

So when will PQS be available? Also, I've noticed that in the new version the planet Kopernicus doesn't spawn.

The Kopernicus planet hasn't been spawned in a long time by the mod. As far as an ETA on PQS goes, I really can't give you one. Except, unlike before, I'm actively working on it right now. So I can tell you it IS going to be released, but probably in various levels of capability over the next few weeks. Tonight I'm planning on getting the code that lets you customize the surface materials ready to go and potentially a skeleton of the PQS loader.

Link to comment
Share on other sites

Basically the idea is to use the Kopernicus planet to test out the systems available, and to serve as an example a 100% custom planet, without using the Template directive. That was just there for convenience sake, but there are a lot of things 100% customization can do for you. Since we are supporting modifying everything down to the material level - you can specify custom terrain detail textures. You can even increase the tiling ratio to increase detail for super-size planets.

For instance, here is the dump of Kerbin's surface material. I've also patched in support to look up built in textures. For instance, you can use "texture = BUILTIN/terrain_rock00" to get Kerbin's rock detail texture for whatever you're going to use it for.

EDIT: This is now complete at of 1:30 AM PDT 3/26/2015


[LOG 22:40:04]: --------- ---- Surface Material ---- ------------
[LOG 22:40:04]: saturation = 1
[LOG 22:40:04]: contrast = 4
[LOG 22:40:04]: tintColor = RGBA(0.173, 0.173, 0.173, 0.482)
[LOG 22:40:04]: powerNear = 0.75
[LOG 22:40:04]: powerFar = 0.75
[LOG 22:40:04]: groundTexStart = 0
[LOG 22:40:04]: groundTexEnd = 10000
[LOG 22:40:04]: steepPower = 4
[LOG 22:40:04]: steepTexStart = 10000
[LOG 22:40:04]: steepTexEnd = 100000
[LOG 22:40:04]: steepTex = terrain_rock00 (UnityEngine.Texture2D)
[LOG 22:40:04]: steepTexScale = (1.0, 1.0)
[LOG 22:40:04]: steepTexOffset = (0.0, 0.0)
[LOG 22:40:04]: steepBumpMap = Cliff (Layered Rock)_NRM (UnityEngine.Texture2D)
[LOG 22:40:04]: steepBumpMapScale = (1.0, 1.0)
[LOG 22:40:04]: steepBumpMapOffset = (0.0, 0.0)
[LOG 22:40:04]: steepNearTiling = 1000
[LOG 22:40:04]: steepTiling = 100
[LOG 22:40:04]: lowTex = terrain_sand00 (UnityEngine.Texture2D)
[LOG 22:40:04]: lowTexScale = (1.0, 1.0)
[LOG 22:40:04]: lowTexOffset = (0.0, 0.0)
[LOG 22:40:04]: lowBumpMap = Waterbump (UnityEngine.Texture2D)
[LOG 22:40:04]: lowBumpMapScale = (1.0, 1.0)
[LOG 22:40:04]: lowBumpMapOffset = (0.0, 0.0)
[LOG 22:40:04]: lowNearTiling = 4000
[LOG 22:40:04]: lowMultiFactor = 10
[LOG 22:40:04]: lowBumpNearTiling = 4000
[LOG 22:40:04]: lowBumpFarTiling = 10
[LOG 22:40:04]: midTex = terrain_grass00_new (UnityEngine.Texture2D)
[LOG 22:40:04]: midTexScale = (1.0, 1.0)
[LOG 22:40:04]: midTexOffset = (0.0, 0.0)
[LOG 22:40:04]: midBumpMap = cloud_normal (UnityEngine.Texture2D)
[LOG 22:40:04]: midBumpMapScale = (1.0, 1.0)
[LOG 22:40:04]: midBumpMapOffset = (0.0, 0.0)
[LOG 22:40:04]: midNearTiling = 4000
[LOG 22:40:04]: midMultiFactor = 100
[LOG 22:40:04]: midBumpNearTiling = 1000
[LOG 22:40:04]: midBumpFarTiling = 100
[LOG 22:40:04]: highTex = terrain_snow00 (UnityEngine.Texture2D)
[LOG 22:40:04]: highTexScale = (1.0, 1.0)
[LOG 22:40:04]: highTexOffset = (0.0, 0.0)
[LOG 22:40:04]: highBumpMap = 05_NORMAL (UnityEngine.Texture2D)
[LOG 22:40:04]: highBumpMapScale = (1.0, 1.0)
[LOG 22:40:04]: highBumpMapOffset = (0.0, 0.0)
[LOG 22:40:04]: highNearTiling = 4000
[LOG 22:40:04]: highMultiFactor = 4
[LOG 22:40:04]: highBumpNearTiling = 2000
[LOG 22:40:04]: highBumpFarTiling = 4
[LOG 22:40:04]: lowStart = 0.02
[LOG 22:40:04]: lowEnd = 0.1
[LOG 22:40:04]: highStart = 0.5
[LOG 22:40:04]: highEnd = 1
[LOG 22:40:04]: globalDensity = -8E-06
[LOG 22:40:04]: fogColorRamp = AerialRampKerbin (UnityEngine.Texture2D)
[LOG 22:40:04]: fogColorRampScale = (1.0, 1.0)
[LOG 22:40:04]: fogColorRampOffset = (0.0, 0.0)
[LOG 22:40:04]: planetOpacity = 0

Dear god we're going to need a GUI of some sort, there are just too many variables to play with ... I'm going to need to come up with something just like parser to generate GUIs...


PQS
{
materialType = AtmosphericOptimized
Material
{

}
FallbackMaterial
{

}
}

Edited by Teknoman117
Link to comment
Share on other sites

The Kopernicus planet hasn't been spawned in a long time by the mod. As far as an ETA on PQS goes, I really can't give you one. Except, unlike before, I'm actively working on it right now. So I can tell you it IS going to be released, but probably in various levels of capability over the next few weeks. Tonight I'm planning on getting the code that lets you customize the surface materials ready to go and potentially a skeleton of the PQS loader.

I just need enough to modify cloned planets in a similar fashion to PF for the time being so once Thomas releases the StarSystems config I can add some planets to the stars.

Link to comment
Share on other sites

This might be a really stupid question and the answer probably is just straight up "yes" or "no".

However, i'd still would like to ask it before i switch from my drawboard to actually implementing planets/stars (bc if the answer is no, i'll have to install Linux, which means i'll probably go nuts with mods for a few months before i'll start working on my own ;) ): Is it feasible to have around 42 bodies if i keep resolutions as low as possible (on heightmaps for instance) without running into major RAM-issues? And, related to that, if i don't use the stock planets except Kerbin, will the game still load them?

Link to comment
Share on other sites

I honestly wouldn't add GUI to your list of work right away Tek. Yeah, eventually it would be nice, but by now people have a lot of practice working via cfgs. A simple list of modifiers with useage examples should be plenty for the get go.

Link to comment
Share on other sites

This might be a really stupid question and the answer probably is just straight up "yes" or "no".

However, i'd still would like to ask it before i switch from my drawboard to actually implementing planets/stars (bc if the answer is no, i'll have to install Linux, which means i'll probably go nuts with mods for a few months before i'll start working on my own ;) ): Is it feasible to have around 42 bodies if i keep resolutions as low as possible (on heightmaps for instance) without running into major RAM-issues? And, related to that, if i don't use the stock planets except Kerbin, will the game still load them?

We're attempting to keep the memory overhead of Kopernicus as low as possible, but as Thomas said, the memory consumption is purely related to what you do with Kopernicus. However, let me detail some of the major consumers of memory one will bump into with Kopernicus. At the moment, even if you don't use the built in planets the resources for them still consume memory. This is because the assets for the stock planets and moons are actually in the autoloaded unity asset bundles. It might be possible to destroy these assets at load time, but the issue is that KSP doesn't intelligently load things. Kopernicus won't know what stock bodies could be deleted until after Kopernicus processes its config files, at which point the game has already crashed from breaking the memory barrier because we literally can't process configs until the asset loading is done. We are probably stuck with some of the memory overhead of the stock planets (dunno if the MapSO source textures are destroyed), I suppose someone can experiment and see.

However, for Kopernicus generated bodies, there are some notable sources of memory consumption

1) Heightmaps - The best possible storage on disk is of one channel, grayscale textures. KSP stores heightmaps internally as 8 bits per channel, one channel textures of the source resolution.

2) Colormaps - Surface color maps are stored internally as 8 bits per channel, 3 channel textures of the source resolution.

3) Biome Maps - stored internally as 8 bits per channel, 3 channel textures of the source resolution, which doesn't need to be that high. (Why squad didn't use a one channel <uncompressed> texture or a 4-5 bits/pixel packed binary format with the value corresponding to the biome ID escapes me, 32-256 biomes would still be ridiculous)

I should note however - since none of these textures end up on the GPU, as they are used as part of the PQS or other systems THEY CAN NOT BE COMPRESSED IN MEMORY (SO NO DDSLoader). Best practice also would have these textures places in the PluginData/ directory of your mod so that they aren't loaded into the texture database, as they aren't needed by the GPU. However, the two remaining uses CAN be compressed, so I highly recommend using DDSLoader or ActiveTextureManagement.

4) Scaled Space Colormap - The colormap used to texture the scaled space body of your planet

5) Scaled Space Normalmap - The normal map for the scaled space body

The recommended mod layout would be as follows


GameData/MyAwesomePlanet
|
---- MyAwesomePlanet.cfg
---- PluginData/
|
---- HeightMap.png
---- ColorMap.png
---- BiomeMap.png
---- Textures/
|
---- ScaledColorMap.dds
---- ScaledNormalMap.dds

For a thought experiment, lets say you are running seriously high quality textures (8k x 4k)

The height map and color map together represent 4x 8 bit channels (32 bits x 8k x 4k) = 128 MB

The biome map you can get away with like 1024x512, so 1.5 MB

The scaled space color map of 8kx4k is a DXT1 (rgb, 6:1) compressed texture for the color, so 16 MB

The scaled space normal map of 8k x 4k is a DXT5 (rgba, 4:1) compressed texture for the color, so 32 MB

Overall, for an 8k x 4k textured planet, you're looking at a 176 MB ram impact (ouch...)

For a 4kx2k textured planet, you're looking at 44 MB

For a 2kx1k textured planet, you're looking at 11 MB

For a 1024x512 textured planet, you're looking at 2.75 MB

... and so on ....

Now this is just the memory consumed by the resources themselves, there is potentially up to a 2x overhead because of how the PQS functions, but since those resources are freed when not needed, its not cumulative consumption. However, these are some alternatives for simplistic bodies.

The best memory efficiency is with planets/moons like Gilly. Gilly doesn't have a heightmap or colormap that is used in the PQS generation process. There is a low resolution color map and a normal map that is used to texture the scaled space (map view) version of the body. Other than that, Gilly is procedurally generated for the height and the colors, and has far lower memory impact.

So its up to the artist to strike a balance between raw quality and the performance considerations. I will disclose however, that I've exclusively run KSP on 64 bit Linux since the Linux version was available, mind you I've been a Linux user since 2004. KSP just runs so cleanly, as Linux handles high load tasks more efficiently that both Windows and OS X (you will still hit a performance barrier because KSP is still single threaded). If you have an ATI card, your results may vary, but if you have an Nvidia card, you'll have nothing but smooth sailing IF YOU INSTALL THE PROPRIETARY DRIVERS. You'll also want to make sure to install the ttf-msfonts for KSP uses the microsoft Arial fonts. After that, launch KSP with these options, as it will instruct the Nvidia driver to use its multithreaded workqueue system, and it ended up doubling my KSP performance.


# Launch KSP with some special sauce
LD_PRELOAD="libpthread.so.0 libGL.so.1" __GL_THREADED_OPTIMIZATIONS=1 ./KSP.x86_64

EDIT: You may ask why there is a separate scaled space texture and PQS color map texture, just use one and save memory right? Well, sadly it doesn't work that way. The texture is used as a source to generate an object called a MapSO, which feeds things like the PQS colormap, heightmap, and the body's biome map. It can't be fed from a compressed texture, but is stored raw internally. The source texture can then be deleted. Instead of having two copies of a large texture in existance (MapSO, scaled space), we just kill off the source texture of the MapSO and load a compressed texture for scaled space.

Edited by Teknoman117
Link to comment
Share on other sites

Okay, so I've got rudimentary support for PQS loading. The actual mod loaders aren't there, but the PQS Loader can generate a usable base PQS that shows up as a black sphere in space. At least its subdividing now, so it's just a question of integrating the PQSMod loaders.

Link to comment
Share on other sites

I have some ideas for the Corbo system to make once Kopernicus has fully-working PQS. Still need ideas for Dolas, though. Based off Nova's various ideas.

Xubol: Hot Moho-like planet. Orbits just outside Corbo's "Corona". Made primarily of sand and salt-like materials.

Rupa: Comet with a perihelion about 1 gm outside Xubol's orbit, so in-between Xubol and Meander. Apihelion about 200x Corbo-Xubol distance.

Meander: Second planet, Jool-sized green, turquoise, or light-blue gas giant. Similar proportional distance to Eve. Slightly warmer than possible habitability, but nowhere near as hot as Xubol. Has 3 large moons.

Sothebin: Third planet, has a Duna-like atmosphere with the same height as Kerbin's. 660 km radius. Thought to have been habitable to Kerbalkind in the past, large amounts of geological activity caused supervolcanoes to erupt and blacken out the sky with ash and kill most of the life on the surface, all that remains are primitive prokaryotes. Has two large moons.

Still working on ideas for the outer planets, though.

Edited by _Augustus_
Link to comment
Share on other sites

That is some quality information and wayyy more than expected, thank you very much!

EDIT: You may ask why there is a separate scaled space texture and PQS color map texture, just use one and save memory right? Well, sadly it doesn't work that way. The texture is used as a source to generate an object called a MapSO, which feeds things like the PQS colormap, heightmap, and the body's biome map. It can't be fed from a compressed texture, but is stored raw internally. The source texture can then be deleted. Instead of having two copies of a large texture in existance (MapSO, scaled space), we just kill off the source texture of the MapSO and load a compressed texture for scaled space.

I was about to ask, yes :blush:

As i have to wait until the PQS stuff is finished (no pressure at all, you guys do an awesome job) i'll just draw some maps for different sized planets/moons to find a good compromise for all the different shapes then. Actually i have the first system lined up with pink spheres already, time to fill them in :cool:

Link to comment
Share on other sites

Is it possible to modify the orbital velocity and period to be something other than what Kepler's laws say it is? Or to make a body's orbital speed zero so it's frozen in place?

Asking specifically for stars, since it would be cool to make a "constellation" that stays in place or at least rotates all at the same very low speed so it keeps its shape as if it were one rigid body. I would prefer this over a StarSystems style implementation since it is easier, more realistic, and doesn't move Kerbin or the Sun, so it introduces fewer bugs. The black hole at the center of the galaxy is cool and all, but it is too far away from the sun IRL to represent in KSP even at 1/10 scale, and it's not really a destination itself. Instead you would have each star at a specific point in the sky that changes seasonally like real constellations do.

Link to comment
Share on other sites

Is it possible to modify the orbital velocity and period to be something other than what Kepler's laws say it is? Or to make a body's orbital speed zero so it's frozen in place?

Asking specifically for stars, since it would be cool to make a "constellation" that stays in place or at least rotates all at the same very low speed so it keeps its shape as if it were one rigid body. I would prefer this over a StarSystems style implementation since it is easier, more realistic, and doesn't move Kerbin or the Sun, so it introduces fewer bugs. The black hole at the center of the galaxy is cool and all, but it is too far away from the sun IRL to represent in KSP even at 1/10 scale, and it's not really a destination itself. Instead you would have each star at a specific point in the sky that changes seasonally like real constellations do.

This isn't possible, though I did experiment with that once.

Unfortunately the black hole is the only option. I like it, as it's possible that Kerbol is inside of a quarternary star system with an intermediate-mass black hole and 2 other stars.

Also, Gargantua :P

Link to comment
Share on other sites

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

I'll certainly look into this.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...