[1.2] Real Solar System v12.0 Dec 8

[regex]

I have an implementation question regarding the KSC repositioning code. Currently it loads the launch sites from the RealSolarSystem.cfg configuration file, but I'm wondering if it might be better to have its own configuration file.

Something else to consider is if it should be optional. I can always put a flag into RealSolarSystemSettings.cfg.

[metaphor]

So I was thinking about making an addon to RSS that can scale the system by any specified number, basically just put in one value and it would calculate all the physical and orbital parameters for the planets to scale. But it would have to contain some code and I'm not really sure where to start with that.

I found some pretty good atmospheric data for the planets as a function of height on some NASA webpages like [this one](http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20070032693.pdf) that contains atmospheric density as a function of height (the scale height is not constant with height). It would be relatively easy to make some interpolated atmospheres for the RSS config file with this data. What's the maximum number of entries an atmosphereCurve can have? And does the temperatureCurve work?

[Starwaster]

I have an implementation question regarding the KSC repositioning code. Currently it loads the launch sites from the RealSolarSystem.cfg configuration file, but I'm wondering if it might be better to have its own configuration file.

Something else to consider is if it should be optional. I can always put a flag into RealSolarSystemSettings.cfg.

Depends on if you want it to always be able to access all of RSS's launch sites. If you split things up then that means you have to always keep them in sync. It will be one more thing to have to keep track of.

So I was thinking about making an addon to RSS that can scale the system by any specified number, basically just put in one value and it would calculate all the physical and orbital parameters for the planets to scale. But it would have to contain some code and I'm not really sure where to start with that.

I found some pretty good atmospheric data for the planets as a function of height on some NASA webpages like [this one](http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20070032693.pdf) that contains atmospheric density as a function of height (the scale height is not constant with height). It would be relatively easy to make some interpolated atmospheres for the RSS config file with this data. What's the maximum number of entries an atmosphereCurve can have? And does the temperatureCurve work?

I suspect you'll hit a practical limit before you hit a hard limit. AnimationCurve is an array and it grows dynamically in size as you add to it. If there's a limit it would maybe be Int32.MaxValue number of entries or 2GB worth of data in the array.

Edit: Rather than spam the pressureCurve with keys, we really need to figure out how to do tangents right. Do altitude keys only for important areas (such as first 10 km on Earth/Kerbin) and use interpolation for the rest.

[regex]

Depends on if you want it to always be able to access all of RSS's launch sites. If you split things up then that means you have to always keep them in sync. It will be one more thing to have to keep track of.

That is an excellent point. I'll keep them in the RealSolarSystem.cfg so that they're specific to each resize configuration.

[NathanKell]

Fleet: grab the ones I uploaded to GitHub, here. The MoonNRM.png should be correct.

SpacedInvader: great!

I'm sorry, I still don't follow what you mean for "scale" for normal maps. Is that something in your map generation tool? I've only used premade planet normal maps or hand-edited them, I haven't used a normal map creation program to know what you mean by scale.

No worries; I've spent time working on the mesh caching; ready to test now.

jsimmons: the fact that Kerbin's atmosphere ended at approximately the Karman line was an artifact of the fact that to roughly (only very roughly) match the pressure curve of Earth's atmosphere in KSP's legacy (single-scaleheight exponential falloff) atmosphere model we used a scale height of 7.5km, which meant (again due to the weirdness of KSP's legacy atmosphere model) things cut out at approximatley 104km (technically when e^(-alt/scaleheight) < 1E-6, or ~13.8 * scaleheight). That cutoff (~13.8 * scaleheight) is true for any planet using the legacy atmosphere model (i.e. Duna, whose 11.1km scale height led to an atmosphere cutoff of 154km, or stock Kerbin whose 5km scale height means 69km or so).

Earth's atmosphere now ends at 180km because we switched to modeling atmospheres with KSP's new way of modeling them, pressureCurves (first with Starwaster's curve, in RSS v6, and soon eggrobin's updated curves). I selected 180km because that allows two things: first, it means that the transition from 0 pressure is gradual enough that even on an interplanetary trajectory you won't be hit with a "wall" of drag (as you would be in the old days), and second, that the 185km (100 nautical mile) "reference" orbit used for measuring the payload of launchers (and Apollo's parking orbit) would still be warpable.

regex: Given that since I have to include cached meshes for scaledspace RSS v7 will depend more on just RealSolarSystem.cfg for each solar system, I think it makes reasonable sense to offload launch site settings into a separate file. Certainly it makes sharing it easier! (I want people to be able to swap launch site configs; I don't want that to depend on their version of RSS, or have the chance of breaking the whole RealSolarSystem.cfg).

That said Starwaster has a reasonable argument in opposition, and it's *also* true that maybe we *don't* want people using *different* RSS.cfgs to be able to swap launch sites without switching system cfgs (and then have that break in-game).

metaphor: I've played with 400 in the curve for Earth and had no trouble, so at least that. Yes, temperatureCurve works (check the current source). You might want to touch base with eggrobin, who has written Mathematica code to generate pressureCurves and temperatureCurves with correct tangents based on that sort of input.

Your addon sounds quite cool!

Starwaster: the current cfg in github has curves by eggrobin with proper tangents, with quite insane accuracy compared to the ISA (on the order of "a pascal or two at sea level" relative error IIRC).

[Starwaster]

Fleet: grab the ones I uploaded to GitHub, here. The MoonNRM.png should be correct.

Starwaster: the current cfg in github has curves by eggrobin with proper tangents, with quite insane accuracy compared to the ISA (on the order of "a pascal or two at sea level" relative error IIRC).

You know, for some reason I was thinking it was Metaphor.... creeping senilities strikes again.

[Green Skull]

Not sure if anyone has done it but am working on a real skybox with hopefully stars in the correct places

[RaccoonTOF]

Wait...you mean...I might be able to use an ACTUAL in-game sextant for celestial navigation on my earthside vehicles? Oh boy, this just got SERIOUS... (I find particular humour in this because in real life...I live on a 36' sailboat, and am shortly getting a new (replacement) sextant for real-world celestial navigation use as a backup to the GPS )

[AndreyATGB]

There's already a bunch of skyboxes from NASA images of the sky. I've been using one for a while, I don't know if it's accurate as in placement of stars but it's definitely our galaxy and it's much higher res than the blurry stock one.

[SpacedInvader]

Fleet: grab the ones I uploaded to GitHub, here. The MoonNRM.png should be correct.

SpacedInvader: great!

I'm sorry, I still don't follow what you mean for "scale" for normal maps. Is that something in your map generation tool? I've only used premade planet normal maps or hand-edited them, I haven't used a normal map creation program to know what you mean by scale.

No worries; I've spent time working on the mesh caching; ready to test now.

This is the scale setting I'm talking about:

That being said, I got home quite late last night, and didn't get as much time as I though I would. I've run into a couple of issues with the lower resolution color maps, mostly that they look pretty junky and Venus refuses to be anything but black. I think this is because they are all photos up to this point (not Venus, I guess), and downsizing them too much makes them look out of focus. I also made the mistake of redoing all of the normal maps with a much lower scale setting which I thought would make them look more realistic, but instead they came out looking plain flat. Fixing the normals will be easy, though I'm not going to be able to get to them for a few hours yet, but I'm not really sure what to do about the color maps. I know we want to limit the total size, so I'll try rescaling them to 4096 to see if that is a happy medium between 128MB at 8096 and really fuzzy at 2048, but if that doesn't work, I'm not sure trying to sharpen the images is going to be a good idea...

Edited April 27, 2014 by SpacedInvader

[Starwaster]

This is the scale setting I'm talking about:

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

That being said, I got home quite late last night, and didn't get as much time as I though I would. I've run into a couple of issues with the lower resolution color maps, mostly that they look pretty junky and Venus refuses to be anything but black. I think this is because they are all photos up to this point (not Venus, I guess), and downsizing them too much makes them look out of focus. I also made the mistake of redoing all of the normal maps with a much lower scale setting which I thought would make them look more realistic, but instead they came out looking plain flat. Fixing the normals will be easy, though I'm not going to be able to get to them for a few hours yet, but I'm not really sure what to do about the color maps. I know we want to limit the total size, so I'll try rescaling them to 4096 to see if that is a happy medium between 128MB at 8096 and really fuzzy at 2048, but if that doesn't work, I'm not sure trying to sharpen the images is going to be a good idea...

Well, it is mostly volcanic rock after all

[Kerbal01]

sorry... They looked like they had made the parts themselves. I'd still be interested in the textures if they have them.

Anyone??????

[blux_]

The GitHub Page for the Hi-Res earth texture seems to be down. Is there a mirror anywhere?

[regex]

Anyone??????

What are you going on about? If I'm reading NathanKell's post right, the textures are standard StretchySRB/Procedural Parts, blackheart's (which has its own release thread), and some personal textures that you really should be PM'ing the author for instead of asking again in this thread.

[jsimmons]

Thanks Starwaster for responding. So it was raw data instead of a formula to compute the atomspheric properties. I will look into a way to compute the atomspheric properties for the kerbal rescale.

[NathanKell]

Starwaster: metaphor also did a pressurecurve as an interim fix. That might be why.

Green Skull: cool!

RaccoonTOF: Hah! It's like when KCreator kept talking about a "star fix" for the planet tools. Y u no haz sextant? Oh, you mean light? Bah.

Which 36? You have my interest

SpacedInvader: Ah! Yeah, I've not used that to generate normals for RSS.

Regarding size: Mac users can't use anything beyond 4096 anyway (for diffuse/normal; height at 8192 is OK IIRC because it's never displayed) so we *have8 to have a 4096 option at least for them. Even Earth with 2048x1024 normals is acceptable, so I would suggest:

Earth/Mars/Venus: 4096 color, 2048 normal

Moon (and other moon-size things): 2048 color, 2048 normal

The hirez versions would be 8192 for terrestials, 4096 for the Moon (8192? Maybe worth it), and similar rez normals.

For the Moon, does a 4096 heightmap provide sufficient resolution? That's what I've been using so far (especially since except for converting raw DEM data the 5760-wide Kaguya map was the best I could find, and that needs to be made power-of-2).

DarthVader: I already explained where the textures are. Look at the StretchySRB OP, it has links to all textures used. I don't think it uses any unreleased textures; what I referred to was that ferram probably tweaked the *stats* of some things for that launch.

blux_: Ack, sorry! Reorganized the repo, forgot to fix the link. Fixed.

jsimmons: your best bet is to go back to using legacyAtmosphere with a scaleHeight of 7.5 for the earth (i.e. don't change the pre-V6 atmosphere of earth-sized Kerbin). That seems a reasonable increase from the 69km atmosphere of Kerbin-scale Kerbin.

Since apparently in the Kerbal universe atmospheres are much "cleaner" mathematically and feature perfect uniform exponential decay

[SpacedInvader]

Well, it is mostly volcanic rock after all

LOL... Well, black rock would be nice, but I was getting a perfectly black sphere a la the singularity drive of the event horizon. That being said, I figured out that the issue was that when I was trying to down sample the Venus color map, all of the color data was being overwritten by the alpha channel's black.

SpacedInvader: Ah! Yeah, I've not used that to generate normals for RSS.

Regarding size: Mac users can't use anything beyond 4096 anyway (for diffuse/normal; height at 8192 is OK IIRC because it's never displayed) so we *have8 to have a 4096 option at least for them. Even Earth with 2048x1024 normals is acceptable, so I would suggest:

Earth/Mars/Venus: 4096 color, 2048 normal

Moon (and other moon-size things): 2048 color, 2048 normal

The hirez versions would be 8192 for terrestials, 4096 for the Moon (8192? Maybe worth it), and similar rez normals.

For the Moon, does a 4096 heightmap provide sufficient resolution? That's what I've been using so far (especially since except for converting raw DEM data the 5760-wide Kaguya map was the best I could find, and that needs to be made power-of-2).

Ok, so here's where I stand right now... I have all of the 8192 resolution maps ready to go (and yes the Moon is definitely worthy of that resolution with the color map I've got and I think 4096 is sufficient, but 8192 is still better). I've tried using everything with the small 2048 normal maps and, while they do the job, they don't do it that great, leaving things blocky and pixelated. That being said, this may be an artifact of the fact that I simply down sampled the 8192 normals to get the 2048. Right now I'm creating new normals based off of the 4096 height maps to see if the smaller drop in resolution results in a better visual effect. That all being said, I'm thinking about just releasing three packs now, one with everything 8192, except maybe normals, at a whopping 1.16GB (unpacked), one with everything small (4096 height, 2048 everything else), and one in the middle with 4096 height and color, and 2048 normal. There are some exceptions to this, for example, Venus is blurry on purpose, being raging clouds anyway, so I'll probably only offer 2048 for color and maybe even 1024 normal since all it is is a grey surface anyway.

My reasoning here is that the 8192 color and normal maps together look just fantastic, but as I said above, they are very memory heavy, so I want them available for anyone who's system can handle them, or if they want to pull in one of them for a specific planet. On the other hand, the 2048 normal and color look pretty junky, but also save a huge amount on memory, so if that's what people need, I want it available, and then of course if Mac users can only handle 4096, then I want the best they can handle to be available.

Now with all that being said, I'm not going to be able to do any more work on this tonight as I have some important homework to finish before tomorrow morning that I've been putting on the back burner to try and roll this out ASAP. That being said, would you rather just wait until tomorrow sometime for me to finish the third pack and the normals for the small pack, or would you rather me upload and PM you a link for the stuff I've got right now so we can get something up and running now rather than later?

EDIT: Is there any chance we could convert the higher resolution to a format like DXT to make their size more manageable?

Edited April 27, 2014 by SpacedInvader

[NathanKell]

SpacedInvader: That sounds good; and unless Github gets pissy at me and I need to move to sourceforge it should all be good. As long as no file is >100MB, which seems likely (SuperPNG->most optimized PNG export should ensure an 8192 normal is *just* under 100MB...I trust.)

With this one might as you suggest use lowres maps mostly, and swap to hires for the bodies one plans to visit that play session, further lowering memory.

I haven't licked the scaledspace caching issue yet (I export fine, but import seems broken)...so that delay is fine; I would, however, like to release v6.1 for now, I think, so that it can come out in concert with RPL MS19b and RO v5. So I'd say PM me what you have and we can launch a "teaser" pack; but as for the others, we can shove off RSS v7 for a few days. Homework obviously comes first!

SuperPNG in most-compressed mode is about the best we can do without going lossy (jpg). KSP does not read DXT directly (although most textures, on load, do get converted to DXT...). So it's png or jpg.

(Note that SuperPNG can achieve a far higher compression than PS's built-in PNG export)

Normal maps are often left uncompressed in memory KSP for quality reasons, but I'm adding a new flag to RealSolarSystem.cfg to allow compression if desired; a user may decide on their own whether the 75% savings in memory is worth the quality reduction.

[RaccoonTOF]

RE: height/normal maps. I tried resizing them down to 4096 and leaving the normal map at 8192 and I ended up having the entire planet surface for earth disappear - along with KSC. On loading, I would just be left staring THROUGH the planet at the sun. For some reason I was only able to make a resize work when they were all the same size - so right now I'm using all of them at 4096 and it seems to work fine, with very few noticeable graphical difference.

As for the boat: she's a 1975 Cheoy Lee/Luders 36 ketch.

Lots more pics on my FB album if you are interested: https://www.facebook.com/media/set/?set=a.10151392717552746.1073741826.529577745&type=1&l=a5e133bd88

[SpacedInvader]

SpacedInvader: That sounds good; and unless Github gets pissy at me and I need to move to sourceforge it should all be good. As long as no file is >100MB, which seems likely (SuperPNG->most optimized PNG export should ensure an 8192 normal is *just* under 100MB...I trust.)

With this one might as you suggest use lowres maps mostly, and swap to hires for the bodies one plans to visit that play session, further lowering memory.

I haven't licked the scaledspace caching issue yet (I export fine, but import seems broken)...so that delay is fine; I would, however, like to release v6.1 for now, I think, so that it can come out in concert with RPL MS19b and RO v5. So I'd say PM me what you have and we can launch a "teaser" pack; but as for the others, we can shove off RSS v7 for a few days. Homework obviously comes first!

SuperPNG in most-compressed mode is about the best we can do without going lossy (jpg). KSP does not read DXT directly (although most textures, on load, do get converted to DXT...). So it's png or jpg.

(Note that SuperPNG can achieve a far higher compression than PS's built-in PNG export)

Normal maps are often left uncompressed in memory KSP for quality reasons, but I'm adding a new flag to RealSolarSystem.cfg to allow compression if desired; a user may decide on their own whether the 75% savings in memory is worth the quality reduction.

Ok, right now I've had to go to work on top of everything else. I'll upload and send you the link as soon as I get home, so you'll have it either late tonight or first thing in the morning depending on your schedule.

[NathanKell]

RaccoonTOF: That's strange about maps. I see no reason why that might be, unless for some reason your resizes did something to the channel count? At least you got it working.

And...she's quite handsome! Will check the album. Sailing is another giant passion of mine (my family has a (v1.0) Cal 25 we sail each summer).

SpacedInvader: no worries. :]

[regex]

Here's the latest for the KSC Switcher feature. This video also details just how slow my laptop gets with the broadcaster software running... E: It also apparently details how I forgot that my laptop has a built-in microphone

You can have as many launch sites as you want; I put in over 30 in an earlier test. They are stored in a LaunchSites node under the top level REALSOLARSYSTEM node in your planet config file. The "Launch Sites" button will not show if you have zero launch sites defined. Note that you still do need the initial PQSCity definition for Kerbin in the planet node proper, otherwise you'll have to figure out where the tracking station is and switch to a viable launch site. I'll detail instructions on the wiki a little later.

This is pretty much ready for release, at least for feedback. Pull request has been sent, although I think I screwed up and forgot to merge first. vOv Next time...

Edited April 28, 2014 by regex

[RaccoonTOF]

@Nathan - too funny, my other boat is also a Cal 25 (1969 - flush deck, not the 25-2). Little small to live on though - I did for about 9 months before "upgrading" - she stays in a nice sheltered marina off the Pasquotank River, except when I go out for a day sail, or if I decide to join in the one-design races on the Chessie this year (absolutely amazing boat for racing singlehanded ).

[SpacedInvader]

@Nathan: If you're still up, I'm uploading right now, I'll be PM'ing you the link as soon as its up.

[NathanKell]

regex: cool! And eggrobin did the hard merging work (since evidently I did stuff while you were, oops). Looks great!

RaccoonTOF: Hah! No way! My parents have had it since like the 70s or so. Here it is back about when I was born, I think off Norwalk.

SpacedInvader: cool! Yup, still up. Trying to finish about 5 releases before crashing...