Jump to content

[1.2] Real Solar System v12.0 Dec 8


NathanKell

Recommended Posts

I was so happy to discover this mod in the Scott Manley video yesterday, so I went all-out with the Modular tanks mod and did a to-scale Apollo mission. Imgur album and Reddit thread.

Thanks for all your work!

Other than some difficult-to describe instability, the only bug I want to point out is the Mun seeming to have some kind of height layer that hovers some 10's of km above the real ground. It was weird to pass through that on my way into the landing.

Darn, you beat me. I've been working on the same thing the last couple days. At the moment I'm about 800m/s dV away from being able to return. All fuel is used up by the time my lunar ascent module docks with the CM. Your craft seems to have about 9km/s more dV than mine though. I guess its time to beef it up even more. Imgur

Link to comment
Share on other sites

I was so happy to discover this mod in the Scott Manley video yesterday, so I went all-out with the Modular tanks mod and did a to-scale Apollo mission. Imgur album and Reddit thread.

Thanks for all your work!

I noticed you throttled down your 1st stage to reduce the gees to something manageable. Believe it or not, the real Saturn V did something similar for the same effect - it shut down the central engine right around 5 gees. That was a very cool recreation of Apollo, many props to you!

I've been playing with the mod a bit and I'm enjoying it very much. One of my mods is not playing nice though. When I stripped out all mods except FAR and RSS, I was able to get a 3 man capsule to orbit with a few hundred m/s to spare. With all other mods installed, I had a horrible time controlling rockets that I thought should otherwise be stable. Over-control and terrible oscillations were the name of the game. My mod list was as follows: KW Rocketry, MechJeb2, a few parts from AESAerospace, I^3's radial drogue, Enhanced Nav Ball, a few parts from KSPX, MechJeb2, and the Triggertech Kerbal Alarm Clock. I initially removed Farram's joint strengthening mod, but that did not fix the problem. I've started adding mods back in until I find the culprit, so I'll keep you updated.

Link to comment
Share on other sites

This looks really terrific so far, and I'm really eager to see where it goes. I think I'll hold off until it's gone through a few more iterations though.

And hopefully by then, I'll have a rig that can actually make use of it. My current setup barely effectively runs the stock game on the lowest settings.

Nonetheless, a full-sized system would be truly awesome...especially with Fractal_UK's Interstellar Mod. Keep it up, and good luck.

Link to comment
Share on other sites

As far as Saturn/Uranus/Neptune go, can you make copies of Jool, maybe color them a different color, and then resize them to the right proportions? Can you even make multiple copies of planets? I'm thinking it would help with populating some of the giant planets' moons and the asteroid belt.

Yes, multiple copies are possible.

kBxbcR3.png

That was in 0.21, but I don't think anything has changed regarding planets and how they work in 0.22, so it should still work just as well. That Eeloo2 is every bit as good (or bad, depending on your opinion) a planet as Eeloo. I just shifted its orbit around so they wouldn't interfere, but other than that I haven't done much on this since. The same could be done for Jool, but you would have to take care to copy all of its moons as well. You can also delete planets/moons if you like as well. When I can find the time I am going to try to make a full planet generator that builds planets from scratch from custom resources and a config file, because I think I've figured out how to do it. Of course my first target would be our solar system, which would be handy for this mod.

Edit:

I didn't mean to imply that copying the planet Jool requires you to copy its moons - I was thinking of the case of copying the Jool system.

Jool is also easily resizable and retexturable, so you should be able to have Saturn, Uranus and Neptune analogues. You can even change the atmosphere tint to match. Jool is the easiest planet to manipulate because it doesn't have a surface (well, not a surface in the sense that the other planets have). It also doesn't have any static objects on it to take care of.

Edited by ZRM
Link to comment
Share on other sites

I am curious whether adding a lot of planets has any relevant impact on performance, as I recall this being the major issue for Squad.

If you're not near a body's surface (near being defined as quite a bit closer than 100Km in most cases - the exact distance varies depending on the body) so that the terrain system is not active, the body is rendered as a simple 3D model. This practically guarantees that only one body has its terrain system and objects on the terrain active at any one time. You're then only limited by the CPU cost of updating orbits for extra bodies (which is not much - it's the same as the cost for all the debris you have in orbit, and think how much of that you can have) and the rendering cost of all the "distant" models. I don't think there's much in the way of a LOD or culling system for these distant models (aka ScaledSpace models), not even for the ones that take up less than the size of a pixel (which is the case for nearly everything), but I think it's possible to implement such a system on top of what's already available to keep performance at a suitable level even with maybe 1000s of bodies (e.g. with upwards of 50 moons per gas giant and a moderate asteroid belt). In theory you could make it so that only a subset of the whole system is actually presented to KSP's systems at any one time, e.g. so that you can cull asteroids.

In short, I think performance is probably not necessarily a permanent problem, if indeed it is one at all. We'll see, once I find the time to work on creating custom planets (probably December at the earliest).

Also, my investigations have indicated that it should be possible to create things like planetary rings, comets, and maybe even wacky things like cube-shaped planets, all as first-class members of the solar system (i.e. without hacking things much).

I would also be curious to see what Squad said about number of planets vs performance, if you have a link.

Link to comment
Share on other sites

I would also be curious to see what Squad said about number of planets vs performance, if you have a link.

To be honest, I do not. It was something I vaguely remembered, but now I am seriously doubting whether that is right.

Link to comment
Share on other sites

@ZRM. Hope RL is going great, and when time permits the addition of other 'bodies' can be realized. I for one would enjoy the idea of multiple comets, each with its own 'interesting' orbit and technical difficulty in reaching, studying and even possible sample return or landing missions.

again, good luck and thanks for all mods and work.

Link to comment
Share on other sites

I am curious whether adding a lot of planets has any relevant impact on performance, as I recall this being the major issue for Squad.

Before one of the recent updates (0.20 or 0.21, not sure) the game loaded all the high detail planetary meshes into memory. Since KSP is a 32 bit application, it can only use a limited amount of memory and a lot of it was taken by these meshes. The update changed the way KSP loads planetary data so that the high detail mesh is only loaded into memory once you approach a planet.

Link to comment
Share on other sites

Before one of the recent updates (0.20 or 0.21, not sure) the game loaded all the high detail planetary meshes into memory. Since KSP is a 32 bit application, it can only use a limited amount of memory and a lot of it was taken by these meshes. The update changed the way KSP loads planetary data so that the high detail mesh is only loaded into memory once you approach a planet.

Thinking about it I did remember something like this (new terrain processing), but it was as vague as my other memory. Guess I was not all wrong after all :D

Link to comment
Share on other sites

Before one of the recent updates (0.20 or 0.21, not sure) the game loaded all the high detail planetary meshes into memory. Since KSP is a 32 bit application, it can only use a limited amount of memory and a lot of it was taken by these meshes. The update changed the way KSP loads planetary data so that the high detail mesh is only loaded into memory once you approach a planet.

Ah, I had heard that they had done something to improve PQS for 0.21, but I did not have specifics of what exactly that was. Thanks (also, link?). The changes in 0.21 are also apparently what made Kragrathea give up on her planet mod. Luckily I started the project with 0.21, so I hopefully won't have to deal with major changes to the system.

Link to comment
Share on other sites

Thankfully, she hasn't given up. :)

Progress update: I hope to have the code for body changing abstracted today. ZRM, haven't had a chance to implement your fix yet; v4 may just include rescales for most bodies but no tilts yet. We'll see how much I can get done this evening.

Well, that's a surprise, hiding away in Mission Reports. I'll still work on my approach though when I get the time, and I plan to make it much more open - for example, as soon as I get it so that you can add a custom planet via a config file I'll make a release. Then anyone can make their own planetary systems, not limited by the imagination of the mod author.

Judging from those screenshots, though this is just an educated guess, it looks like Krag's mod is making planets by duplicating and modifying existing ones (for example those screenshots show a blue gas giant still possessing a green atmosphere tint like that of Jool, and the new rocky bodies look very similar in certain respects to some existing ones). I can already do that to an extent (see my previous post with the screenshot), but I would much prefer being able to generate bodies completely from scratch, which I have reason to believe is very doable, and would lead to a much greater range of possibilities. I also might have a solution for the multiple star illumination problem.

Damn, I really wish I had the time to work on this, if only just to get it out my head.

Edited by ZRM
Link to comment
Share on other sites

A generator would be pretty amazing. It would be so easy to replicate systems as they are being discovered in real life.

Yeah, well somehow I think it might be quite difficult (I'm not saying impossible - we've all learned not to say that) to get interstellar distances working. Implementing such scales on the current system directly would not end well due to floating point precision. If a modder was ever to attempt having multiple planetary systems light years apart it may be best to treat interstellar travel as unloading the system you're leaving and loading the destination system as necessary, dealing with all the setting up and tearing down along the way. There would also need to be a new super-map view for visualising space at the per-system level. The tricky part is making sure that unloading/loading systems cleanly deals with the persistence of the state of things on and orbiting bodies in those systems, and figuring out how to deal with vessels in interstellar space in the best way. The feasibility of all of this hinges on how much of the internals the API exposes. The more feasible alternative is to just have multiple systems that the user can pick between per save file.

Squad would probably take a different route to implementing interstellar travel given that they actually have control over how the core code works directly. They would probably make a new "super" scaled space environment which each system's scaled space resides in. That would end up being a lot more seamless.

Link to comment
Share on other sites

Yes, I was careful not to suggest travel between systems. For now, bouncing around locally will be amazing enough. Maybe Squad will be motivated to implement some things that make interstellar travel easier in the long run, but I feel that interstellar travel gameplay and -mechanics wise is something quite different that what KSP does now.

Link to comment
Share on other sites

Regarding improving terrain detail - currently Kerbin uses 4096x2048 heightmap, theoretically we could increase it's resolution to 8k by 4k or even 16k by 8k (DirectX 11-compatible cards support texture sizes up to 16k), but I think there still won't enough details...

Link to comment
Share on other sites

According to experiments in the UR thread, KSP/Unity will reject textures over 8x4. I'm thinking we should try out an 8x4 Earth heightmap for kicks, see how that goes. If we're replacing, might as well go whole hog. But you're right, it's a drop in the bucket. We'd get 0.043 degree (~5km) per pixel resolution at the equator. I wonder if there's any way to use the scatter system for Munar craters to generate procedural detail on Kerbin?

ZRM...heh, life. :]

Link to comment
Share on other sites

I wonder if there's any way to use the scatter system for Munar craters to generate procedural detail on Kerbin?

Would it be possible to create some after market procedural terrain generation, Space Engine style?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...