How to detect which bodys have physical real sea level spheres

[Dunbaratu]

Some bodies, like Kerbin and Eve and Laythe, have a sea level sphere that is real and made of liquid.

Some bodies, like Minmus, have a sea level sphere that is real and made of solid ground.

But other bodies, like the Mun, have a sea level sphere that is entirely invisible and permeable and not "really" there. The Mun has one or two craters that actually allow you to go below sea level and land under the "sea", with no ill effects.

Is there something in the API I can query that can tell me the difference? Given a CelestialBody or a CelestialBody's pqsController, what is the way I can tell if its sea level is a "real" one or not? This matters because I'm trying to work out what the distance to the ground or water using a homemade raycats algorithm, given the body's pqs controller, and on some planets, when the pqsController tells me the ground altitude is negative at a certain location, that means I can actually go below sea level and land down there, and on other planets, it means I cannot ever reach that ground and I'll hit the sea level sphere first. Knowing the difference matters and I don't know how to tell other than just hardcoding it per body which way (which seems inelegant).

[sarbian]

CelestialBody.ocean ?

[Greys]

There's no such thing as a hard sea.

Minmus does not have a sea

the Mun does not have an invisible sea

The Mun has no ocean at all, nor does Minmus, or Jool for that matter. Oceans are an optional component.

The way Minmus works is that it has a seeded noise based procedural terrain definition; which is then clamped to within a range. This sets the smooth flats at the minimum value, and the smooth highlands at the maximum value; then just like Kerbin, the terrain is textured based on it's altitude, latitude, slope, biome, etc; the land on minmus which is at the minimum altitude is given this texture, land on kerbin that is near sealevel is given sand texture, land that's above some latitude becomes arctic.

All ocean is regular ocean, the color changes, the density changes, but it's all 'liquid', and all unusually lethal

[Dunbaratu]

There's no such thing as a hard sea.

Minmus does not have a sea

the Mun does not have an invisible sea

The Mun has no ocean at all, nor does Minmus, or Jool for that matter. Oceans are an optional component.

I didn't say it had an ocean. I said it has a mathematical "sea level" and it does. It's the altitude that is returned as "zero" in the altimeter, as opposed to the radar altitude to the actual terrain. The point is that on some worlds, when the pqsController tells you terrain exists that has negative altitude (the radius returned is less than the planet's default sphere radius, it's "sea level"), you actually can land on it, but on other words you cannot because there is an actual object to collide with a sea level that you hit first. I don't care whether that object is liquid and therefore can be called an "ocean" or not. I only care whether that object exists on the body in question in one form or another, be it liquid or not. On some worlds, while the pqsController will return terrain at negative altitude, you can't actually get to it because the world is made up of an intersection between the terrain altitude returned by pqsController AND a smooth sphere at altitude zero, and whichever of the two of them is higher is the effective lowest you can go. On other bodies, you actually can go land at a negative altitude when the pqsController tells you there is negative altitude terrain there, because the "sea level" altitude isn't populated with anything.

I deliberately avoided calling the sea level object an "ocean" because for the purpose of this query I don't care whether it's made of liquid or not. I only care whether it's going to be there or not, interfering with trying to reach the negative terrain.

As for Minmus, I was assuming it worked just like Kerbin - an intersection of a plain spherical object with a bumpy terrain object, but in minmus's case the plain spherical object was solid instead of liquid. That's why I left the door open for the possibility that the same intersection with a plain sphere that was used for oceans might be used for dry land too. I don't KNOW whether that's the case or not. All I want to know is "what's the reliable way to detect whether or not there will be that superimposed sphere in place or not?" If it turns out that this technique is only used when CelestialBody.ocean is true, and it's never used for dry land, then that's my answer. I didn't know whether or not that superimposing-a-sphere-with-the-terrain technique was reserved purely for oceans and nothing else. Is it?

Edited October 15, 2014 by Steven Mading

[philotical]

there is no superimposed sphere, the ocean is an effect object - not a solid sphere

You can check for it's presence with get component. as sarbian suggested.

If that is not present, you can land on any spot on the body. No matter what altitude it has.

The proof are submarines and underwater rovers..

you can drive down to 1800meter below sealevel on kerbin if your rover does not float.

I wouldn't call that a superimposed solid sphere..

the answer is therefore "yes" - but actualy greys answer was allready quite clear on this?

HTH

[Dunbaratu]

there is no superimposed sphere, the ocean is an effect object - not a solid sphere

You can check for it's presence with get component. as sarbian suggested.

Get component? The only suggestion I saw mentioned CelestialBody.ocean, not get component.

I wouldn't call that a superimposed solid sphere..

Neither would I, and I didn't. I didn't claim that Kerbin's superimposed sphere was a solid one, but that Minmus's was, under the assumption that Minmus had such a superimposed sphere.

the answer is therefore "yes" - but actualy greys answer was allready quite clear on this?

No, not really. That answer just told me that Minmus had no ocean, which I already knew and I never claimed it had an ocean, nor a "hard sea", as it was put. What I assumed was that the method of superimposing a smooth sphere with the bumpy pqsController terrain height was a technique that wasn't limited to oceans only.

In other words, I was envisioning the cases breaking down this way:

  Does Body have a superimposed sea-level sphere?
       /      \
      /        \
    no         yes
 (i.e Mun)      |
  Case 1        |
                |
            Is it an ocean?
              /   \
             /     \
            /       \
           no       yes
    (i.e. Minmus)   (i.e. Kerbin)
      Case 2              Case 3

It sounds like what you're trying to say is that Case 2 doesn't exist.

So telling me oceans aren't solid doesn't really tell me anything because by the time I'm calling it an "ocean" I'm already thinking Case 3 and I'm already thinking "well of course they're not solid. The kinds of spheres that are solid aren't going to be called "oceans".

That's why the previous answers were not clear. They assumed I was thinking of it this way:

  Does Body have an ocean?
       /      \
      /        \
    no         yes
 (i.e Mun)      |
  Case 1        |
                |
            Is it liquid?
              /   \
             /     \
            /       \
           no       yes
    (i.e. Minmus)   (i.e. Kerbin)
      Case 2              Case 3

When that's not what I was thinking, nor how I was trying to describe it.

Edited October 15, 2014 by Steven Mading

[philotical]

https://raw.githubusercontent.com/Anatid/XML-Documentation-for-the-KSP-API/master/Assembly-CSharp.xml

<member name="F:CelestialBody.ocean">

<summary>

Whether this planet has an ocean at "sea level"

</summary>

</member>

the sea level is just a number arbitrarly defined, if the answer to above question is no, the sea level is not much more than a number..

No one tried to hypotethise, what you thought - you where quite clear in OP.

Greys told you that your assumption is wrong and explained why it's likely to get the wrong assumption, I confirmed that it's wrong.

Now it's actually just up to you to believe it :-)

Consider this: Could it be, that you got lost in a futile question because KSP/Unity is confusing in all details?

It is as simple as we described - no mysteries attached in this case..

PS: the get component I mentioned, is an alternative (more complicated) way to reach the same - if you query for OcenFX (iirc) you can get the same confirmation

Does it or does it not have the water effect at sea level..

...but the sea level does not otherwise affect the flight as far as I understand the matter

[Dunbaratu]

No one tried to hypotethise, what you thought - you where quite clear in OP.

Then why would anyone think that telling me oceans can't be solid constituted an answer? Someone who thinks I thought oceans can be solid didn't understand me.

Greys told you that your assumption is wrong and explained why it's likely to get the wrong assumption, I confirmed that it's wrong.

No, Greys said that an assumption I wasn't even making was wrong. The actual assumption I was making is that both oceans and flat bottom land are modeled using the same smooth sphere superimposition method, not that oceans themselves are solid.

Now it's actually just up to you to believe it :-)

It only became clear eventually further down in the thread that in addition to the strawman of my assumption referred to in Grey's post being wrong, that the assumption I actually made was wrong too. The claim that it was clear from Grey's post alone is wrong.

Consider this: Could it be, that you got lost in a futile question because KSP/Unity is confusing in all details?

It is as simple as we described - no mysteries attached in this case..

It's simpler than you described, which is why it's confusing. Talking about the red herrings of whether oceans can be solid deflected the topic from the actual point where my assumption was wrong, which was about whether or not solid land uses the same sphere intersection system oceans use.

"The system that superimposes a sphere above the negative altitude terrain is only used by oceans and oceans alone. It was not used to build flat land like you see on Minmus. Minmus's pqsController actually returns zero for real for the terrain height in those locations". <- That's the simple answer that addresses the point where I actually had the wrong assumption, and it's not quite how it was being expressed. Telling me that "my" assumption that oceans can be solid is wrong is addressing a different assumption than the one I was making. I never thought that the flat land on Minmus was actually an ocean.

Anyway, thanks for clearing it up.

Edited October 15, 2014 by Steven Mading

[NathanKell]

PQS can have negative altitude (i.e. below PQS.radius). CelestialBody also has a radius, and below that radius is "below sea level" on the altitude meter.

As Greys and others said, you're confusing two things:

1. Some PQS have child PQSs (Kerbin, Eve, Laythe), a whole separate PQS that does not get any height mods. This is the ocean PQS. It's why Kerbin etc are more processor-intensive to look at than other bodies, because they have two PQSs. This child PQS has its radius as the body's radius (i.e. sea level) and doesn't vary in height, while (as mentioned above) the parent PQS may vary in height below itsradius (i.e. below sea level) and thus you get a sea floor.

2. All bodies have a set radius, this is their (altitude) sea level, against which the ASL altitude is calculated. Altitude above terrain is calculated from the actual PQS (parent-sphere if there is also a child sphere) terrain.

[philotical]

NathanKell to the rescue.. :-D

Anyway, thanks for clearing it up.

your welcome..

[Dunbaratu]

1. Some PQS have child PQSs (Kerbin, Eve, Laythe), a whole separate PQS that does not get any height mods. This is the ocean PQS. It's why Kerbin etc are more processor-intensive to look at than other bodies, because they have two PQSs. This child PQS has its radius as the body's radius (i.e. sea level) and doesn't vary in height, while (as mentioned above) the parent PQS may vary in height below itsradius (i.e. below sea level) and thus you get a sea floor.

The relevant thing not being said here, and it's important as its the only thing I was ever confused about, is the fact that not only is the child PQS used for oceans, but that this system is used exclusively for oceans and never for generating flat land.

The same type of child PQS data structure could have easily been used to make flat bottom land, so it's not an obvious assumption to make that it is never done that way.

Although mentioning that the oceans are also a separate PQS of their own does give rise to an alternate algorithm I can use that's more robust than assuming this system will only ever be used for oceans from now and forever. Instead of trying to track whether the planet has oceans, I just ask for all the PQS objects attached to it, and look for the intersect with whichever one of them is nearest, not caring whether it's an ocean or not. That way the code might continue working if in a future release SQUAD decides to change the assumptions and start using the child PQS system for solid ground.

Edited October 15, 2014 by Steven Mading

[silverfox8124]

Steven, If you're using raycasts for measuring the distance to ground, then just do so. You can call a ray's distance travelled and it also has a vector to it which you can return. No matter what planet/mun you're on, you can raycast the ground and get the "real" altitude by raycasting the ground and getting the distance travelled by the ray. ~SilverFox8124

[Dunbaratu]

Steven, If you're using raycasts for measuring the distance to ground, then just do so. You can call a ray's distance travelled and it also has a vector to it which you can return. No matter what planet/mun you're on, you can raycast the ground and get the "real" altitude by raycasting the ground and getting the distance travelled by the ray. ~SilverFox8124

KSP doesn't load the terrain polygons into Unity at distances longer than about 10km or so. Raycasts only work when close up. I want this to also work from orbit too. The only way I've found to make it work from far away from the ground is making a numeric approximation algorithm that takes sample points along the ray and queries the pqsController to find the altitude at those locations, using a dissection algorithm to find where the ray first becomes underground, then recursively checking where in THAT slice the sub-slice is where it first goes underground, then check the sub-sub-sub slices, and so on until the error is less than the epsilon I've chosen (which is 2 meters, as this is only used from very long distances where that's acceptable).

KSP does have a raycast method in the pqsController but all it does is a sphere intersection with the ray and the body's default zero-altitude radius, ignoring the actual terrain.

The first thing my code does is attempt the direct raycast hoping the polygons are actually loaded and it's a nearby hit. It's only when that fails but the ray does intersect the body's radiusMax sphere that I then drop down into the more expensive numeric approximation algorithm.

[silverfox8124]

Have you tried calling for Biome.LowestHeight and Biome.HighestHeight yet? Those have been working for me if you do them right.

[Dunbaratu]

Have you tried calling for Biome.LowestHeight and Biome.HighestHeight yet? Those have been working for me if you do them right.

I've got a working solution using theBody.pqsController.radiusMin and theBody.pqsController.radiusMax. The only thing is that I have to be careful that some bodies have no pqsController because they have no surface (the Sun, and perhaps Jool, but I haven't tested on Jool yet so I don't know).