[1.2] Real Solar System v12.0 Dec 8

[manuelasa1999]

have you try'ed resizing EarthNRM to 4096x2048 ? And are you using RT2 ?

Thank you now it works!!!!!

[Mecripp]

Thank you now it works!!!!!

If you are still having ram problem check you skybox pic and see what there set at alot are 4096x4096 you can change them to 2048x2048 and save 10% on ram.

[SpacedInvader]

So I think I've finally got Mercury to a decent place, or at least it's presentable and will need some refining in the future.

Javascript is disabled. View full album

I had to remove the coloration because it was entirely too patchy from all of the different lighting conditions compiled to make it to even try to make it look natural. That said, I do plan on revisiting this a little more later now that I've got a nice grayscale image and a good idea of what the coloration of the surface should be. As for the height map, I pulled a displacement map from the surface image and then gave it some variation with some elevation multipliers based off of the incomplete satellite data. The end result, unfortunately, is that the surface features are a somewhat muddled, though they do exist to a decent degree if you know where to look, but then again, Mercury is quite smooth to begin with compared to the other planets, so this may have been the case even if we had full data. Again, that being said, once I've had a chance to work on the other planets, I'll probably be revisiting this to see if I can figure out a better process that retains some more detail. I'll also want to give it the once over with the PQS to enhance the surface appearance a little.

Anyway, this just leaves Earth, which should be the easiest of them all, and a little touch up to the Mars color image I'm using, and then I'll be ready to package all of this up for release.

@Ralathon: If you're still following this at all, what are the chances you could write a script that can identify discrete low level features (craters / canyons) from an image or height map based on their color or shape and then enhance the elevation around them?

Edited April 25, 2014 by SpacedInvader

[Kimaera026]

Am I the only one here or other people are also getting some weird orbital values?

I did a fresh install of RSS v6, from v5 on .23, to v6 on .23.5 and noticed (after admiring for hours at the beauty of earth *_*) that rotational period is now 3days 5 hours, a year is approx 400+ days, and going to the moon on a conventional Apollo style burn takes 10-16 days rather than 3+

What am I doing wrong? Any suggestion?

---------------------------------

ooops! never mind! I just learnt that .23.5 brings an option in the settings.cfg to toggle Kerbin/Real time scale (6h/24h)

Very handy, now that I know it's an actual feature, rather than a bug. ahahah

Edited April 25, 2014 by Kimaera026

[NathanKell]

regex: cool!

SpacedInvader: only way I can think of (to generate a heightmap from a 2D image) is to use software to convert it to a normal map (I think I've seen tools that claim to derive normal maps from diffuse maps' shading), and from there to a bump map.

So...much like what you're doing (and is failing), sorry.

White Owl: Nope, that's KerbTown. regex is making a GUI for the support for moving KSC that's already in RSS.

AndreyATGB: I've been waiting on (1) fixing the wrapping issue (I need to design a caching mechanism) and (2) SpacedInvader's updated maps. However, Mars will need some work such that the land color matches the image of Mars that will be used for scaledspace (woo, *another* texture since IIRC Duna relies on a vertex color map rather than landclasses)

You can actually get the latest working RSS dll from Better Atmospheres v4

So...given the number of people who are having problems with 8192 textures, I'm considernig only supplying 4096s, and having the 8192s as an optional download. Thoughts?

[Mecripp]

@Nathankell what all can change the terrain playing RSS kerbal size but the state of Florida looks like Islands and on the textures at 8192 textures just eat alot of ram resize down to 4096 lets you pretty much added 1 more mod lol as we all like mods.

EDIT I added the rescale RSS to Kerbal size but the land don't look right from the launch pad from orbit looks good.

So is something in the rescale file changing the way the land looks up close ?

Edited April 26, 2014 by Mecripp2

[NathanKell]

Sorry, I can't understand what you mean. Can you restate (maybe with punctuation)?

(Not trying to be snarky, btw, I genuinely can't follow that.)

[SpacedInvader]

regex: cool!

SpacedInvader: only way I can think of (to generate a heightmap from a 2D image) is to use software to convert it to a normal map (I think I've seen tools that claim to derive normal maps from diffuse maps' shading), and from there to a bump map.

So...much like what you're doing (and is failing), sorry.

White Owl: Nope, that's KerbTown. regex is making a GUI for the support for moving KSC that's already in RSS.

AndreyATGB: I've been waiting on (1) fixing the wrapping issue (I need to design a caching mechanism) and (2) SpacedInvader's updated maps. However, Mars will need some work such that the land color matches the image of Mars that will be used for scaledspace (woo, *another* texture since IIRC Duna relies on a vertex color map rather than landclasses)

You can actually get the latest working RSS dll from Better Atmospheres v4

So...given the number of people who are having problems with 8192 textures, I'm considernig only supplying 4096s, and having the 8192s as an optional download. Thoughts?

As you can see, I've had some success using the displacement map method, but because it's based on coloration and not elevation, that means that every little detail gets treated as height information (note the impact ejecta lines being treated as valleys) resulting in a very busy terrain surface that must be toned down quite a bit or else it ends up looking like a brain-coral. This also means that, thanks to the composition of the planet, high points end up with the same coloration as impact sites, meaning they either all have to be craters or all have to be hills. I was thinking for a little while about mirroring the half of the planet we do have a digital elevation model for and then going through some contortions in shuffling and blending to make it look like unique terrain across the whole surface, but abandoned that idea because of its departure from the real thing when I have a really good full surface mosaic for the color map. That being said, I may revisit that idea in the next few days / weeks to see if it produces something realistic enough to pass for Mercury at least, while at the same time improving the surface appearance to a worthwhile degree.

As for the issues with the 8192 maps, they really seem to be system specific as only a few people seem to be having the issue. That being said, I thought the plan all along was to package the 4096 maps and then offer the 8192 maps as an optional upgrade? I've done some testing with the reduced maps and while they do degrade the surface somewhat and you can more clearly see the tiling, I think they'll do fine for most people. Also, don't forget that once we get at the generic PQS loader (how's that coming along btw?) we should be able to improve the appearance of the quads below the height resolution. The only area where I might be concerned is the color maps. This is mostly because I've been using photoreal mosaics and I'm not sure how well they will hold up as the resolution decreases.

On a different note, since I'm just about ready to put this thing out into the wild, how would you recommend I go about the release? I get the impression from your response to Andrey that you might be thinking about rolling at least the lower resolution maps into the RSS package in some way, in which case, would I just be sending them off to you to be put on Github? Or should I just put them up myself and then go from there?

[SpacedInvader]

So I found something interesting when I started looking at Earth elevation data. The height map you used includes ocean bottom terrain (deepest point ~10.911km), but you only offset the height map to -2150m. Then, you've got the deformity set at 17300m, which is not quite high enough to account for the total distance from the Earth's lowest point (Challenger deep ~10.911 below the surface) to the highest point (Everest ~8850m). Anyway correcting all of this to an offset of -10.911km and a deformity of 19.761km increased the available terrain above the surface by about 2500m, increasing terrain definition, especially at high elevations and putting KSC in a 2.5km hole in the ground. That all being said, I'm downloading elevation data right now that ignores the ocean depths , giving more definition to the land. I'm not 100% sure just yet how to actually handle the oceans at this point, though I'm thinking about just giving the whole map a small offset (<500m) on output from the mapping program to ensure the minimum of vertical space is eaten up by a part of the world we'll never see, at least in KSP...

EDIT: Correcting for subsurface elevation seems to have killed the ocean some how. I'll have to look into what exactly is going on there.

EDIT: Nevermind about the ocean, I'm just an idiot... I put -10.911 rather than -10911.

Edited April 26, 2014 by SpacedInvader

[Whirligig Girl]

Error-----

Edited April 26, 2014 by GregroxMun

[SpacedInvader]

Just a little update... Apparently the ocean doesn't respond the way I thought I would when you shift the land around it. I figured that giving a 500m drop off at the coast and then giving the height map a -500 offset would simply shift the land down while the ocean elevation stayed the same, instead, the ocean ended up at -500 and KSC at 53 where it always was. The result is that I have an ocean at the bottom of a 500m drop which is full of "islands" because its only about 50m deep at best and the PQS is popping up through the water. Anyway, that being said, I found that my height map did indeed enhance definition, while on the other hand, I think your (Nathan's) color map works best, as the one I've got, at least at this point, would need some work to edit out the ocean since it's just a single tone blue with darker areas near the shore. I still thought I'd share it anyway (don't mind the crazy exaggerated normals... I need to learn not to over-do them):

Speaking of normals, what settings do you usually use? I've been clinging to 50 and that still seems high in some cases, but not others.

[ThorBeorn]

That is one beautiful Earth you have got there SpaceInvader.

[Nemrav]

I think, especially now with asteroids some changes need to be made :

1 : for all the major moons that are basically asteroids, make then asteroids with giant settings (nearly impossible to move) and same goes to vesta.

2 : if using planet factory, then make inaccessible one of the real moons that is a ellipsoid.

3 : move the asteroid generation area into where the asteroid belt is, and copy paste the generator to make it complete.... also disable the areas of the script that make the asteroids encounter with Kerbin....

BUT FOR NOW ONE OF BEST MODS EVAR

edit : yup came across starstrider's mod, seems that you can set minimum and maximum sizes for the asteroids, maybe there is a way to set minimum mass....

or the best alternate to the current configs would be for somebody to create the remaining solar system planet(oids) and moons using planetfactory CE, if not already, then we wouldn't need a star as sedna

Edited April 26, 2014 by Nemrav

[Whirligig Girl]

Here is an updated version of metaphor's planet factory config. Includes textures for each planet and in some cases height maps. Currently, no new Normal Maps are included.

Textures and Config:

https://www.dropbox.com/s/0pryhc4wf7lve3w/RSS_PlanetFactory_Textures.zip

Cloud Layers (download both and place in BoulderCo/Clouds):

https://www.dropbox.com/s/cs5paqlzrk9zhvh/cloudLayers.cfg

https://www.dropbox.com/s/xqs73bpocz4a1lr/cloudLayers-PlanetFactory.cfg

Body list:

Mercury (Moho)

Venus (Eve)

Earth (Kerbin)

Moon (Mun)

Mars (Duna)

Phobos (Bop)

Deimos (Gilly)

4 Vesta (Inaccessable)

Ceres (Minmus)

Jupiter (Jool)

Io (Pol)

Europe (Eeloo)

Ganymede (Tylo)

Callisto (Ike)

Saturn (Sentar)

Enceladus (Vall)

Titan (Erin)

Iapetus (Ringle)

Uranus (Skelton)

Miranda (Ablate)

Titania (Thud)

Neptune (Laythe)

Triton (Ascension)

Pluto (Dres)

Charon (Pock)

Eris (Joker)

Sedna (Serious)

I'm getting clouds clipping with the ground on Earth and Mars. Is there a fix? Also is there a fix for the terrain features on Uranus and Laythe?

[Starwaster]

I'm getting clouds clipping with the ground on Earth and Mars. Is there a fix? Also is there a fix for the terrain features on Uranus and Laythe?

I can't speak as to Earth since I try to spend as little time there as possible,, but those aren't clouds at ground level on Mars. Those are dust storms simulated by volumetric clouds.

[NathanKell]

SpacedInvader: I'm currently dealing with the caching of meshes; generic loader is on hold for a bit, sorry.

For release, if you want to just upload the files I'll pull them into the RSS repo (and keep the alternate versions there too, as is done now for Earth's normal map). I was definitely planning to release them with RSS if you're cool with that.

The reason for the heightmap offset etc is as follows: It was my opinion that people probably cared considerably less about accuracy under water than they did for accuracy above water; therefore I decided that, instead of use 55% of the heightmap's height resolution for stuff underwater (i.e. 11km worth of 20km total displacement) and only 9km for above water, I would set my image levels such that only about 30 of 255 (IIRC) shades are used for below water displacement (thus leading to vastly-shallower oceans, but oh well) and the remaining 225 shades for the above-ground terrain, leading to an accuracy of 40m/shade rather than 78m/shade for above-ground terrain.

So basically I already did what you were considering, just allocated a bit more color-pallete-space to the below-water terrain. The deformation level was set to maintain approximately-correct sealevel.

Not sure what you mean by "what settings do {I} use" for normals...

Nemrav:

1. Asteroids are actually just vessels, not celestial bodies. It would not, IMO, be the best idea to use them for moons. KSP asteroids are smaller (and have a density approaching LH2!) than real asteroids, anyway.

2. I do eventually plan to support all major bodies in the solar system; adding new planets has taken a back seat to fixing stuff nearer-to-hand though.

3. RSS will depend on Starstrider42's Custom Asteroids mod.

And thanks. :]

GregorxMun: Alt-N to load cloud editor; raise altitude of cloud layer; apply and save. (This is because of Z-fighting and is a known issue. rbray is working on it). Also the clouds have an issue where the 2D cloud layer is rendered much lower than it should be on RSS; you'll need to raise it to at least 10km to get something reasonable even up close, let alone for z-fighting issues. rbray is also working on that.

[Guest]

I think, especially now with asteroids some changes need to be made :

1 : for all the major moons that are basically asteroids, make then asteroids with giant settings (nearly impossible to move) and same goes to vesta.

2 : if using planet factory, then make inaccessible one of the real moons that is a ellipsoid.

3 : move the asteroid generation area into where the asteroid belt is, and copy paste the generator to make it complete.... also disable the areas of the script that make the asteroids encounter with Kerbin....

BUT FOR NOW ONE OF BEST MODS EVAR

making moons asteroids, might be abit much. Better to have them stay on rails. but i do like the idea of moving the asteroids generation area (or better yet the creation of an asteroids belt with in game asteroids, but that might be ALOT of asteroids, more than most people can handle within ram limit considering the number of mods in use for RSS/RO/RPL

[Fleet]

I am having a weird issue with the high res moon maps where the moon is being lit from 90 degrees off from where the sun is. I have poked around in the configs but could not find any tweaks that helped. any ideas?

EDIT: BTW all other planets and moons are fine its just the moon being wonky.

[pingopete]

Hey Nathan, small problem here. Just started a new campaign with remote tech and can't get any signal as I don't have a relay up and the real earth KSC is at a different latitude.

[Guest]

Hey Nathan, small problem here. Just started a new campaign with remote tech and can't get any signal as I don't have a relay up and the real earth KSC is at a different latitude.

http://i.imgur.com/D9sjLOP.jpg

open remote tech2's settings cfg and match its ground staton location to the location of KSC as in real solar system's cfg. (longitude and latitude)

this will make the KSC and remote tech2 control station the same location

[pingopete]

open remote tech2's settings cfg and match its ground staton location to the location of KSC as in real solar system's cfg. (longitude and latitude)

this will make the KSC and remote tech2 control station the same location

ok thanks, will try now

[Mecripp]

ok thanks, will try now

Should look something like this but, I play 1/10 size

ConsumptionMultiplier = 1

RangeMultiplier = 1

ActiveVesselGuid = 35b89a0d664c43c6bec8d0840afc97b2

SpeedOfLight = 3E+08

MapFilter = Omni, Dish, Planet, Path

EnableSignalDelay = True

RangeModelType = Standard

MultipleAntennaMultiplier = 1.0

ThrottleTimeWarp = False

DishConnectionColor = 0.9960784,0.7019608,0.03137255,1

OmniConnectionColor = 0.5529412,0.5176471,0.4078431,1

ActiveConnectionColor = 0.6588235,1,0.01568628,1

GroundStations

{

STATION

{

Name = Mission Control

Latitude = 28.608389

Longitude = -80.604333

Height = 75

Body = 1

Antennas

{

ANTENNA

{

Omni = 7.5E+07

}

}

}

}

[SpacedInvader]

SpacedInvader: I'm currently dealing with the caching of meshes; generic loader is on hold for a bit, sorry.

For release, if you want to just upload the files I'll pull them into the RSS repo (and keep the alternate versions there too, as is done now for Earth's normal map). I was definitely planning to release them with RSS if you're cool with that.

The reason for the heightmap offset etc is as follows: It was my opinion that people probably cared considerably less about accuracy under water than they did for accuracy above water; therefore I decided that, instead of use 55% of the heightmap's height resolution for stuff underwater (i.e. 11km worth of 20km total displacement) and only 9km for above water, I would set my image levels such that only about 30 of 255 (IIRC) shades are used for below water displacement (thus leading to vastly-shallower oceans, but oh well) and the remaining 225 shades for the above-ground terrain, leading to an accuracy of 40m/shade rather than 78m/shade for above-ground terrain.

So basically I already did what you were considering, just allocated a bit more color-pallete-space to the below-water terrain. The deformation level was set to maintain approximately-correct sealevel.

Not sure what you mean by "what settings do {I} use" for normals...

I'm totally cool with that

As for the normal map, I'm mostly curious about what scale setting to use. I've been using 50, which often turns out pretty nice, but it also clearly exaggerates the terrain quite a bit when in reality the surface looks almost flat from orbit.

I did some poking around with both maps to see what differences there were between the two, and there are some that are noticeable, but that being said, I found an interesting effect where, because there were more shades available, and thus more detail, certain areas lost their shape somewhat. Whatever the case, I think it doesn't make sense at this point to go for the alternate height map as there just isn't enough difference between the two to make the change worthwhile, after all, aside from gentler terrain by the coast of Florida, you'd have to explore quite a bit to get the benefit of 33m/shade terrain vs. 40m/shade terrain.

I am having a weird issue with the high res moon maps where the moon is being lit from 90 degrees off from where the sun is. I have poked around in the configs but could not find any tweaks that helped. any ideas?

EDIT: BTW all other planets and moons are fine its just the moon being wonky.

This is because we haven't released the updated normal maps to go with the new color maps. They should be out shortly though.

EDIT: @Nathan: I'm just trying a couple last minute touch ups to the mars color map to get rid of unwanted reflection and then I'll pack it all up and upload. I should have it up today before 5:30MST, but if not I'll put it up shortly after I get home from work around 1am.

Edited April 26, 2014 by SpacedInvader

[jsimmons]

Hello.

I just started the process of updating my kerbol 10x system config file. The only thing left is to handle the atmosphere but I notice you changed it from the Karman line to some new number. Where did you get that number from? I like to use a formula to properly scale the atmosphere properties. I noticed also you have a atmosphereMultiplier value. What does that do? Thanks for your help.

[Starwaster]

Hello.

I just started the process of updating my kerbol 10x system config file. The only thing left is to handle the atmosphere but I notice you changed it from the Karman line to some new number. Where did you get that number from? I like to use a formula to properly scale the atmosphere properties. I noticed also you have a atmosphereMultiplier value. What does that do? Thanks for your help.

The cutoff point was never the Karman line. The original pressureCurve data came from a spreadsheet I devised to automatically create pressureCurve data in a format that I could easily cut and paste into the config file. The Karman line is too abrupt a transition to go from atmosphere to vacuum. At that altitude it's still too dense and we wanted an atmosphere that faded out into space more gradually than that. It was a little further out originally but Nathan asked me to cut it to 180 so that players could go off-rails at 100nmi, which was the parking orbit used by Apollo astronauts on their way to the moon.

Edit: (I'm not even sure the Karman line actually entered into our conversations though I did calculate it on my spreadsheet for reference purposes to compare to the final cutoff)

Edit #2: I think what's in there currently was computed by Metaphor based on more current data than what I used. At least on the github repository, not sure if that's in the current download?

Edited April 27, 2014 by Starwaster