Altitude above ground level?

[stupid_chris]

Anyway, this is what I came up with for distance & surface normal at an angle (with respect to the ocean--the intent being to take to compare with a raycast, take the min() of the distances, and then decide the correct normal based on that):

http://i.imgur.com/dAGb9jd.png

I originally thought I could solve this relatively easily with the law of cosines, until I realized that that's intended for finding the angle between two known sides, and not when you have an angle next to only one known side. I still think it's applicable, just I have to derive exactly what I need correctly.

p.s. - In case it wasn't apparent, ignore the tangential line for the side of the triangle labeled "r+a", as that is the length of the full side, not just to where it intersects the tangent.

Did you actually get it? Because I feel like you're overcomplicating your things (from a guy who did calculus III)

Okay, quick 5 second test.

FlightGlobals.ActiveVessel.pqsAltitude (field) looks to be what to use. It returns the height of the terrain below the vessel's CoM as altitude above sea level (to the terrain, not the vessel).

There is also a FlightGlobals.ActiveVessel.PqsAltitude() method that also returns a double, but in a quick run in a rover around KSC, the .psqAltitude field was more accurate.

Note that .pqsAltitude returns a negative number over water, so I will confirm that your vessel's current altitude above terrain is:

VesselAboveTerrain = FlightGlobals.ActiveVessel.altitude - Math.Max(FlightGlobals.ActiveVessel.pqsAltitude,0);

The Math.Max ensures that if you are over water, the negative number for the seabed is not used.

D.

You should also check for oceans. Some planets have negative altitude values and no ocean (like Duna)

[Diazo]

Bleh, you always miss something.

But yes, you do need to check for oceans.

D.

[Padishar]

According to Mu it could have unpredictable effects. On my side it had the effect of smashing my first test pods in the mountains when I first drafted RealChute. It doesn't seem to be as much on target as it always should.

Are you sure that was vessel.terrainAltitude? Your earlier post mentioned vessel.heightFromTerrain as being unreliable...

[stupid_chris]

Are you sure that was vessel.terrainAltitude? Your earlier post mentioned vessel.heightFromTerrain as being unreliable...

If I remember correctly, .heightFromTerrain, .terrainAltitude, and .heightFromSurface aren't always on target and/or aren't used in the situations we could think.

[Padishar]

If I remember correctly, .heightFromTerrain, .terrainAltitude, and .heightFromSurface aren't always on target and/or aren't used in the situations we could think.

Well, I had to run a test on this to be sure so I added a few extra fields to KER's surface tab and it appears that terrainAltitude is actually the same as pqsAltitude. heightFromSurface always appears to be -1 (for a rover on the ground or on a short hop anyway). heightFromTerrain looks to be quite close (~0.1m less) but it might be more wrong in other situations.

You can give this version of KER a try if you like. Just replace the Engineer.dll in a standard 0.6.2.3 KER with the one from this zip:

https://www.dropbox.com/s/cjodvjb2vlrqono/kerlogterrain.zip

Note: Backup your existing Engineer.dll as this one has lots of logging enabled in the deltaV simulation code so the build engineer and the vessel tab of the flight engineer may run a bit slow and make output_log.txt grow quite quickly (especially with more complex craft).

[rbray89]

Unfortunately that does not work at all. I had a talk with Mu a while ago while I was figuring this out myself for RealChute. Turns out that vessel.heightFromTerrain should actually be a private field. It's rarely ever used for the game, and definitely isn't what you are looking for there. RealChute confirmed it the hard way for me (meeting a mountain at high velocity).

That one is going a little complex. Actually, the way to get terrain altitude is vessel.pqsAltitude. Mu directed me to that one actually, and I can confirm that it returns the height of the terrain, and that it does not clamp to ocean. However it's quite easy to get it with something like this:

double terrainAlt = this.vessel.ocean ? Math.Max(this.vessel.pqsAltitude, 0d) : this.vessel.pqsAltitude;

However this returns the altitude directly below the ship's COM. You could indeed get it with some trig, and I could help you with it in #kspmodders if you wait for me to get home later

In one of my mods, I'm trying to more or less duplicate a layer above the terrain (and add additional scenery), but I'm having issues settling with the height error provided by celestialBody.pqsController.GetSurfaceHeight(pos). I tried using the actual PQS quad tree and the vertices with a recursive function to get the three closest vertecies and do interpolation, gave the same results, but much, much slower. Ideas?

[stupid_chris]

Well, I had to run a test on this to be sure so I added a few extra fields to KER's surface tab and it appears that terrainAltitude is actually the same as pqsAltitude. heightFromSurface always appears to be -1 (for a rover on the ground or on a short hop anyway). heightFromTerrain looks to be quite close (~0.1m less) but it might be more wrong in other situations.

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

You can give this version of KER a try if you like. Just replace the Engineer.dll in a standard 0.6.2.3 KER with the one from this zip:

https://www.dropbox.com/s/cjodvjb2vlrqono/kerlogterrain.zip

Note: Backup your existing Engineer.dll as this one has lots of logging enabled in the deltaV simulation code so the build engineer and the vessel tab of the flight engineer may run a bit slow and make output_log.txt grow quite quickly (especially with more complex craft).

Try bringing a plane to a mountain and see how it reacts, I'd be interested to know, it's where terrainalt failed for me with old RealChute.

In one of my mods, I'm trying to more or less duplicate a layer above the terrain (and add additional scenery), but I'm having issues settling with the height error provided by celestialBody.pqsController.GetSurfaceHeight(pos). I tried using the actual PQS quad tree and the vertices with a recursive function to get the three closest vertecies and do interpolation, gave the same results, but much, much slower. Ideas?

Yeah PQS is pretty slow. You could try querying surface height using this, but I'm not sure if it would be more accurate. Alternatively, you could try raycasting. I think raycasting from the center of the planet would work. But that might be even more slow.

One method that was proposed to me for another mod I'm working on was to create "premade" high precision heightmaps of celestialbodies, and storing those in the PluginData folder. This way you can do the have all the long and exhausting work with pqs done and simply have to query the files, read the height you need and close it. I think even a simple .png would work by reading the alpha channel.

[rbray89]

Try bringing a plane to a mountain and see how it reacts, I'd be interested to know, it's where terrainalt failed for me with old RealChute.

Yeah PQS is pretty slow. You could try querying surface height using this, but I'm not sure if it would be more accurate. Alternatively, you could try raycasting. I think raycasting from the center of the planet would work. But that might be even more slow.

One method that was proposed to me for another mod I'm working on was to create "premade" high precision heightmaps of celestialbodies, and storing those in the PluginData folder. This way you can do the have all the long and exhausting work with pqs done and simply have to query the files, read the height you need and close it. I think even a simple .png would work by reading the alpha channel.

I'm not convinced the resolution would be good enough in terms of hight. (256 values for 6km of height?) I also can't use ray-tracing as the PQS insance isn't rendered yet. (should have mentioned that bit). I'd just like to know why the value returned is incorrect.

[stupid_chris]

I'm not convinced the resolution would be good enough in terms of hight. (256 values for 6km of height?) I also can't use ray-tracing as the PQS insance isn't rendered yet. (should have mentioned that bit). I'd just like to know why the value returned is incorrect.

Theres other way you could store it, I know that in my case it would most likely be enough resolution I don't know why the values you get aren't right though, my knowledge of PQS isn't that vast.

[Padishar]

Try bringing a plane to a mountain and see how it reacts, I'd be interested to know, it's where terrainalt failed for me with old RealChute.

Well, I've spent a couple of hours flying and driving various craft around various hilly places on Kerbin, Mun and Minmus and terrainAltitude is always the same as pqsAltitude. I suspect that Squad have changed something since your early RealChute version...

I will continue to use terrainAltitude as I suspect the only time it will not equal pqsAltitude is when the body doesn't have a pqsController (I suspect pqsAltitude will be -1 in that case but terrainAltitude may still have a "correct" value).

[stupid_chris]

Well, I've spent a couple of hours flying and driving various craft around various hilly places on Kerbin, Mun and Minmus and terrainAltitude is always the same as pqsAltitude. I suspect that Squad have changed something since your early RealChute version...

I will continue to use terrainAltitude as I suspect the only time it will not equal pqsAltitude is when the body doesn't have a pqsController (I suspect pqsAltitude will be -1 in that case but terrainAltitude may still have a "correct" value).

I'm using a null checker on the body pqs and I dare not to disregard the tips of the creator of PQS

[Padishar]

I'm not suggesting that vessel.pqsAltitude isn't "correct" (for bodies with a pqsController) but I suspect that terrainAltitude was changed at some point to simply call pqsAltitude.

As for not disregarding tips from the creator of something (and you can stick your tongue out all you like) but I've seen far too many cases over the years where official documentation and/or direct advice from the creators of an API has been plain wrong. In this particular case, you are suggesting that terrainAltitude is inaccurate but terrainAltitude is not part of PQS, it is a property (or member variable) of the Vessel class and could easily have been changed at some point without the creator of PQS knowing or changed since he gave you that advice...

[pizzaoverhead]

Back in 0.18.2, I did some test flights recording the various altitude fields. Results:

Key:

• Blue: altitude. Standard above sea level altitude.
  
• Orange: pqsAltitude. Has similar values to terrainAltitude, but with an offset that varies with value.
  
• Yellow: heightFromTerrain. The "how close am I from crashing into the terrain or buildings" value. It reads -1 when the sea depth is >= 600m.
  
• Green: heightFromSurface. Was always -1 during atmospheric testing. It likely shows more interesting values when in orbit.
  
• Brown: terrainAltitude. The height above or below sea level of the terrain or buildings.

The graph is a flight taking off from the runway and then flying to the airfield islands. The three tall brown (terrainAltitude) peaks in the middle are when flying over the islands. The small square-edged bumps at the right are flyovers of the VAB. The curved dips in terrainAltitude after takeoff and on returning to the mainland are unexplained.

Edited March 21, 2014 by pizzaoverhead

[Padishar]

Interesting... The first little dip after initial takeoff looks very much like you took off, crashed into the water just after takeoff and then reverted (maybe data from a previous run?). The much larger dip at the right end looks like you strayed back out over the ocean. The bit about 2/3rds of the way when the terrain comes out of the water to ~180m and then drops suddenly to the flat value (presumably the runway) is strange. I can't think of any good reason for that unless the surroundings of KSP had some odd features back then. It looks like you landed back on the runway from over the water and then took off for a bit of a fly around KSC.

While I was testing I found that heightFromSurface was always -1 even in orbit around Mun. heightFromTerrain also always read -1 in orbit around Mun. A rocket launch from KSP (staying over land) starts reading -1 for heightFromTerrain once you get into the upper atmosphere (about 50km). Landing on Mun from 40km up the value reads -1 until just over 20km and then reads correctly though it switches to -1 if you timewarp.

[pizzaoverhead]

The yellow line is the altitude above obstructions. You can see a take-off, followed immediately by a landing, but the terrainAltitude dips before that. The aircraft was not on or below the ocean in this flight, nor did any reverts take place. There were no odd features; the sudden curved dip on both sides is an anomaly of some sorts. heightFromTerrain seems to give accurate readings until the geometry it is using is removed, after which point it reads -1. It seems to be possible to construct the heightFromTerrain values using Altitude and either pqsAltitude or terrainAltitude. I wonder would this method show the same inaccuracy that stupid_chris saw. Perhaps the slight difference between pqsAltitude and terrainAltitude is the significant factor here.

[USAGuerrilla]

Any resolution on this item? I was checking Unity docs and it seems you can do collision detection using different means. Not sure if we can change KSP code to enable water ray casting detection.

[Diazo]

I use celestialBody.ocean as a work around for this in my Landing Height mod.

If a body has an ocean and the distance the raycast returns is greater then our altitude, we've hit the seabed with our raycast, so:

If (SOI.ocean && rayCast.hit.distance > vessel.ASL)
{
print("Ray Cast Hit water!");
}

D.

[USAGuerrilla]

Is it a valid assumption that radius for the planet == where ocean starts? So on altitude 0 there is always an ocean? I only been to main planet (and moons, which don't have oceans). So couldn't test my theory yet. Oh well. Need to create measurement equipment and send a satellite to the planet with the ocean! Woo hoo science project!

(I did ray intersection with the sphere to get range in case my range finder is tilted).