[1.2] Real Solar System v12.0 Dec 8

[NathanKell]

ANWRocketMan: No apologies necessary; it's a heck of a thread by this point. :]

As eggrobin is reminding me, I need to put up docs.

whiskey1992: output_log.txt please.

Kingster8128: ditto.

SpacedInvader: The site Ralathon linked to charges $8 "for bandwidth costs" to download the hirez Mars maps.

SpacedInvader: As ANWRocketMan says they are reversed because the scaled-space mesh of Kerbin is UV mapped that way, and because evidently the heightmap is that way too. But perhaps that only holds for Kerbin?

ANWRocketMan: Sounds like either I flipped them wrong or Mun's mapping isn't flipped. Weird.

Regarding heightmap/scaled space. I will look into why it's right for Earth/Moon but not Mars; that sounds like something is failing.

SlimeCrusher: Yes, and it's not a bug. When you're trying to move KSC, you need to set its radial offset to how far from sea level it should be placed. Sounds like the elevation there is much more than the 60 or so meters that is the default. What I suggest in these cases is to use repositionToSphereSurface = true which will move it to whatever height the sphere surface is.

Starwaster: it shouldn't need to be commented out, but it should be 1!

Mr.Rocket: Yes, it comes in the download. Check back a few pages; metaphor released an updated CFG. I will update the OP.

That "nosecone" is actually a procedural interstage with the top radius made as small as possible and nothing above it.

[Starwaster]

ANWRocketMan: No apologies necessary; it's a heck of a thread by this point. :]

As eggrobin is reminding me, I need to put up docs.

whiskey1992: output_log.txt please.

Kingster8128: ditto.

SpacedInvader: The site Ralathon linked to charges $8 "for bandwidth costs" to download the hirez Mars maps.

SpacedInvader: As ANWRocketMan says they are reversed because the scaled-space mesh of Kerbin is UV mapped that way, and because evidently the heightmap is that way too. But perhaps that only holds for Kerbin?

ANWRocketMan: Sounds like either I flipped them wrong or Mun's mapping isn't flipped. Weird.

Regarding heightmap/scaled space. I will look into why it's right for Earth/Moon but not Mars; that sounds like something is failing.

SlimeCrusher: Yes, and it's not a bug. When you're trying to move KSC, you need to set its radial offset to how far from sea level it should be placed. Sounds like the elevation there is much more than the 60 or so meters that is the default. What I suggest in these cases is to use repositionToSphereSurface = true which will move it to whatever height the sphere surface is.

Starwaster: it shouldn't need to be commented out, but it should be 1!

Mr.Rocket: Yes, it comes in the download. Check back a few pages; metaphor released an updated CFG. I will update the OP.

That "nosecone" is actually a procedural interstage with the top radius made as small as possible and nothing above it.

Oh ok so SSTScale = 1 is ok?

(good thing I didn't get around to commenting it out on mine...)

[metaphor]

So, does that Earth texture (actually i think its just Earth, not a texture) come in the download, or do i have to replace something else to get it? Also, in metaphors version with stock+PF, would the universe replacer replace the Earth texture? I plan on making an ultra realistic KSP

That config is outdated, if you use it with this version of RSS it replaces it back with the Kerbin texture (also the cloud mod files aren't compatible with that mod's newest version). I'm working on a new one but would like to see where this goes with the new Mars etc textures since that would make it more realistic. Also trying to figure out how to use the Planet Factory planet maker to make better real planets and moons.

[Green Skull]

I know Nathan you said that the Mun maps needed something doing to them but I'm having trouble locating what it is I'm supposed to do in the thread lol. Any pointers?

[soverign]

metaphor, I updated your config to incorporate all of the changes in version 6 as well as updated the orbital parameters using the same method as the other planets. I also added the missing CelestialBodyScienceParams to each body that didn't have them. I have a link to it on page 233.

[metaphor]

metaphor, I updated your config to incorporate all of the changes in version 6 as well as updated the orbital parameters using the same method as the other planets. I also added the missing CelestialBodyScienceParams to each body that didn't have them. I have a link to it on page 233.

Didn't see that, awesome!

[NathanKell]

Aaaaand OP updated for that.

Green Skull: http://forum.kerbalspaceprogram.com/threads/55145-0-23-5-Real-Solar-System-v6-4-7-14?p=1077612&viewfull=1#post1077612

Starwaster: it defaults to 1 so commenting it out is fine too.

[regex]

If anyone else wants to try it: Just dump THIS heightmap in your RealSolarSystem\Plugins\PluginData folder and copy paste the following PQS code to Duna's RSS config.

PQS
{
Duna
{
maxLevel = 14
maxQuadLenghtsPerFrame = 0.8 //0.03 -- and yes, typo is correct.
//visRadSeaLevelValue = 7.0 //5.0 // the max visRad
//visRadAltitudeValue = 1.7999999523162842 // the minimum visRad
//visRadAltitudeMax = 15000.0 //10000.0

PQSMod_VertexSimplexHeightAbsolute // doubles
{
deformity = 900 //1000 // 485
persistence = 0.7 // 0.60000002384185791
frequency = 36 //12 // 24
}
PQSMod_VertexHeightNoiseVertHeightCurve2 // floats
{
deformity = 5000 //6000 // 4000
ridgedAddFrequency = 48 // 48
ridgedSubFrequency = 32 // 32
//ridgedAddOctaves = 8 // 6 INT
simplexHeightStart = 800 // 800
simplexHeightEnd = 9000 // 4600

}
PQSMod_VertexRidgedAltitudeCurve // floats
{
deformity = 950 // 1800 //1100 // 750
ridgedAddFrequency = 140 // 25 // 140
//ridgedAddOctaves = 8 // 3 INT
simplexHeightStart = 500 // 0
simplexHeightEnd = 9000 // 6000
}
PQSMod_VertexHeightMap // doubles
{
heightMapOffset = -2150.0 //-2000.0
heightMapDeformity = 17300.0 //15600.0 //7000 // 5000
heightMap = GameData/RealSolarSystem/Plugins/PluginData/DunaHeight.png
}
PQSMod_AltitudeAlpha // doubles
{
atmosphereDepth = 6000 // 4000
}
}
KerbinOcean
{
PQSMod_AerialPerspectiveMaterial // floats
{
atmosphereDepth = 7500 // 5000, scale height in m
}
}
}

I did some basic copy-pasta with your PQS here and changed some values as appropriate for Moho under 6.4:1 Kerbin (max height is 1.5x normal, for instance) and, even without a custom height map, I see dramatic differences in land rendering. It's ... beautiful. The only thing I could wish for is a "layman's" explanation of the different PQS values there. Suppose I should get to Googling...

Javascript is disabled. View full album

[SpacedInvader]

....what facility. Ain't nuthin' but a hole.

So that's where port Canaveral came from...

SpacedInvader: The site Ralathon linked to charges $8 "for bandwidth costs" to download the hirez Mars maps.

SpacedInvader: As ANWRocketMan says they are reversed because the scaled-space mesh of Kerbin is UV mapped that way, and because evidently the heightmap is that way too. But perhaps that only holds for Kerbin?

ANWRocketMan: Sounds like either I flipped them wrong or Mun's mapping isn't flipped. Weird.

Regarding heightmap/scaled space. I will look into why it's right for Earth/Moon but not Mars; that sounds like something is failing.

I've voting for the NASA data then, it's free and way higher resolution and it seems like Ralathon at least is having some luck with it, though I haven't tried the newest noise map. Also, they have elevation data for Venus and Mercury and probably at least some moons, though I haven't spent much extra time looking. As for the flipping, I think it might be limited to Kerbin, at least at this point, though we haven't even finished three planets yet, so who knows what sort of messes we'll find...

Can you shed any light on my difficulties in getting virtually ANY terrain to appear with my heightmaps? I've redone my conversion process so that it will output an image with much wider variation between high and low (the old one linked earlier by Ralathon was compressed towards the low end), but aside from Olympus Mons, which appears, but is quite hard to see (I guess thats what you get with a 600km wide mountain), I've not been able to get.... Gonna stop myself here and say I was working under the impression that certain features were much smaller than they actually are... Will go back to trying to enhance their appearance and maybe do a little tweaking to get them to stand out a little more than they really should.

On that note though, what are the chances of getting those fine tuning controls I asked for a few pages back? Ralathon's noise function is a good start, but the only way we're going to get something other than 5km x 5km hills when at ground level is working with Octaves, Lacunarity, and Persistence for all of the subsections.

EDIT: I'm suddenly curious if I even needed to redo my process. My understanding of the way the heightmap deformity mod is probably supposed to work is that it is the difference between the highest and lowest points on the map, even if those points are only a few shades apart. So even though my previous heightmap was much darker and skewed towards the low levels, by virtue of the fact that there was no true white in it, it would mean that the lightest color would still be set to 29387m (highest point above ground when lowest point is shifted 0m), or am I just crazy?

The example heightmaps so people know what I'm talking about:

Javascript is disabled. View full album

Edited April 15, 2014 by SpacedInvader

[SpacedInvader]

This got me a little excited so I thought I'd post it...

May I present the Olympus Mons caldera

[SpacedInvader]

@NathanKell: Can you comment on this lines from the PQS components listed for Duna:

<requirements>
    <ModiferRequirements>VertexMapCoords MeshCustomNormals</ModiferRequirements>
</requirements>

And also

<requirements>
    <ModiferRequirements>MeshCustomNormals</ModiferRequirements>
</requirements>

This seems to indicate the necessity of including a normal map to get the desired results from the mod, is this the case, or is the heightmap png the same as this?

The reason I'm asking is because, while I've been able to get certain features to show up (see my previous post) most, if not all of canyons and valleys just refuse to appear. Earlier tonight I thought that it was because of the sheer size of the features, but after lots of messing around, I've decided something is definitely not being processed correctly here. I've come to this conclusion because I've been able to clearly see the boundaries of Olympus Mons (600km across) from multiple angles and distances, but placing myself in the thinnest part of Valles Marineris and Ophir Chasma where 10km elevation differences should at least be apparent, if not drastic, reveals only flat, rolling hills pitted by craters (which exist in the heightmap). Were it not for the crater generation and the big mountain, I would have thought the game was just not reading the heightmap correctly, but both of these are depicted in the heightmap, so something else is completely wiping out low level elevation variation. I should also add that I've tried turning all of the noise functions off, as well as dialing them down significantly, but nothing seems to pull the valleys out of the ground, so to speak...

EDIT: I'm starting to think it might be easier to find a way to get rid of the stock planets and create the whole system using the Planet Factory CE rather than try to manipulate Squad's code to do something it just doesn't seem to want to do.

[Mr.Rocket]

I got metaphors and soverigns settings for RSS, and it works great.

Unfortunately, lots of the clouds aren't working. Do i need another mod with clouds?

Pictures:

Javascript is disabled. View full album

[Starwaster]

EDIT: I'm suddenly curious if I even needed to redo my process. My understanding of the way the heightmap deformity mod is probably supposed to work is that it is the difference between the highest and lowest points on the map, even if those points are only a few shades apart. So even though my previous heightmap was much darker and skewed towards the low levels, by virtue of the fact that there was no true white in it, it would mean that the lightest color would still be set to 29387m (highest point above ground when lowest point is shifted 0m), or am I just crazy?

The example heightmaps so people know what I'm talking about:

http://imgur.com/a/G8rIU#0

I don't think you're crazy, I've been thinking along those lines myself.

I think we need the maximum possible range of shades in the heightfield maps. When you stretch out the elevation (which is what you're doing when you scale deformity up) the gradation between elevations is going to be steeper if you're using a narrow range of shades than if you were using the full range of available shades.

Put another way, if the lowest point on your map is represented by 32 and the highest point represented by 128, that's a separation of 96. Taking the separation in meters between high and low, that's 306.11458 meters between steps. That's not very much detail. So you want the maximum possible range of colors utilized in your heightfield map. For accuracy you probably want to use something like Matlab like Ralathon's been using as opposed to just photoshopping like I've been doing for Duna. Unfortunately, because we're using grayscale here, we're only going to get a maximum of 256 range of colors. That's a separation of ~114.8 meters between elevations. You're still losing a lot of detail

Basically we're dealing in 8 bit.

[Guest]

I got metaphors and soverigns settings for RSS, and it works great.

Unfortunately, lots of the clouds aren't working. Do i need another mod with clouds?

Pictures:

http://imgur.com/a/jPIhW

You want "EnvironmentalVisualEnhancements 7-2" to get clouds, I was able to edit some settings in "cloudLayers.cfg" to give:

Titan a goldenrod cloud colour of Red:0.855 green:0.647 blue:0.125 alpha:1.0 (golden rod: a yellowy brown colour) with eve1 texture @ altitude = 200000 (may be abit too yellow)

Venus a reddish cloud colour of r = 0.38 g = 0.16 b = 0.098 a = 1 with eve1 texture, 2 layers @ layer 1 of altitude = 50000, layer 2 of altitude = 100000

Uranus a blueish cloud colour of r = 0.4 g = 0.4 b = 0.6 a = 1 with jool1 texture @ altitude = 390000

Neptune a blueish cloud colour of r = 0.4 g = 0.4 b = 0.6 a = 1 with kerbin1 texture @ altitude = 250000 (i dont know what to do about Laythe islands)

Mars I left colour as it was but edited @ altitude = 50000

Earth i left colour as it was but edited @ altitude = 12000

I removed cloud entries for Jupiter/Saturn as they are gas giants and clouds seemed to hurt their appearance

If there is an official/recommended "cloudLayers.cfg" and any needed cloud textures for metaphors and soverigns RSS planet set that is for RSS v6/EnvironmentalVisualEnhancements 7-2, i would love to get my hands on it. if anyone has this please link to it

But if not my settings provide a decent looking set of clouds for now. although cloud heights/shades arnt 100% true to life, they are better than they were.

Is there anyone working on RSS cloud settings for standard RSS planet set and/or metaphors and soverigns RSS planet set?

Edited April 15, 2014 by Guest

[soverign]

You want "EnvironmentalVisualEnhancements 7-2" to get clouds, I was able to edit some settings in "cloudLayers.cfg" to give:

Titan a goldenrod cloud colour of Red:0.855 green:0.647 blue:0.125 alpha:1.0 (golden rod: a yellowy brown colour) with eve1 texture @ altitude = 200000 (may be abit too yellow)

Venus a reddish cloud colour of r = 0.38 g = 0.16 b = 0.098 a = 1 with eve1 texture, 2 layers @ layer 1 of altitude = 50000, layer 2 of altitude = 100000

Uranus a blueish cloud colour of r = 0.4 g = 0.4 b = 0.6 a = 1 with jool1 texture @ altitude = 390000

Neptune a blueish cloud colour of r = 0.4 g = 0.4 b = 0.6 a = 1 with kerbin1 texture @ altitude = 250000 (i dont know what to do about Laythe islands)

Mars I left colour as it was but edited @ altitude = 50000

Earth i left colour as it was but edited @ altitude = 12000

I removed cloud entries for Jupiter/Saturn as they are gas giants and clouds seemed to hurt their appearance

If there is an official/recommended "cloudLayers.cfg" and any needed cloud textures for metaphors and soverigns RSS planet set that is for RSS v6/EnvironmentalVisualEnhancements 7-2, i would love to get my hands on it. if anyone has this please link to it

But if not my settings provide a decent looking set of clouds for now. although cloud heights/shades arnt 100% true to life, they are better than they were.

Is there anyone working on RSS cloud settings for standard RSS planet set and/or metaphors and soverigns RSS planet set?

I'm working on some proper clouds layers. Uranus and Neptune don't look very good currently. Uranus needs to be flatted out but everything I tried didn't seem to flatten it. The pack currently has no new Normal maps so the surface lighting is still default. That's why you can still see the islands on Neptune.

Does anybody know if Specular maps are supported? It might be a good thing to add to Earth.

[Guest]

thanks for the FAST reply soverign! Please keep us all updated on your work on cloud layers, we all would be very happy to have them

[Starwaster]

I removed cloud entries for Jupiter/Saturn as they are gas giants and clouds seemed to hurt their appearance

Unfortunately, we might need to use clouds to to have actual gas giants that don't have a (reachable) solid surface.

Ultimately what I'd like to do is shrink the radius of Jool/Jupiter to something the size of Earth (1.0-1.5x Earth size) and give it a set of pressureCurve / temperatureCurve that approximate what we know (and speculate) about Jupiter. You'd be able to probe the upper reaches but then temperature would quickly rise and destroy you even without Deadly Reentry. I've done some work on that experimentally but visually it looks like crap because you can still see the solid surface, which looks really strange with the atmospheric shell pulled out to Jupiter's radius. A series of volumetric and cloud layers might be the way to go to make it look right or at least to hide the 'core'.

[soverign]

I added links to the cloud files in the post.

[Vim Razz]

The only thing I could wish for is a "layman's" explanation of the different PQS values there. Suppose I should get to Googling...

Have you tried playing around with the KittopiaTech planet editor yet? Being able to see how PQS changes translate directly into the game helps a lot.

In my own efforts to "beautify" my 10x stock .cfg (based on frozenbacon's 10x .cfg file plus the MapDecalTangent fix provided by NathanKell), I'm to the point of almost having a routine worked out:

- HyperEdit to planet, open up KittopiaTech

- load planet template and save data to create an "as is" data template

- copy "as is" planet data from KittopiaTech's CustomData.cfg to a reference file

- play around with PQS values until is looks good (or less boringly flat, at least)

- hit the rebuild and save buttons to store the new planet data

- line-item compare the new CustomData.cfg to the "as is" template made earlier (I use Notepad++'s compare plugin)

- copy the modified value definitions (no need to add the others) to the RealSolarSystem.cfg in a separate KSP install for testing

- swear and tinker as necessary until it works

Edited April 15, 2014 by Vim Razz

[regex]

Have you tried playing around with the KittopiaTech planet editor yet? Being able to see how PQS changes translate directly into the game helps a lot.

I'll give that a try. I've been using a combination of Hyperedit and a very pared down install (like twelve parts) to check things out, but even then it still takes time to load up the game.

[DoctorCruz]

This. is. awesome. Interesting the first time you play with it

Edited April 15, 2014 by DoctorCruz

[SpacedInvader]

I don't think you're crazy, I've been thinking along those lines myself.

I think we need the maximum possible range of shades in the heightfield maps. When you stretch out the elevation (which is what you're doing when you scale deformity up) the gradation between elevations is going to be steeper if you're using a narrow range of shades than if you were using the full range of available shades.

Put another way, if the lowest point on your map is represented by 32 and the highest point represented by 128, that's a separation of 96. Taking the separation in meters between high and low, that's 306.11458 meters between steps. That's not very much detail. So you want the maximum possible range of colors utilized in your heightfield map. For accuracy you probably want to use something like Matlab like Ralathon's been using as opposed to just photoshopping like I've been doing for Duna. Unfortunately, because we're using grayscale here, we're only going to get a maximum of 256 range of colors. That's a separation of ~114.8 meters between elevations. You're still losing a lot of detail

Basically we're dealing in 8 bit.

I did go back into photoshop and do a histogram adjustment to make the thing expand all the way from 0 to 255 instead of ~117, which resulted in the picture I posted above. That highlights one problem with Ralathon's code that I'm not really liking: Because of the adjustments he makes to get the cliffs in place, it really washes out detail features like that caldera. This whole process I feel is going to end up having to be a balancing act between what KSP will allow and what we're willing to give up.

Edited April 15, 2014 by SpacedInvader

[Guest]

I added links to the cloud files in the post.

Clouds seem better, but questions>> (all my viewings were done from tracking station)

Earth's clouds are set to 4km, isnt this slightly low (i had assumed aprox 10km, is this intentional??)

Mars clouds seem a little low at points sinking under planets surface (is this intentional??)

Venus/Titan clouds are so thick that you cant see surfaces at all (is this intentional??)

Uranus clouds seem 100% under surface of planet (is this intentional??)

Please dont think of this as a complaint, only as a question for my own info

[Ralathon]

I did go back into photoshop and do a histogram adjustment to make the thing expand all the way from 0 to 255 instead of ~117, which resulted in the picture I posted above. That highlights one problem with Ralathon's code that I'm not really liking: Because of the adjustments he makes to get the cliffs in place, it really washes out detail features like that caldera. This whole process I feel is going to end up having to be a balancing act between what KSP will allow and what we're willing to give up.

The reason my code doesn't catch the caldera is that all the cliffs need to be at roughly the same height. For cliff detection the map is only split in 2 segments: low areas and high areas. If the depressed region (like the caldera) happens to be in high up the algorithm won't catch it.

It is then further destroyed by the Perlin noise scaling to height as opposed to something more sensible.

Programming something that detects craters and calderas on high areas is going to be difficult. I'm not saying its impossible, I certainly got some ideas on how to do it. But it's going to eat a lot of time that I don't currently have.

[soverign]

Clouds seem better, but questions>> (all my viewings were done from tracking station)

Earth's clouds are set to 4km, isnt this slightly low (i had assumed aprox 10km, is this intentional??)

Mars clouds seem a little low at points sinking under planets surface (is this intentional??)

Venus/Titan clouds are so thick that you cant see surfaces at all (is this intentional??)

Uranus clouds seem 100% under surface of planet (is this intentional??)

Please dont think of this as a complaint, only as a question for my own info

The clouds in mod appear to be based on Cumulus clouds which are low-level clouds typically only about 2 KM above the ground.

I didn't really adjust the height on Mars yet since I'm waiting to so how the terrain will be adjusted.

Venus and Titan are both completely covered by clouds in reality so I did the same.

I disabled the cloud cover on the gas giants for now since the cloud layers didn't look all that good due to flickering.