[1.2] Real Solar System v12.0 Dec 8

[NathanKell]

regex (and others): I have added my post explaining (some) PQSMod values to the wiki. https://github.com/NathanKell/RealSolarSystem/wiki/PQSMods-supported-in-the-cfg

SpacedInvader: The site Ralathon mentioned is what Ralathon used, I thought, and it is hosting a cleaned-up stitched-together version of the NASA data.

My understanding is that deformity means full black = 0, full white = deformity. So if you have a deformity of 255 but your lowest luminosity is 100 and highest is 180, then the highest point will be 180m and the lowest 100m above sea level. I really, really doubt that KSP actually trawls through the entire image to grab its darkest and lightest pixels and then rescales everything.

Regarding ModifierRequirements: what this means is that for the given PQSMod to be active, the PQS quad must have those things. For example, a vertexheightmap requires that the underlying PQS supports mapping coordinates, or else how to translate between a vertex and its corresponding heightmap pixel. It does not have anything to do with extra maps you need to supply; it has to do with how PQSMods relate to each other, and you can be sure that each PQSMod applied to a stock planet does have its requirements met.

I have been somewhat busy the last few days; I will investigate the issues with Duna and try to get started rewriting my loader code.

While I do not intend to take this on, it would "only" double the memory required per map to make a version of MapSO (and corresponding PQSMod) that supported 16bit heightmaps.

Starwaster: rbray is working on volume fog.

[GamerGaius]

Well, I am stumped by a repeating graphical error I've been getting using this with Visual Enhancement. When I look straight down at Kerbin from orbit, I can see clouds, but then, when I look at the horizon, the clouds just disappear, like they are not being rendered, as if I was looking away from the planet.

I'm not sure if I should post this here, or on Visual Enhancement, but, again, I am stumped as to why I've been getting this error, and I just wonder if anyone else here has been experiencing it...

[NathanKell]

It's an issue rbray needs to fix; AFAIK we all get it with 7.x

[Starwaster]

regex (and others): I have added my post explaining (some) PQSMod values to the wiki. https://github.com/NathanKell/RealSolarSystem/wiki/PQSMods-supported-in-the-cfg

SpacedInvader: The site Ralathon mentioned is what Ralathon used, I thought, and it is hosting a cleaned-up stitched-together version of the NASA data.

My understanding is that deformity means full black = 0, full white = deformity. So if you have a deformity of 255 but your lowest luminosity is 100 and highest is 180, then the highest point will be 180m and the lowest 100m above sea level. I really, really doubt that KSP actually trawls through the entire image to grab its darkest and lightest pixels and then rescales everything.

Yes, it just generates a float based on the pixel values and multiplies by deformity. Confirmed that.

Starwaster: rbray is working on volume fog.

Awesome, can't wait! Though I am finding some bizarre issues when dropping into Jool when I configured it as described. Thinking that instead of scaling it down to 'core sized' to maybe scale it down to its metallic hydrogen layer. Seems like if the atmosphere is too deep that 'weird' thing happen such as graphical issues with AeroFX and camera gimbal lock issues. I'm also wondering if there's not some hidden PQSMod that got missed with Jool because I experienced similar things when I munged Duna's heightfield parameters and dropped below a certain altitude.

Well, I am stumped by a repeating graphical error I've been getting using this with Visual Enhancement. When I look straight down at Kerbin from orbit, I can see clouds, but then, when I look at the horizon, the clouds just disappear, like they are not being rendered, as if I was looking away from the planet.

I'm not sure if I should post this here, or on Visual Enhancement, but, again, I am stumped as to why I've been getting this error, and I just wonder if anyone else here has been experiencing it...

Pretty sure you should post there. It's probably the result of scaling Kerbin up. There might be something in VE's configs that can be adjusted to fix it, which would filter back to RSS in the form of a config file fix. (RSS has config files that alters VE behavior for cloud layers for instance)

[NathanKell]

A note: coders (and other interested folks) please respond here about making a PQSMod that supports 16bit pixels (and other nice things).

[SpacedInvader]

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.

I totally understand... I've done my fair share of coding over the years and it inevitably takes way longer than you originally thought it would. If it can't be done, then it can't be done, but I guess we'll just have to wait and see what options we have once the generic loader is available. I did finally get around to trying the output.png you derived from the MOLA data I sent over and I'm disappointed to say that even with your enhancements, the area around Valles Marineris just refuses to gain any real definition. Sure the thing is huge and the slopes are not that steep on average, but an elevation gain of 10km, even across a distance of 20km, would be noticeable and significant. Unfortunately, all I get out of it is rolling, if large, hills. I've been poking around in the in-game editor with your file as a base, but I just can't seem to get the desired result. I'm really starting to think there is something in one of the other PQS mods affecting Duna that's overriding the low-level heightmap in one way or another.

regex (and others): I have added my post explaining (some) PQSMod values to the wiki. https://github.com/NathanKell/RealSolarSystem/wiki/PQSMods-supported-in-the-cfg

SpacedInvader: The site Ralathon mentioned is what Ralathon used, I thought, and it is hosting a cleaned-up stitched-together version of the NASA data.

My understanding is that deformity means full black = 0, full white = deformity. So if you have a deformity of 255 but your lowest luminosity is 100 and highest is 180, then the highest point will be 180m and the lowest 100m above sea level. I really, really doubt that KSP actually trawls through the entire image to grab its darkest and lightest pixels and then rescales everything.

Regarding ModifierRequirements: what this means is that for the given PQSMod to be active, the PQS quad must have those things. For example, a vertexheightmap requires that the underlying PQS supports mapping coordinates, or else how to translate between a vertex and its corresponding heightmap pixel. It does not have anything to do with extra maps you need to supply; it has to do with how PQSMods relate to each other, and you can be sure that each PQSMod applied to a stock planet does have its requirements met.

I have been somewhat busy the last few days; I will investigate the issues with Duna and try to get started rewriting my loader code.

While I do not intend to take this on, it would "only" double the memory required per map to make a version of MapSO (and corresponding PQSMod) that supported 16bit heightmaps.

Starwaster: rbray is working on volume fog.

First question I have in relation to that wiki post does the VertexSimplexHeight get affected by the VertexHeightNoiseVertHeightCurve2 following them? The way you have that text written, I'm under the impression that the former defines the overall deformity imposed on the vertex multiplied by the simplex evaluations. Are those evaluations handled by other PQS mods, or is that something much simpler added as a basic noise?

As for the variation from black to white, I did go back and do a histogram stretch to use the full spectrum from 0-255 and it generally improved my output results. At this point, I really think you're right that KSP just takes the data at face value and then applies some kind of simple math to produce the PQS. After all, Squad are only really interested in high detail in a few specific areas (e.g. KSP), and they are responsible for generating the map anyway, so trying to account for a lack of variation in the input map doesn't seem like it would be high on their list of concerns.

My question for the ModifierRequirements line is less about whether all of the requirements are met for each of the stock PQS mods, but rather more about whether or not some part of the stock PQS system might be interfering with what we're trying to do because we haven't gotten around to supplying an alternative. What's got me curious is three lines I'm seeing in the in-game PQS editor that seem like they have something to do with the terrain generation, but making changes to them doesn't seem to have an effect. Those lines are:

mapFilername = Duna3_

mapFilesize = 4096

mapMaxHeight = 10500

I may be completely off base, but I have a theory that the issues I've been having getting low-level terrain features to appear might be related to something like these (though not necessarily these) which has defined something specifically for Duna, but when you try to apply Mars information to something that's affected by them, they or overriding it somehow.

I'm definitely excited to get at that new loader when its ready as I feel like it will definitely give us the tools to get all of this looking really good. I wonder if I could make a request about that if it's not going to be too hard. The Planet Factory CE has the ability to reload the config file from within the game, allowing you to make any edit and then view it in real time. I much prefer this to the in-game editor we're currently using as it allows you to modify multiple mods at once without having to rebuild before switching and also, I don't think the loading function of the in-game editor works at all. That all being said, if it's not something you're interested in doing, or if it would just be too hard or time intensive, don't worry about it.

[Starwaster]

My question for the ModifierRequirements line is less about whether all of the requirements are met for each of the stock PQS mods, but rather more about whether or not some part of the stock PQS system might be interfering with what we're trying to do because we haven't gotten around to supplying an alternative. What's got me curious is three lines I'm seeing in the in-game PQS editor that seem like they have something to do with the terrain generation, but making changes to them doesn't seem to have an effect. Those lines are:

mapFilername = Duna3_

mapFilesize = 4096

mapMaxHeight = 10500

I can't find those... what pqsmod is that in??

[SpacedInvader]

I can't find those... what pqsmod is that in??

The very first one titled "Duna".

[BahamutoD]

Maybe its just the nature of super scaled up planets, but when I was testing a Mars cargo lander, it appeared that Mars was breathing! I'm worried about attempting to build a base on the surface.

[Starwaster]

Maybe its just the nature of super scaled up planets, but when I was testing a Mars cargo lander, it appeared that Mars was breathing! I'm worried about attempting to build a base on the surface.

Get out! GET OUUUUUUT!

All Kerbals man your rockets!

Nuke the place from orbit!

Leave warning buoys!!!

Edit: Seriously I have no idea. I have never seen this thing before. Very strange.

[SlimeCrusher]

So... Ok, fixed the strange floating grass thing (Thanks Green Skull ), but now its different.

I start a new game to test it out, works perfectly! No floating grass, nothing! After that i quit to menu.

Ok, then i start ANOTHER new game on Carrer Mode (Im trying to play as the Koviets), all ok, UNTIL IT LOADS... And i get back to the beggining... I get the floating grass again... I don't know what's causing it, as i said, it works perfectly the first time, after i create another new game it just unfixes itself!

[NathanKell]

SpacedInvader:

All PQSMods are applied in order (note the "order" member in those export XMLs), with the final result of all previous mods being the input for the current one.

Example:

PQS has vertex at height 0 (obviously)

Heightmap adds 50 (total: 50)

Ridged Alt curve takes 50 as input, subtracts 5 (lowers it to 45)

Vert Heightcurve takes 45 as input, adds 15 (to 60)

SimplexAbsolute takes 60 as input, adds 5 (65)

Final height: 65.

All PQSMods are evaulated for all vertices, and they are evaluated "dumb"--that is, none actually know or depend on the existence of others; each takes its input as stateless.

Note that AFAICT, PQSMods are always additive, not multiplicative; that is, though their input is based on the current vertex displacement (and might be different for different input displacements), the *way* they further displace a vertex is by adding or subtracting height, not multiplying height.

I have not yet had a chance to check out Duna and do some tests. I will try to do so today.

Regarding rebuilding terrain during the game. I would actually have to rewrite a good chunk of RSS to handle that, since as it stands everything is done at main menu, not least because all information is loaded when the game launches (i.e. it's in config nodes) rather than my reading files. That said I understand how useful that change would be, and wil look into it.

BahamutoD: I, too, have not experienced that. Weird! Does it happen everywhere on Duna?

SlimeCrusher: It may be that KSP resets some things on return to the main menu (or that RSS doesn't play well with returning to the main menu). I have not seen such problems myself, but...for safety I suggest not doing that. Only play one save per launch of KSP.

[SpacedInvader]

Maybe its just the nature of super scaled up planets, but when I was testing a Mars cargo lander, it appeared that Mars was breathing! I'm worried about attempting to build a base on the surface.

IT'S ALIVE!!!!!

The interesting thing for me is that you don't have any vibration there at all, just the "breathing"... I wonder if these effects might be related to the specific hardware configuration rather than something in game?

SpacedInvader:

All PQSMods are applied in order (note the "order" member in those export XMLs), with the final result of all previous mods being the input for the current one.

Example:

PQS has vertex at height 0 (obviously)

Heightmap adds 50 (total: 50)

Ridged Alt curve takes 50 as input, subtracts 5 (lowers it to 45)

Vert Heightcurve takes 45 as input, adds 15 (to 60)

SimplexAbsolute takes 60 as input, adds 5 (65)

Final height: 65.

All PQSMods are evaulated for all vertices, and they are evaluated "dumb"--that is, none actually know or depend on the existence of others; each takes its input as stateless.

Note that AFAICT, PQSMods are always additive, not multiplicative; that is, though their input is based on the current vertex displacement (and might be different for different input displacements), the *way* they further displace a vertex is by adding or subtracting height, not multiplying height.

That's what I had thought, especially after they were described in that video as being "monobehavioral". I just wanted to be sure because I just can't seem to get some of these to do what I thin't they're supposed to... of course that's also assuming that what I think they are supposed to do is correct...

I have not yet had a chance to check out Duna and do some tests. I will try to do so today.

Regarding rebuilding terrain during the game. I would actually have to rewrite a good chunk of RSS to handle that, since as it stands everything is done at main menu, not least because all information is loaded when the game launches (i.e. it's in config nodes) rather than my reading files. That said I understand how useful that change would be, and wil look into it.

I appreciate that you're willing to have a look at it. Again, though, if its going to be too much work, don't worry about it because we can always make do without it. And anyway, I think the generic loader is much higher priority right now, at least in my opinion.

On a side note, I may take a couple of days off from tinkering with terrain as I've not even properly played the game once in the last three weeks while I've been doing all of this

EDIT: Is there a way to turn off atmospheric occlusion? Considering the scales we're working with, I think it would be quite helpful to not have the ground texture wash out after only a few hundred meters lateral.

Edited April 16, 2014 by SpacedInvader

[Subcidal]

Bit off topic, But does anybody have a more neptune-y looking laythe for the RSS + Planet factory config? ATM you can see the terrain of laythe and it looks rather odd. Is that the normal map?

BTW Are you suppose to load the sentar pack with that .cfg or not?

Edited April 16, 2014 by Subcidal

[braininator]

Bit off topic, But does anybody have a more neptune-y looking laythe for the RSS + Planet factory config? ATM you can see the terrain of laythe and it looks rather odd. Is that the normal map?

BTW Are you suppose to load the sentar pack with that .cfg or not?

Yes I agree... It does look a bit odd. I looked at the files and it does appear that the creator did create a height map that is completely flat for Neptune. However, he commented out the line in the config that set the height map to that. I do not know why, but uncommenting it breaks the Scaled Space for the planet. Also yes, both Sentar and Serious are supposed to be enabled when you use this pack.(if you are not using CE just sentar has to be enabled I believe.

On another topic, does anyone know if it is possible to change the color of stars in this mod/CFG file system? As PF CE edition, in the current version, does not allow you to change it, so I am curious. Thanks

[Starwaster]

IT'S ALIVE!!!!!

The interesting thing for me is that you don't have any vibration there at all, just the "breathing"... I wonder if these effects might be related to the specific hardware configuration rather than something in game?

That's what I had thought, especially after they were described in that video as being "monobehavioral". I just wanted to be sure because I just can't seem to get some of these to do what I thin't they're supposed to... of course that's also assuming that what I think they are supposed to do is correct...

I appreciate that you're willing to have a look at it. Again, though, if its going to be too much work, don't worry about it because we can always make do without it. And anyway, I think the generic loader is much higher priority right now, at least in my opinion.

On a side note, I may take a couple of days off from tinkering with terrain as I've not even properly played the game once in the last three weeks while I've been doing all of this

EDIT: Is there a way to turn off atmospheric occlusion? Considering the scales we're working with, I think it would be quite helpful to not have the ground texture wash out after only a few hundred meters lateral.

I think that's what PQSMod_AltitudeAlpha. Or is it AlphaAltitude? Something like that.

Also, I've been thinking. When testing your Mars map, you should turn OFF all PQSMods for starters. Not necessarily by disabling, but by zeroing out all deformities. Get a feel for what your baseline is.

EDIT

I've been doing some research on the various libnoise functions are and have some observations.

Start with octave and deformity. Small value changes for octaves to start with because each level of octave doubles the effect.

Use frequency sparingly because it can really make the terrain choppy and spiky.

lacunarity is VERY subtle and I don't see it having a huge impact for most of the PQSMods, but for a few of them lacunarity had larger impact than for others.

Edited April 17, 2014 by Starwaster

[SpacedInvader]

I think that's what PQSMod_AltitudeAlpha. Or is it AlphaAltitude? Something like that.

Also, I've been thinking. When testing your Mars map, you should turn OFF all PQSMods for starters. Not necessarily by disabling, but by zeroing out all deformities. Get a feel for what your baseline is.

EDIT

I've been doing some research on the various libnoise functions are and have some observations.

Start with octave and deformity. Small value changes for octaves to start with because each level of octave doubles the effect.

Use frequency sparingly because it can really make the terrain choppy and spiky.

lacunarity is VERY subtle and I don't see it having a huge impact for most of the PQSMods, but for a few of them lacunarity had larger impact than for others.

I haven't tried zeroing them out, but as far as I can tell, I think that disabling the mod should do exactly the same thing. I might try going back and doing it that way just to see if there is any difference. That being said, after some further thought, I'm starting to think that my problem might be that KSP is trying to load two different heightmaps somehow, or at least my heightmap with the stock Duna normal map. That mapFilename variable entry seems to follow the same naming convention that every other planet mod is using (i.e. Earth_color.png), while leaving the block after the underscore open for the various map components. This has me thinking that maybe the vertex mod is loading my heightmap, but then the previous Duna mod, is loading all of the rest as well, interfering with the output. I'm going to try generating a rough color and normal map from my data and then set all their names to follow convention and try directing that mod to look in the RSS config folder for the names and see if that has any effect.

[regex]

regex (and others): I have added my post explaining (some) PQSMod values to the wiki. https://github.com/NathanKell/RealSolarSystem/wiki/PQSMods-supported-in-the-cfg

Quite helpful, thank you.

[Starwaster]

I haven't tried zeroing them out, but as far as I can tell, I think that disabling the mod should do exactly the same thing. I might try going back and doing it that way just to see if there is any difference. That being said, after some further thought, I'm starting to think that my problem might be that KSP is trying to load two different heightmaps somehow, or at least my heightmap with the stock Duna normal map. That mapFilename variable entry seems to follow the same naming convention that every other planet mod is using (i.e. Earth_color.png), while leaving the block after the underscore open for the various map components. This has me thinking that maybe the vertex mod is loading my heightmap, but then the previous Duna mod, is loading all of the rest as well, interfering with the output. I'm going to try generating a rough color and normal map from my data and then set all their names to follow convention and try directing that mod to look in the RSS config folder for the names and see if that has any effect.

That should be easy to test for. Give it a flat heightfield map. All one shade.

And of course disable any deforming PQSMod

If you get anything other than a flat planet or anything that looks like Duna then you're probably right and the old map is being loaded. But if you get a flat planet then that's probably not the answer.

[SpacedInvader]

That should be easy to test for. Give it a flat heightfield map. All one shade.

And of course disable any deforming PQSMod

If you get anything other than a flat planet or anything that looks like Duna then you're probably right and the old map is being loaded. But if you get a flat planet then that's probably not the answer.

LOL, duh... and here I am spending 40 mins generating high res surface pngs from the MGS MOC data. I'll give that a try and then I guess this stuff will also come in handy when we are ready to start wrapping the planet in the proper texture...

[Starwaster]

LOL, duh... and here I am spending 40 mins generating high res surface pngs from the MGS MOC data. I'll give that a try and then I guess this stuff will also come in handy when we are ready to start wrapping the planet in the proper texture...

I was also just thinking it might come in handy to practice PQSMod editing on a flat planet to really get a good feel for how it all works.

[SpacedInvader]

Ok, well that worked to show that with everything disabled completely (except the heightmap mod, of course), a flat grey heightmap produced a near perfectly flat terrain. There was still some minor variation on a per-tile basis, but we're talking about a quarter of a meter across a single tile. This also has me fresh out of ideas at the moment... By all rights, the highest point on my globe should be just over 29km and the lowest should be at 0, but, while the high point exists correctly, a quick jaunt over to the lowest point has it sitting at 11km. I've exported the heightmap from within KSP itself to see what was going on, and even it says the low point should be at or near zero, and even that canyon I've been working on day after day should exist with nearly 10km of vertical elevation change, yet neither of these facts hold true within the game itself.

Any ideas what else might be going on?

I was also just thinking it might come in handy to practice PQSMod editing on a flat planet to really get a good feel for how it all works.

That or a checkerboard pattern to see if how the mods work with elevation changes...

[Starwaster]

Ok, well that worked to show that with everything disabled completely (except the heightmap mod, of course), a flat grey heightmap produced a near perfectly flat terrain. There was still some minor variation on a per-tile basis, but we're talking about a quarter of a meter across a single tile. This also has me fresh out of ideas at the moment... By all rights, the highest point on my globe should be just over 29km and the lowest should be at 0, but, while the high point exists correctly, a quick jaunt over to the lowest point has it sitting at 11km. I've exported the heightmap from within KSP itself to see what was going on, and even it says the low point should be at or near zero, and even that canyon I've been working on day after day should exist with nearly 10km of vertical elevation change, yet neither of these facts hold true within the game itself.

Any ideas what else might be going on?

Try setting the offset to -11000

But... then you'll also have to increase deformity.

Unless by any chance the low point on the map isn't really pixel value 0?

[SpacedInvader]

Try setting the offset to -11000

But... then you'll also have to increase deformity.

Unless by any chance the low point on the map isn't really pixel value 0?

I trimmed the histogram in photoshop so the high point is 255 and the low point is 0. I'll try -11k, but I'm almost sure it will result in a flat plain at the zero mark similar to minmus.

[SpacedInvader]

The other problem with setting the offset below zero is that when you go into negative values, you're locked into a view as if your ship is sinking into the ocean... is there a way to set negative offset for sea-level as well?

EDIT: The negative offset also did nothing to fix the elevation problems.. I've tried deformity values as high as 300km and I still can't get what should be the walls of a valley to appear from a flat plain... And no matter what I do, the lowest point on the map still sits several kilometers above zero...

EDIT: I think what bothers me the most is that its rendering some features and not others... Craters, but not valleys, mountains, but not canyons. It doesn't make sense why it would see and execute much less prominent features while leaving others to sit un-rendered...

Edited April 17, 2014 by SpacedInvader