[1.2] Real Solar System v12.0 Dec 8

[NathanKell]

Not sure about the jitter....

Re: maps. First of all, the normal maps are for the scaled-space planets; PQS terrain appears to have a normal map applied in the shader that's not exposed to the PQS itself (?)--just the vertex colors are. Most planets do have a heightmap for when in PQS mode; for Earth it's already at the maximum KSP allows (8192x4196) but I haven't redone Mun into the Moon's real terrain yet so that's still using the stock, lower-res heightmap (and lower-res diffuse and normal maps for scaled space).

[SpacedInvader]

Not sure about the jitter....

Re: maps. First of all, the normal maps are for the scaled-space planets; PQS terrain appears to have a normal map applied in the shader that's not exposed to the PQS itself (?)--just the vertex colors are. Most planets do have a heightmap for when in PQS mode; for Earth it's already at the maximum KSP allows (8192x4196) but I haven't redone Mun into the Moon's real terrain yet so that's still using the stock, lower-res heightmap (and lower-res diffuse and normal maps for scaled space).

I think in our specific instance, we're hoping to create a better height map for the scaled space Kerbol system so that the stock (albeit larger) planets will look better in scaled space without having to go to vertical extremes like I did in my earlier testing.

[WindShieIds]

I can't give you credit for mixing up the analogue's with Pluto and Europa, but it still seems like a good mod

[NathanKell]

SpacedInvader: You seem to be mixing terms here. Heightmaps are used by PQS, and all the changes you did are to PQS. The scaled-space models don't have a heightmap; they get their vertex displacements from the PQS at game launch (although obviously they have a *lot* fewer vertices), and on that is placed a color (diffuse) map and a normal map.

Let me ask a question: regardless of terms, which terrain are you trying to make look better: the terrain you get when you're close, or the terrain you get in (medium-high) orbit?

On enlarging heightmaps: that's *already true* for Earth in v6 (it has the largest heightmap possible). And it's still a resolution of almost 5km per pixel. For the Moon, with another 8192 map (that's another 32megs at 8bits/pixel) it'll be 1.33km / pixel (which is *roughly* what Kerbin was in stock KSP, IIRC; I think they used a 2048x1024 heightmap?) As you can see, the various noise-based PQSMods are *very* necessary to make for good terrain in practice; heightmaps alone are far insufficient.

WindShields: uh...? Have you *seen* how close Europa and Eeloo look?

[Starwaster]

SpacedInvader: You seem to be mixing terms here. Heightmaps are used by PQS, and all the changes you did are to PQS. The scaled-space models don't have a heightmap; they get their vertex displacements from the PQS at game launch (although obviously they have a *lot* fewer vertices), and on that is placed a color (diffuse) map and a normal map.

Let me ask a question: regardless of terms, which terrain are you trying to make look better: the terrain you get when you're close, or the terrain you get in (medium-high) orbit?

Duna... say Duna.... say Duna....

(so I don't have to....)

[Oksbad]

So by what ratio (roughly) are RSS distances scaled compared to vanilla KSP? I'm playing with Remote Tech 2 and have to adjust ranges on the antennas accordingly.

[ANWRocketMan]

About x10.5 more or less I think?

[AndreyATGB]

Eeloo's apoapsis is about 1.1E8km while Pluto's is 7.1E9km. I'd give the largest dish at least 8E9km range.

[darkside]

I'm also curious right now about RSS / RO / everything else that goes with these compatibility with .23.5. The whole asteroid thing really seems interesting, but I want all my realism to stay unbroken while trying to use it...

This is what happens. I am guessing that some (many) asteroids spawn too close to Kerbin, within it's enlarged SOI and moving a bit too slow to escape it so they end up in Kerbin orbit from the beginning. Those spawning farther away seem to be ok, so simple fix should be just making them spawn outside of Kerbin SOI.

[Starwaster]

This is what happens. I am guessing that some (many) asteroids spawn too close to Kerbin, within it's enlarged SOI and moving a bit too slow to escape it so they end up in Kerbin orbit from the beginning. Those spawning farther away seem to be ok, so simple fix should be just making them spawn outside of Kerbin SOI.

WOAH. I haven't seen anything like that.... I need to pay closer attention to what's happening at home!!!!!!!

We need Impact Events!!!! Like the one that took out the kerbosaurs many millions of years ago during the Kerbaceous period. Or was it the Kerbisticene?

[SpacedInvader]

SpacedInvader: You seem to be mixing terms here. Heightmaps are used by PQS, and all the changes you did are to PQS. The scaled-space models don't have a heightmap; they get their vertex displacements from the PQS at game launch (although obviously they have a *lot* fewer vertices), and on that is placed a color (diffuse) map and a normal map.

Let me ask a question: regardless of terms, which terrain are you trying to make look better: the terrain you get when you're close, or the terrain you get in (medium-high) orbit?

On enlarging heightmaps: that's *already true* for Earth in v6 (it has the largest heightmap possible). And it's still a resolution of almost 5km per pixel. For the Moon, with another 8192 map (that's another 32megs at 8bits/pixel) it'll be 1.33km / pixel (which is *roughly* what Kerbin was in stock KSP, IIRC; I think they used a 2048x1024 heightmap?) As you can see, the various noise-based PQSMods are *very* necessary to make for good terrain in practice; heightmaps alone are far insufficient.

WindShields: uh...? Have you *seen* how close Europa and Eeloo look?

http://i.huffpost.com/gen/1061601/thumbs/r-JUPITER-MOON-EUROPA-ICE-large570.jpg?8

http://wiki.kerbalspaceprogram.com/w/images/thumb/e/e0/TinyEeloo.png/270px-TinyEeloo.png

So the PQS uses the heightmap for each planet model to generate its terrain, but the planet models in scaled space don't have heightmaps? Now I'm just a little confused... To answer your question though, I want low / landed terrain to look better as high orbit seems to look ok for the most part. My whole endeavor so far is to create terrain that is closer to stock / real life when on or close to the surface (i.e. stuff to run into that poses a threat to navigation).

This is what happens. I am guessing that some (many) asteroids spawn too close to Kerbin, within it's enlarged SOI and moving a bit too slow to escape it so they end up in Kerbin orbit from the beginning. Those spawning farther away seem to be ok, so simple fix should be just making them spawn outside of Kerbin SOI.

Isn't it within the realm of possibility for Kerbin (or earth for that matter) to have small asteroid satellites in orbit?

[NathanKell]

darkside: I'll see what I can dig up about asteroids. Been busy dealing with aftermath of moving (many boxes, much unpacking, wow!) so I've been operating at slower-than-normal speed. I did verify that all my stuff does at least work in .23.5 so I didn't feel the urgency to roll out an insta-fix.

SpacedInvader: Ah, maybe I should back up a bit--and forgive me if this is info that you already know.

Celestial bodies other than Jool are rendered in two ways in KSP: via procedural terrain (PQS) when close, and via a static textured mesh (the scaled space mesh) when far away. Jool lacks PQS and has only the static mesh.

The static mesh is spherical mesh transformed to fit the planet's terrain and given a diffuse map (the colors) and a normal map (the bumpiness you can see from high orbit). In stock KSP, since the terrain is already known, (and ditto for PlanetFactory IIRC) the meshes are prebuilt to follow the procedural terrain and just loaded as they are; in RSS, each load, I reconfigure the meshes to comport to the PQS. Since these are static meshes with a single texture page each diffuse/normal, so they have a hard limit of 8192 pixels wide for each texture. This means, when you are viewing a CB in scaled space, you literally *cannot* make it less blurry beyond a certain point (well, if you remade the mesh to have *multiple* textures, you could, but 8192x4096 is 32MB of ram each).

I do *not*, however, remake the texture on each load (it takes about 40 minutes for my i7 to render an 8192x4096 map of a planet), though RSS can be configured to do that (the Export node in the cfg, when reenabled [i.e. foo removed] will export diffuse and bump maps of the given size for that body).

The dynamic terrain is the terrain you can see from very low orbit and from within the atmosphere/on the ground. It is dynamically generated into a sphere subdivided into quadtrees (Planet Quadtree Sphere) and then each vertex (and other things) are modified by all PQSMod components (like a heightmap component, or a simple noise component, or a City component that adds a static mesh...). Once all PQSMods have been applied (in their specified order) the quad can be rendered.

here is a previous post of mine detailing PQSmods.

If you want to increase the fineness of the terrain (so it doesn't look so flat/angular/low-detail), you can increase maxLevels (it's commented out, IIRC, in v6pre) which will increase the maximum subdivision of the PQS beyond what you have set in Terrain Quality. I run with 14, which means my MET is often yellow but I get very pretty coastlines in Florida. If you want to increase the roughness, your best bet is playing with deformity and frequency of the various PQSMods.

So, summary: PQS and its mods is the dynamic terrain (that usually is a heightmap and some noise/fractal-based things to create terrain below the resolution of the heightmap), then the result of that is "rendered" if you will to a mesh and two textures for the static scaled-space object you only see when far away (like, 120km or more--in RSS, 200km or more IIRC) from the body.

[Jupiter02]

weird..metaphor's texture pack kinda does nothing to ksp, some of the planets have the same texturee (i dont know about the same names if that supposed to happen) and the asteroid are too close to the sun

[Oksbad]

So does anybody know of a delta - V map for the bodies in this bundle (default settings)?

[NathanKell]

http://en.wikipedia.org/wiki/Delta_v_budget

[Oksbad]

http://en.wikipedia.org/wiki/Delta_v_budget

I am aware of what a delta-v budget is, yes. I also have a delta-v map for the actual solar system. Are you implying that that map will work for the planets in this bundle?

[brooklyn666]

I am aware of what a delta-v budget is, yes. I also have a delta-v map for the actual solar system. Are you implying that that map will work for the planets in this bundle?

Yes. They are the same.

[NathanKell]

OP states: This converts the Kerbol system into our real solar system. So yes.

[Konstantine the Great]

Is the Real Earth texture out/released yet?

[Oksbad]

OP states: This converts the Kerbol system into our real solar system. So yes.

Ah, I see! I didn't realize it was supposed to be an exact match. I assumed the inner planets were roughly the same but the outer ones were made up due to a lack of gas giants.

So some of the gas giants are represented by rocky planets? Is there a way to change them to look like gas giants (not necessarily exactly like their real life equivalents), or failing that switch to an alternate configuration of RSS without losing my save? I only have stuff in low earth orbit.

Edited April 7, 2014 by Oksbad

[SpacedInvader]

darkside: I'll see what I can dig up about asteroids. Been busy dealing with aftermath of moving (many boxes, much unpacking, wow!) so I've been operating at slower-than-normal speed. I did verify that all my stuff does at least work in .23.5 so I didn't feel the urgency to roll out an insta-fix.

SpacedInvader: Ah, maybe I should back up a bit--and forgive me if this is info that you already know.

Celestial bodies other than Jool are rendered in two ways in KSP: via procedural terrain (PQS) when close, and via a static textured mesh (the scaled space mesh) when far away. Jool lacks PQS and has only the static mesh.

The static mesh is spherical mesh transformed to fit the planet's terrain and given a diffuse map (the colors) and a normal map (the bumpiness you can see from high orbit). In stock KSP, since the terrain is already known, (and ditto for PlanetFactory IIRC) the meshes are prebuilt to follow the procedural terrain and just loaded as they are; in RSS, each load, I reconfigure the meshes to comport to the PQS. Since these are static meshes with a single texture page each diffuse/normal, so they have a hard limit of 8192 pixels wide for each texture. This means, when you are viewing a CB in scaled space, you literally *cannot* make it less blurry beyond a certain point (well, if you remade the mesh to have *multiple* textures, you could, but 8192x4096 is 32MB of ram each).

I do *not*, however, remake the texture on each load (it takes about 40 minutes for my i7 to render an 8192x4096 map of a planet), though RSS can be configured to do that (the Export node in the cfg, when reenabled [i.e. foo removed] will export diffuse and bump maps of the given size for that body).

The dynamic terrain is the terrain you can see from very low orbit and from within the atmosphere/on the ground. It is dynamically generated into a sphere subdivided into quadtrees (Planet Quadtree Sphere) and then each vertex (and other things) are modified by all PQSMod components (like a heightmap component, or a simple noise component, or a City component that adds a static mesh...). Once all PQSMods have been applied (in their specified order) the quad can be rendered.

here is a previous post of mine detailing PQSmods.

If you want to increase the fineness of the terrain (so it doesn't look so flat/angular/low-detail), you can increase maxLevels (it's commented out, IIRC, in v6pre) which will increase the maximum subdivision of the PQS beyond what you have set in Terrain Quality. I run with 14, which means my MET is often yellow but I get very pretty coastlines in Florida. If you want to increase the roughness, your best bet is playing with deformity and frequency of the various PQSMods.

So, summary: PQS and its mods is the dynamic terrain (that usually is a heightmap and some noise/fractal-based things to create terrain below the resolution of the heightmap), then the result of that is "rendered" if you will to a mesh and two textures for the static scaled-space object you only see when far away (like, 120km or more--in RSS, 200km or more IIRC) from the body.

Ok, this would explain why the surface of the CB tends to "evaporate" as you descend to land. The static mesh is giving way to the dynamic terrain. I'm guessing this happens in stock as well, but because the static mesh is 100% match to the dynamic, you don't see the switch, or at least not as easily. That being said, the heightmap does affect the PQS dynamic output, so I guess my desire to try and increase it's resolution somehow still stands. I will also go back to messing with the PQS modifiers to see if I can come up with something less drastic (75km is pretty big), but also with much more definition so landing and exploring is much more challenging and fun.

[NathanKell]

Konstantine the Great: It's been out for about 2 months, altough not on the OP. Well, now it is.

Oksbad: Yes, there have been packs posted using Texture Replacer and EVE to change them. Don't have a link offhand.

SpacedInvader: This does happen in stock, and if you watch carefully at about 60km you can see it happen.

The heightmap *only* affects the PQS; it's one of the PQSMods. The PQS as a whole (counting all its PQSMods) then affects the scaled space mesh due to some code I added. Let me repeat: Unless you want to create your own PQSMod that supports a paging heightmap, you will not be able to increase the resolution of the heightmap beyond what I have already set for Earth (8192x4096). Instead you need to play with the other PQSMods. The Moon, as yet, is still using a stock heightmap, but that can be upped to 8192...

Changelog

v6 \/

*Fixed orbit lines (thanks HoneyFox!)

*Added pressureCurve support with curves for Earth, Venus, and Mars (thanks Starwaster!)

*Added temperatureCurve support (nothing here yet)

*Fixed a typo with tidally locked orbits (thanks eggrobin!)

*Converted orbits to Earth-relative inclination, to support axial tilt (megathanks eggrobbin!)

*Recompiled for .23.5

[FanaticalFighter]

*Casually browsing for mods*

*Sees new RSS version compatible with 0.23.5, inclined planets, and Earth *

*Goes crazy*

Does this support asteroids as well, Nathan?

[HoneyFox]

*Casually browsing for mods*

*Sees new RSS version compatible with 0.23.5, inclined planets, and Earth *

*Goes crazy*

Does this support asteroids as well, Nathan?

Looks like the probability of an asteroid being spawned on a direct impact orbit has raised quite a lot...

And i've been busy sending multiple probes with ion thrusters to redirect them these days... quite busy.

[SpacedInvader]

SpacedInvader: This does happen in stock, and if you watch carefully at about 60km you can see it happen.

The heightmap *only* affects the PQS; it's one of the PQSMods. The PQS as a whole (counting all its PQSMods) then affects the scaled space mesh due to some code I added. Let me repeat: Unless you want to create your own PQSMod that supports a paging heightmap, you will not be able to increase the resolution of the heightmap beyond what I have already set for Earth (8192x4096). Instead you need to play with the other PQSMods. The Moon, as yet, is still using a stock heightmap, but that can be upped to 8192...

I've been playing with tweaking the PQS mods, but there are certain terrain features that just refuse to gain definition (the twin craters, for example) without skewing the heightMapDeformity to some huge level. I think this may be the result of how those features are created compared to normal craters. That being said I've been able to tweak the munar surface into something interesting again at least and some issues at least I'm almost sure stem from the massive increase in distances associated with the rescale... if the planet is 10x larger, an object is then 10x farther away so it would have to be 10x larger to appear the same as if you were closer to it. I may just have to accept a much different appearance than what I've gotten used to in stock and just be happy that I've been able to turn the surface into something better than flat. I would definitely still like to see the rest of the system with the higher resolution heightmaps though, and would be interested in how you went about making the one for Kerbin. I should also mention that I've tried now for a couple of hours to get the PQS to work for Minmus as well and just can't seem to get it do do much more than the old flat plain that I found originally on the Mun. Any thoughts as to why this might be the case?