[1.2] Real Solar System v12.0 Dec 8

[sploooshman]

NathanKell - Slimecrusher : I was being lazy when I resized my EarthColour.png with mspaint lol and as I assumes it had turned the transparent in to white , re edited with photoshop and it kept the transparency of the land so now I have green and blue

heres a edited version of the file for you http://www./view/n4frv7lycwrq13o/EarthColor.png

The new ksc location has totally screwed up my orbital inclination of my station compared to my lauch but hey a lil more DV and a plane correction and im ok , great job guys

[ThorBeorn]

I'm using the latter; real life sizes and orbits, but with Kerbin still Kerbin. To do it, replace your PQSCity and PQS_MapDecalTangent with the ones I posted, and comment out any lines that reference the textures (search for .png).

Fake edit: Decided I'd just upload my config to make it easier. Here you go.

It's not perfect, but works with both default Kerbin and the 8K texture/4K heightmap I use. If you need to raise/lower the KSC buildings change the repositionRadiusOffset value under PQSCity.

Yey, thanks!

[metaphor]

Too many data charts on Venus disagrees with each other. NASA doesn't even have a decent model for it listed at all like they do for Mars or Earth. I'd love to have a better curve for it, but I just can't find any information that fills me with confidence to make one better than what's in there now Listed scale heights range from 15-22. Wiki lists it's atmosphere as ending at 250km but I'm a bit skeptical at that.

And we've got a heck of a lot more information on Venus than we do on Titan...

Here's one I found to 100 km (page 5 of this pdf). You can extend it higher by setting scale height after 100 km to about 5 km. All the models I've seen agree that the scale height of Venus gets shorter with increasing altitude until ~100 km. Since it has a shorter scale height than Earth at high altitude, Venus's atmosphere "ends" faster than you would think.

edit: just finished a Venus pressure curve (link). Looking up info for Titan. This site looks promising. Or should I just let eggrobin take care of it?

edit 2: did a Titan pressure curve as well (link).

note: these are just pressures. I'm assuming FAR does the conversion to density. You need temperature data for that though and the in-game temperatures are way off the real ones. I still think just converting everything to density (since that's all you need for aerodynamics) and not worrying about temperature and composition would be better. (pressure = density * molar mass / temperature)

Edited April 10, 2014 by metaphor

[maccollo]

So... asteroid redirect is every hard in RSS. Will require 100 km/s of delta V.

[metaphor]

So... asteroid redirect is every hard in RSS. Will require 100 km/s of delta V.

I had that happened after I rescaled the system on the same install. Some of the asteroids previously near Earth orbit were now close to Uranus. But all the new asteroids on the same save started spawning close to Earth/Kerbin.

So it shouldn't really be a problem, all new asteroids should spawn close to wherever Kerbin/Earth is in your save.

[Starwaster]

Here's one I found to 100 km (page 5 of this pdf). You can extend it higher by setting scale height after 100 km to about 5 km. All the models I've seen agree that the scale height of Venus gets shorter with increasing altitude until ~100 km. Since it has a shorter scale height than Earth at high altitude, Venus's atmosphere "ends" faster than you would think.

edit: just finished a Venus pressure curve (link). Looking up info for Titan. This site looks promising. Or should I just let eggrobin take care of it?

edit 2: did a Titan pressure curve as well (link).

note: these are just pressures. I'm assuming FAR does the conversion to density. You need temperature data for that though and the in-game temperatures are way off the real ones. I still think just converting everything to density (since that's all you need for aerodynamics) and not worrying about temperature and composition would be better. (pressure = density * molar mass / temperature)

I've some reservations about FAR after it told me terminal velocity just above the surface of Venus was 7 m/s which I know is off. Could be the mass / cross section of the probe so I'll try again with something smaller but at the same mass. Something about the size and mass of a certain Venera probe whose chute failed just before landing.

[SpacedInvader]

@NathanKell: So it just occurred to me that it's unlikely that you're going to develop height maps for the stock planets to be used in the scaled system. Seeing as how I would like to keep the stock system (probably with planet factory planets as well), it looks like I should start thinking about making some of my own. The question is, how should I go about doing this? What tools will I need and where can I get the stock planet height information to work with?

[AndreyATGB]

@NathanKell: So it just occurred to me that it's unlikely that you're going to develop height maps for the stock planets to be used in the scaled system. Seeing as how I would like to keep the stock system (probably with planet factory planets as well), it looks like I should start thinking about making some of my own. The question is, how should I go about doing this? What tools will I need and where can I get the stock planet height information to work with?

I'm assuming you want to make a 10x Kerbol system, you can probably get height maps from ScanSAT. Remember that you're spreading the surface area of a planet that was 10 times smaller, so all features will be much flatter. I think RSS actually doesn't flatten the terrain in any way, so what you're seeing now is the stock height map.

[ANWRocketMan]

@NathanKell: So it just occurred to me that it's unlikely that you're going to develop height maps for the stock planets to be used in the scaled system. Seeing as how I would like to keep the stock system (probably with planet factory planets as well), it looks like I should start thinking about making some of my own. The question is, how should I go about doing this? What tools will I need and where can I get the stock planet height information to work with?

@AndreyATGB is right. The heightmap is the same as that of the stock game. Only the gradient of all the slopes is majestically reduced to a comfortable walking gradient due to the x10 stretching(as Andrey mentioned).

[SpacedInvader]

I'm assuming you want to make a 10x Kerbol system, you can probably get height maps from ScanSAT. Remember that you're spreading the surface area of a planet that was 10 times smaller, so all features will be much flatter. I think RSS actually doesn't flatten the terrain in any way, so what you're seeing now is the stock height map.

@AndreyATGB is right. The heightmap is the same as that of the stock game. Only the gradient of all the slopes is majestically reduced to a comfortable walking gradient due to the x10 stretching(as Andrey mentioned).

How would you recommend getting around this problem then? I spent the better part of two hours attempting to apply PQS settings to Minmus and couldn't get the terrain to be anything better than slightly not flat. I understand that we're just not going to get the same kind of terrain that exists in stock thanks to the stretching (of which I was already aware), but I certainty want something better than slightly not flat. My thinking is that a one way around this would be to apply a transformation to the height map histogram to enhance the difference and rate of change between levels. In theory this would increase the slopes enough to break up the terrain some.

[SlimeCrusher]

Ok... Now, im getting ANOTHER error... Earth is... Half black... Yea

[Green Skull]

Ok... Now, im getting ANOTHER error... Earth is... Half black... Yea

http://s30.postimg.org/8mzdrg9jl/screenshot8.png

Did you edit the textures or use something like a PngOptimizer to reduce size ? Have you tried a fresh download and textures?

[NathanKell]

pingopete: Flicker remains as before: as soon as you enter a different scene and return, it's gone. Shorelines are better now, especially if you play with a super-high maxLevels. And yes, that's the texture in the OP.

SpacedInvader: I am not sure whether PlanetFactory CE allows you to export heightmaps; if it doesn't, let me know and I'll add some functionality to RSS to do that. The problem, let me reiterate, is *not* that the heightmap is somehow mismade; it is that for a planet of Earth's size, a single large heightmap is simply insufficient to produce anything but gentle inclines. This is because the maximum resolution possible in KSP for a heightmap for a planet of Earth's size is 5km a pixel. Even if, let us say, one went from sea level to the height of Mount Washington (highest point in the Northeast US) in the space of one pixel, it would *still* be only a 22 degree slope. You simply cannot get the "cragginess" you want from playing with the heightmap. Nor is there a way to play with how the heightmap is interpreted (in its own heightmap PQSMod).

Instead, you have two options. It's best to combine them, but only one is currently supported in RSS.

Option 1 (not available yet) is to create a number of "detail area" heightmaps. For example, creating a hires heightmap for the area around KSC, or for the area around Kerbin City, or various other interesting spots. That's what that flat land around KSC actually is, by the way: it just has a flat heightmap. This way you can have a decent-res heightmap for the entire planet and then also have some high-detail areas.

Option 2 is to play with the procedural terrain PQSMods. That's exactly what they're there for--to create detail below the resolution of the heightmap. By playing with the frequency, persistence, octaves, deformity etc of the other PQSMods--particularly the Ridged Altitude Curve which does *exactly* what you want, i.e. sharpens slopes--you should be able to get good terrain. Watch that video where Mu explains PQS if you haven't yet, he demonstrates visually what various PQSMods do.

[SlimeCrusher]

Did you edit the textures or use something like a PngOptimizer to reduce size ? Have you tried a fresh download and textures?

Ok, first of all, yes, i had to resize them because of the white-red Earth bug, i resized them with GIMP, also, when i use a fresh download of the mod, i get the red-white Earth anyways

[SpacedInvader]

pingopete: Flicker remains as before: as soon as you enter a different scene and return, it's gone. Shorelines are better now, especially if you play with a super-high maxLevels. And yes, that's the texture in the OP.

SpacedInvader: I am not sure whether PlanetFactory CE allows you to export heightmaps; if it doesn't, let me know and I'll add some functionality to RSS to do that. The problem, let me reiterate, is *not* that the heightmap is somehow mismade; it is that for a planet of Earth's size, a single large heightmap is simply insufficient to produce anything but gentle inclines. This is because the maximum resolution possible in KSP for a heightmap for a planet of Earth's size is 5km a pixel. Even if, let us say, one went from sea level to the height of Mount Washington (highest point in the Northeast US) in the space of one pixel, it would *still* be only a 22 degree slope. You simply cannot get the "cragginess" you want from playing with the heightmap. Nor is there a way to play with how the heightmap is interpreted (in its own heightmap PQSMod).

Instead, you have two options. It's best to combine them, but only one is currently supported in RSS.

Option 1 (not available yet) is to create a number of "detail area" heightmaps. For example, creating a hires heightmap for the area around KSC, or for the area around Kerbin City, or various other interesting spots. That's what that flat land around KSC actually is, by the way: it just has a flat heightmap. This way you can have a decent-res heightmap for the entire planet and then also have some high-detail areas.

Option 2 is to play with the procedural terrain PQSMods. That's exactly what they're there for--to create detail below the resolution of the heightmap. By playing with the frequency, persistence, octaves, deformity etc of the other PQSMods--particularly the Ridged Altitude Curve which does *exactly* what you want, i.e. sharpens slopes--you should be able to get good terrain. Watch that video where Mu explains PQS if you haven't yet, he demonstrates visually what various PQSMods do.

Any chance you can link that video? I've been wanting some kind of guide and/or proper documentation for PQS ever since this whole process began and just haven't been able to find anything of the sort.

As for the first option, I'm suddenly reminded of some projects I did when I used to play Trainz. Because that game used UTM for its coordinate system, you could only get so much east-west distance before the distortion would become too great. The solution was to break up the coverage into multiple smaller maps which would be played in sequence going from one side of the route to the other. With that in mind, I'm wondering if it's possible to opt for different size and resolution combinations so that I could find one that would allow for full planetary coverage at a reasonable resolution with multiple heightmaps without placing too much of a burden on the system.

EDIT: I also want to mention that I don't think the heightmap is mismade, but rather that manipulating the heightmap might allow a jury rigged way around it the limitations of the system.

Edited April 10, 2014 by SpacedInvader

[Ralathon]

One thing that might help for the heightmap is to multiply it with some random noise.

Mountainranges on the current heightmap appear as white blobs. This means that the individual pixels don't differ that much, making your mountain range appear rather flat even though it is pretty high. If you multiply it with some random noise the highest areas should get a lot more individual variation while leaving the rest of the world relatively untouched, giving much bigger height differences over short distances.

EDIT:

Yea, after messing about a bit with MSpaint and the height map I am convinced that upping the relative height differences between pixels can produce some interesting terrain.

The uber pro editted area around the cape.

Result in game.

Obviously this is rather rough, those peaks are 15 kilometers high. But its a proof of principle.

Edited April 10, 2014 by Ralathon

[NathanKell]

SpacedIvander: I linked it a page or two back, but here it is again. Fast forward to about 15 minutes in IIRC (unless you want the stuff from Harv too).

The downside is that due to how KSP handles PQSMods, every mapdecal added will be checked for every vertex. Now, it should return quickly after a check if this vertex is radius units from the center of the decal, but still--it's not a good way to handle "piecing out" a global heightmap, rather for some few detail areas. What would be much better--and what asmi and I were talking about, oh, six months ago or so--would be to actually creating a paging/LOD PQSMod to handle multiple levels of terrain detail. But that's quite a bit of work.

Manipulating the heightmap is exactly what those other PQSMods do, basically. It's not like PQSMods all occur in their own universe; they're *all* applied, in order, for every vertex. Usually first the heigthmap, then the ridged curve, then the straight noise. They are, basically, signal processing.

Ralathon: That's, as above, exactly what the other PQSMods do. I'd much rather tweak the values of things already doing that than add false data to the heightmap (the reason a pixel is a given color in the heightmap is because the average height for that 5km x 5km area is that height).

Let me try to say this one more time: the main reason the terrain is poor in RSS is because I (and anyone else who wants to help) has not had the time or the luck to fix the other PQSMods. The tools are there. We just have to use them.

If we want 100% real terrain, then we need to play around with map decals and paging heightmaps and the like. But as long as we just want nice-looking terrain, the procedural tools we already have should suffice.

[SpacedInvader]

One thing that might help for the heightmap is to multiply it with some random noise.

Mountainranges on the current heightmap appear as white blobs. This means that the individual pixels don't differ that much, making your mountain range appear rather flat even though it is pretty high. If you multiply it with some random noise the highest areas should get a lot more individual variation while leaving the rest of the world relatively untouched, giving much bigger height differences over short distances.

EDIT:

Yea, after messing about a bit with MSpaint and the height map I am convinced that upping the relative height differences between pixels can produce some interesting terrain.

http://imgur.com/zeOjzaY.png

The uber pro editted area around the cape.

http://imgur.com/avNvpLH.png

Result in game.

Obviously this is rather rough, those peaks are 15 kilometers high. But its a proof of principle.

Is this with RSS installed, or is that on a stock sized planet?

[Ralathon]

Is this with RSS installed, or is that on a stock sized planet?

That's in RSS.

[SpacedInvader]

SpacedIvander: I linked it a page or two back, but here it is again. Fast forward to about 15 minutes in IIRC (unless you want the stuff from Harv too).

The downside is that due to how KSP handles PQSMods, every mapdecal added will be checked for every vertex. Now, it should return quickly after a check if this vertex is radius units from the center of the decal, but still--it's not a good way to handle "piecing out" a global heightmap, rather for some few detail areas. What would be much better--and what asmi and I were talking about, oh, six months ago or so--would be to actually creating a paging/LOD PQSMod to handle multiple levels of terrain detail. But that's quite a bit of work.

Manipulating the heightmap is exactly what those other PQSMods do, basically. It's not like PQSMods all occur in their own universe; they're *all* applied, in order, for every vertex. Usually first the heigthmap, then the ridged curve, then the straight noise. They are, basically, signal processing.

Ralathon: That's, as above, exactly what the other PQSMods do. I'd much rather tweak the values of things already doing that than add false data to the heightmap (the reason a pixel is a given color in the heightmap is because the average height for that 5km x 5km area is that height).

Let me try to say this one more time: the main reason the terrain is poor in RSS is because I (and anyone else who wants to help) has not had the time or the luck to fix the other PQSMods. The tools are there. We just have to use them.

If we want 100% real terrain, then we need to play around with map decals and paging heightmaps and the like. But as long as we just want nice-looking terrain, the procedural tools we already have should suffice.

I'd already seen that video, I was thinking there was another where he went into much greater detail. Is there any real documentation for the various PQS components describing what each does exactly and how to use them? Also, you talk about them as if you have access to them for modification, can you tell me where they reside and how I can get access to them?

[SpacedInvader]

That's in RSS.

So now I'm suddenly wondering how you were able to get such definition when NathanKell just said you wouldn't be able to do better than 22° from one cell to the next. Is that a "detail" heightmap rather than a planet wide heightmap?

[NathanKell]

SpacedInvader: alas, as with everything else KSP, the documentation is "look at variable names, try stuff out, repeat." Or asking other modders. Since most of the procedural PQSMods use libnoise-based noise, a fair attemt at "reading the manual" would be to familiarize yourself with libnoise and with Perlin noise / simplex noise and things like that, and their terminology. That'll make understand KSP's use of them much easier.

As to where they reside: they're components of the PQS object they modify. You can get them by finding the PQS and then grabbing all components of type PQSMod; that will get you a list of the PQSMods for that PQS. (PQSMods generally derived from the parent class PQSMod.) You can modify them by, once you have the pointer to the object, changing its members. When done, you rebuild the PQS. RSS does this, starting here: https://github.com/NathanKell/RealSolarSystem/blob/master/Plugins/RealSolarSystem/RealSolarSystem.cs#L524

As you can see below, I've exposed a number of PQSMods' members to the cfg; the next main step will be integrating the generic PQSMod loader Krag offered. However, in some ways that's less helpful because (I think--it's been a couple months) you'll have to fully specify PQSMod members, rather than now where things are only touched if you tell RSS to do so.

Regarding 22 degrees: I said that a slope from sea level to Mt. Washington (2km) if they were 5km apart, would be 22 degrees going only from the heightmap; sea level to 15km would be rather different. Also note that due to the various other PQSMods, height is never exactly what the heightmap says; my guess is the ridged altittude curve is making those slopes even sharper (presumably that much variation is enough to trigger it, whereas I haven't found the settings to trigger good behavior for the gentler slopes normally encountered).

Ralathon: that's very interesting! Are those mountains 5km x 5km at the base, or are the various other PQSMods tightening the base to make the slope sharper?

[Ralathon]

Ralathon: that's very interesting! Are those mountains 5km x 5km at the base, or are the various other PQSMods tightening the base to make the slope sharper?

I didn't check their bases, but they look 5x5. As I said they're about 15km high, and they appear about twice as high as they're wide in my screenies. All I did was edit the RSS heightmap, left all the other PQS systems the same.

Anyway, I had some spare time so I wrote the following matlab code:

%Read the heightmap and convert to matrix for ease of use
[FileName,PathName] = uigetfile;
I=imread(strcat(PathName,FileName));
I=double(I(:,:,1))/255; 


%Magic happens
[m,n] = size(I);
I = min(0.5*rand(m,n).*I+I,1);


%Write to output
imwrite(I,'output.png');

It reads a heightmap and multiplies it with a random matrix before saving it again to a new heightmap. This promotes some individual variance between the pixels. Numbers for it are pulled out of my arse and its going to need some polishing, but it makes terrain way more interresting upclose even its current rough shape:

This is in the Appalachian mountains north of the cape.

I'm gonna go to bed now, but I'll probably try to improve the algorithm a bit over the weekend. Right now it completely ruins coastlines f.ex

Edited April 11, 2014 by Ralathon

[SpacedInvader]

Looks like there are a lot more PQS mods than the few used in the RSS config. That being said, you mention that you need to call the object (I'm guessing you mean individual CB's in this case) to find out which PQS mods it actually contains. What is the process for finding this out so that I can play with the mods for each planet? Also, is this something that will apply after implementing the generic PQS? You mentioned that the generic mod would require you to define the parts of the PQS, is this something that would have to go into the config or is that more of a dll thing?

[metaphor]

Kinda relevant to this discussion, anyone happen to know which PQS mod needs to be changed in order to lower the max terrain height of a planet and smooth out the surface? Would be useful for Bop and Gilly. Basically the opposite of what you're trying to do with Earth/Kerbin. I've tried a few and no luck so far (the deformity and heightMapDeformity parameters on a few different PQSmods don't seem to work).

edit: yay, found it, kinda, after much trial and error. Turns out it's the deformity value in PQSMod_VertexSimplexHeightAbsolute.

Edited April 11, 2014 by metaphor