Jump to content

Realism Overhaul

NathanKell

By NathanKell
in KSP1 Mod Development

 Share

Recommended Posts

Bobhendly

Bobhendly

Posted
Posted

"MONO DLL HAS CAUSED A ACCESS VIOLATION"

Ya hear that? That's KSP Running out of memory due to massive planets.

*Sorry* For the sarcasm, But the point is that when people add more core things into the game, Like krathegea adding planets, Unity's Crapstick of 32Bit Wont handle more than 3GB... So the game will start crashing from memory loss with your supersize-Me Planets. It seems like a cool idea, But that's (One of the reasons) why squad ultimately decided to go with smaller celestials.. As far As I know.

Good Luck! -BobHendly

Link to comment
Share on other sites
asmi

asmi

Posted
Posted
Success! Holy smokes, success.

asmi: Code checked in. Note that you need to not be running remotetech, because it calculates distance to missions control before the planet is rescaled. That had me stumped before I remembered I was running RT.

Also, clicking on buildings in spaceport is hard as all get-out, but possible. Zoom out so they appear, then rotate to top view.

So, we went from "It's impossible!" to essentially "Done!" in less than 24 hours. Great job! Looks like my "motivation" technique hit exact spot I was aiming it to :)

Link to comment
Share on other sites
NathanKell

NathanKell

Posted
  • Author
Posted (edited)

Bobhendly, the quadtree hasn't been expanded any, so this, AFAIK, shouldn't take up any more memory.

Remember that Earth rotational axis is tilted, and so Moon's inclination in regards to equatorial plane is not constant. I wonder if it's possible to tilt Kerbin's axis...

But I'd suggest to solve problems one by one, and not jumping on everything at once as it's the most sure way to not get them all solved. My few short tests have shown that orbital mechanics works just fine with whatever parameters we set in CelestialBody. It's graphics which could prove to be a problem.

If we'll succeed in rescaling terrain (and something tells me that we will :) ), it will look rather blurry and coarse as textures are covering specific spherical patches which are defined using lat/lng angular coordinates, and so their physical size is defined by the radius of the body. Theoretically quadtree could be extended beyond current max subdivision level of 10 (BTW Orbiter uses the same approach, and it uses levels up to 14, while my D3D11Client engine for Orbiter allowed for up to lvl 18, which gives <10meters precision for the bodies of Earth-like size - although there were FP precision issues to be solved to achieve that), but that would possibly require generating additional higher-res textures if we want it to look nice, AND implementing rather aggressive paging mechanism for textures as they simply would not fit within the confines of 32bit process address space. Well - I've solved this problem once already (for D3D11Client graphics engine for Orbiter), so I'm sure we'll find a way to solve it within Unity :)

But let's not get ahead of ourselves. The task of the day is to get terrain to render at all according to the new size. Once that is done, we'll see what to do next.

1. Kerbin's axis of rotation is tilted in the stock game, I think. Anyway, there's a rotationaxis and if it's not we can.

2. I'm not sure how their quadtree implementation works; thankfully that was my senior project so I'm relatively familiar with them, but it's not super clear how their system works as yet... But sounds like you're even more on top of this stuff! :)

Anyway, the "task of the day" is done. :)

It seems that this Kerbin is scaled 1:1 with Earth. It might be preferable to use 64% scale, because that's roughly how Kerbals and every realistic mod out there is scaled. I wouldn't want to upscale the N1 to 1:1, because it wouldn't fit in the VAB very well. Currently, VAB is about 65m tall, which is just enough for the largest RL superboosters. That said, if it was possible to enlarge the VAB somewhat, and to automatically up the rescale factor for all parts, I'd be all for going 1:1.

I wouldn't really want to do 64% planet size because that would (as we've seen from stock KSP's weird orbital flight paths) mess up the trip to orbit. So much of the weirdness if from the different gravity gradient, as well as the much lower dV requirement.

I do support all actual non-planet sizes being 64%, though, and for that reason we should scale most payload masses to 1/4 (I was wrong to say 1/3 above, dunno why I thought that). That is if the part is made to Kerbal-size (64%) like the Mk1-2 3-crew pod, not real size like the Mk1.

Edited by NathanKell
Link to comment
Share on other sites
Guest

Guest

Posted
Posted
Bobhendly, the quadtree hasn't been expanded any, so this, AFAIK, shouldn't take up any more memory.

1. Kerbin's axis of rotation is tilted in the stock game, I think. Anyway, there's a rotationaxis and if it's not we can.

2. I'm not sure how their quadtree implementation works; thankfully that was my senior project so I'm relatively familiar with them, but it's not super clear how their system works as yet... But sounds like you're even more on top of this stuff! :)

Anyway, the "task of the day" is done. :)

I wouldn't really want to do 64% planet size because that would (as we've seen from stock KSP's weird orbital flight paths) mess up the trip to orbit. So much of the weirdness if from the different gravity gradient, as well as the much lower dV requirement.

I do support all actual non-planet sizes being 64%, though, and for that reason we should scale most payload masses to 1/4 (I was wrong to say 1/3 above, dunno why I thought that). That is if the part is made to Kerbal-size (64%) like the Mk1-2 3-crew pod, not real size like the Mk1.

The problem is, you're ending up with a disproportion between celestial bodies and rockets. You'd have to scale rockets to 1:1, too, or cheat with fuel densities. Scaling payload masses to 1/4 while keeping the rest of the rocket 64% introduces a change in mass distribution of the rocket, which might lead to inaccuracies in flight model. I'm especially concerned about stuff like Kliper, where the payload has a major effect on rocket's aerodynamics. In this example, COM will inevitably move back, potentially causing instability if the aerodynamics were like on the real thing.

Link to comment
Share on other sites
NathanKell

NathanKell

Posted
  • Author
Posted

No, it shouldn't lead to a change of distribution: .64*.64*.64 = .262. So technically that's what to scale by, I was simplifying with 1/4.

Right now, with rockets and payloads that are 64% as wide (and as tall and as deep) as real life, but the same mass, we are _currently_ dealing with out of balance rockets.

Link to comment
Share on other sites
pina_coladas

pina_coladas

Posted
Posted

So I pretty much ignored this thread at first because I'm not that interested in people playing with lowering ISPs and things like that to try to make dV to orbit more "realistic" on toy-sized planets, but I looked again and suddenly this is the best thread on the forums! I had to lol a bit at the blurry orbiter-like kerbin textures (it's beautiful).

I hope you guys can get the kinks worked out and that you don't run into memory limits! Godspeed.

Link to comment
Share on other sites
asmi

asmi

Posted
Posted

1. Kerbin's axis of rotation is tilted in the stock game, I think. Anyway, there's a rotationaxis and if it's not we can.

2. I'm not sure how their quadtree implementation works; thankfully that was my senior project so I'm relatively familiar with them, but it's not super clear how their system works as yet... But sounds like you're even more on top of this stuff! :)

Anyway, the "task of the day" is done. :)

Ok, awesome! Now we need to come up with config system so instead of hardcoding values we could provide them in a config, which would automatically be processed by the mod and it will configure solar system. If you want, I can take care of that bit since I'm intimately familiar with stock ConfigNodes system. The only thing I need to know is what degrees of freedom (minimal list of independent parameters that would define the complete state of the celestial body) do we have so I could code them into configs.

Just in case you haven't seen it already, watch this:

This is Squad's speech at the most recent Unite conference, it contains a ton of very useful technical information on how exactly KSP works under the hood.
Link to comment
Share on other sites
ferram4

ferram4

Posted
Posted

Thinking about it more, I'd actually advise making the atmosphere taller than 105km; here's why:

We should set the cutoff so that dynamic pressure (0.5f * air_density * velocity2) is about the same between stock Kerbin and real Kerbin.

Dynamic pressure at the top of stock Kerbin's atmosphere (at orbital velocities) tends to be ~2-5 Pa.

At the top of this atmosphere, assuming a circular orbit, we get a velocity of 7.836 km/s.

Converting to rotating frame:

sidereal day: 86164s

angular rate: 1.1606 1/s

velocity of the frame at the top of the atmosphere: 0.0751 km/s

So we're looking at a velocity in atmosphere of ~7.761 km/s

Air density at 105km: 1.0186 * 10-6 kg/m3

Dyn pressure = 30.677 Pa

This means that the aerodynamic forces are about ten times as high for this Kerbin's atmospheric cutoff than for the stock Kerbin atmospheric cutoff.

Looking at the math for it, rather than having the cutoff at 14 scale heights (105km), increasing it to 17-18 scale heights (127.5km - 135km) will set the cutoff dynamic pressure slightly below what is experienced in stock KSP. It would also make going into the atmosphere a lot less abrupt in terms of forces applied.

Link to comment
Share on other sites
NathanKell

NathanKell

Posted
  • Author
Posted

ferram: makes sense. I'll do that. So ingame scaleheight of 8.5, here we come.

asmi: sure, if you want to do that, though it's probably a better use of your talents if you want to try tackling either getting the spaceport useable again (fixing the positions and scales in PQSCity), or the atmosphere graphics scaling incorrectly (think I have a handle on that though). I could probably knock together a confignode system in a half hour or so. But I certainly wouldn't say no! :)

I was thinking:

REALSOLARSYTEM
{
	Kerbin
	{
		PQS
		{
			float
			{
				Radius = 6137
				atmosphereScaleHeight = 8.5
			}
		}
		Scaled
		{
			Vector3
			{
				localscale = 1.0618333333, 1.0618333333, 1.0618333333
			}
		}
	}
}

with SetFields() based on key names, and type based on node names.

Or were you thinking more inputting real life parameters and having the plugin figure out what to set? That limits us to only being able to change parameters the plugin is set up for...

Link to comment
Share on other sites
ferram4

ferram4

Posted
Posted (edited)

No, I meant keep the scale height where it is at 7.5km, but set the maxAtmosphereAltitude to ~135km. What you're doing keeps the same issue I was trying to solve, but causes it at a higher altitude. :P

Also, the proper average radius is 6371km, not 6137km; minor, but important detail.

Edited by ferram4
Link to comment
Share on other sites
asmi

asmi

Posted
Posted (edited)

Wow - this is a first time in a loooong time I wasn't able to reach orbit on the first try:

FPuh33V.png

Abr6Rec.png

cy2KKzI.png

gYl5O4v.png

Getting ready for reentry:

ltCHd2M.png

Entry interface @21.5M lol

frOAosr.png

Peak G-load (almost 10G):

l1IeuIO.png

Sorry man, but I just can't stop playing this :D It's so awesome!!!

Edited by asmi
Link to comment
Share on other sites
asmi

asmi

Posted
Posted (edited)
asmi: sure, if you want to do that, though it's probably a better use of your talents if you want to try tackling either getting the spaceport useable again (fixing the positions and scales in PQSCity), or the atmosphere graphics scaling incorrectly (think I have a handle on that though).

Ok then - I'll get to it. To be honest I don't have too much spare time during the work week, but I do have "good Saturdays and Sundays" :) My wife is in the business trip abroad, so I've got plenty of free time during weekends :)

I could probably knock together a confignode system in a half hour or so. But I certainly wouldn't say no! :).

I was thinking:

REALSOLARSYTEM
{
	Kerbin
	{
		PQS
		{
			float
			{
				Radius = 6137
				atmosphereScaleHeight = 8.5
			}
		}
		Scaled
		{
			Vector3
			{
				localscale = 1.0618333333, 1.0618333333, 1.0618333333
			}
		}
	}
}

with SetFields() based on key names, and type based on node names.

Or were you thinking more inputting real life parameters and having the plugin figure out what to set? That limits us to only being able to change parameters the plugin is set up for...

Yea, that's what I was thinking of (stuff like Radius, GeeASL). This would be easier for users. And config should include orbital parameters as well so we won't have to have them in a separate place.

Edited by asmi
Link to comment
Share on other sites
ferram4

ferram4

Posted
Posted

@asmi: Make the central core a little taller and use the same engine type to make a pair of liquid boosters that are half as tall as your current core stage is. No fuel cross feed. That should provide enough dV for you to get there.

I must try this myself.

Link to comment
Share on other sites
asmi

asmi

Posted
Posted
I've almost finished real-weight engines and fuel tanks for this. Then boy howdy am I playing too. It's like Christmas!

Squee!

Make sure you put this somewhere for download - looks like there's quite an interest :)

Oh, I've found a bug in VAB - sometimes it doesn't display all icons in staging when I'm adding multiple engines (ullage motors and SRBs in my case). Saving and reloading craft makes them appear, so no big deal for now, but it's somewhat annoying. Not sure if it's related to your MFSC, or something else - although I don't quite see how resize could affect that.

Link to comment
Share on other sites
asmi

asmi

Posted
Posted
@asmi: Make the central core a little taller and use the same engine type to make a pair of liquid boosters that are half as tall as your current core stage is. No fuel cross feed. That should provide enough dV for you to get there.

I must try this myself.

There is no room in VAB - it already hits the roof :) Looks like we need to get EditorTools to expand VAB more.

Link to comment
Share on other sites
SFJackBauer

SFJackBauer

Posted
Posted (edited)

Oh God, I'm totally trying it.

EDIT: Deadly Reentry, forgot to add heat shield. Command pod destroyed on reentry at 40km altitude, 3800m/s speed.

EDIT2: Heat shield didn't changed the outcome. :D

Edited by SFJackBauer
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...