Question Surface base elevation question

[Usquanigo]

I just spent some time searching and wasn't able to find much.

I understand that Orbiter 2006p1 renders all planets as smooth spheres, and that's why we have Orulex and that other libProcTer(?) that are trying to add elevation features to planets and such.

But my question is... let's say I wanted to build a base at a location that is above sea level (say 3,500ft to a mile or so), would there be any work around to provide that advantage to rockets taking off? (thinner air, some elevation already provided so not as far to go, etc)

 

[Tommy]

You'ld need a 3-d terrain mesh, could be a "base" mesh rather than a "planet" mesh if you know what I mean. It may look funny, since the rest of the planet will still be a shere, and a base mesh isn't usually very large in the geographic sense.

A launchpad (done as a vessel) could have it's touchdown points set so that the tower appears at the correct altitude to match the mesh, and made to release the rocket upon throttle-up.

None of that helps with runway use for takeoffs and landings, though. You could use whatever technique was used on the Shukra station, but it's not perfect. Also, there's isn't a "radar" altimeter so it will require memorizing the base's altitude since you won't otherwise know your altitude above ground level.

 

[Hielor]

Also, there's isn't a "radar" altimeter so it will require memorizing the base's altitude since you won't otherwise know your altitude above ground level.

This is how it works in the real world.

 

[Tommy]

Most of the planes I've been in had a radar alt. Of course, the Vintage planes often don't, unless it's added on - which kind of ruins the whole "Vintage" appeal!

I assume many small private planes also don't have a radar alt, either. Flight maps are marked with the altitude of the airports, but not RLA's. Since you need permission to land at a RLA (barring emergency, of course) that's rarely a problem since anyone who lands there already knows the alt.

And being able to use depth perception IRL helps make estimating altitude easier than on a 2-D screen.

 

[Usquanigo]

And being able to use depth perception IRL helps make estimating altitude easier than on a 2-D screen.

If the graphics engine is good enough, you can get pretty good at that, from landing on high mountain bases to trapping on a carrier to flying under a bridge at high speed in IL2.

So.... design a whole base mesh you say? Eeep. That's way out of my league right now (and I hadn't even thought about it being possible actually). But I guess that's where it stands.

I think I'll just work on the layout of the base for now on a flat plane. I would imagine it to be made so anyway since the mountain/mesa area is pretty rough. But part of the point of choosing the location was it's combination of altitude and longitude. (all part of this crazy idea I'm cooking up lol)

 

[ex-orbinaut]

You could try the meshland add on for these purposes? I have not attempted it yet, but I do want to make Quito airport some time.

http://www.orbithangar.com/search_quick.php?text=artlav&StartRow=31

Most of the planes I've been in had a radar alt. Of course, the Vintage planes often don't, unless it's added on - which kind of ruins the whole "Vintage" appeal!

I assume many small private planes also don't have a radar alt, either. Flight maps are marked with the altitude of the airports, but not RLA's. Since you need permission to land at a RLA (barring emergency, of course) that's rarely a problem since anyone who lands there already knows the alt.

And being able to use depth perception IRL helps make estimating altitude easier than on a 2-D screen.

New light aircraft are sometimes better equipped than some of the even slightly older airline aircraft still in service. The latest Cessna T-182T, T-206H or Caravan, for example, have a complete Garmin G-1000 IA system, with synthetic vision, TAWS (better than a radar alt or EGPWS), VNAV and an autopilot that does just about everything except buckle up your seat belt! Reliability of the newest versions of the system is also vastly improved. Take a look....

https://buy.garmin.com/shop/shop.do?pID=6420#g1000

 

[ar81]

I just spent some time searching and wasn't able to find much.

I understand that Orbiter 2006p1 renders all planets as smooth spheres, and that's why we have Orulex and that other libProcTer(?) that are trying to add elevation features to planets and such.

But my question is... let's say I wanted to build a base at a location that is above sea level (say 3,500ft to a mile or so), would there be any work around to provide that advantage to rockets taking off? (thinner air, some elevation already provided so not as far to go, etc)

Planets are textured spheres that are created with DirectX7, and they are composed by triangles, so at some points the base may look like floating, because triangles are flat.

Surface bases are drawings on a second layer, above planet layer.

Orbiter was not designed to have mountains, since planets are just spheres, something Artlav tried to change with Orulex addon.

It causes problems if you have Valles Marineris under the surface or if you want to put a rocket on top of a mountain, because meshes are not detected as surface, since there is no default mesh collision detection in Orbiter.

 

[Usquanigo]

Planets are textured spheres that are created with DirectX7, and they are composed by triangles, so at some points the base may look like floating, because triangles are flat.

Surface bases are drawings on a second layer, above planet layer.

Orbiter was not designed to have mountains, since planets are just spheres, something Artlav tried to change with Orulex addon.

It causes problems if you have Valles Marineris under the surface or if you want to put a rocket on top of a mountain, because meshes are not detected as surface, since there is no default mesh collision detection in Orbiter.

Yes, I know that. That's why I started this thread.

Precisely because there are no mountains, and that there is no collision detection at all (internally), how then can one "simulate" the effects of a base several thousand feet above sea level?

Alternately, I guess the question could be, just what impact being 4500 feet up to start would actually have. I don't have the numbers, but in my head, it seems to make sense that everything would benefit from the thinner air. Especially if you're using a horizontal craft and something like the DeltaCannon.

Using something like Meshland or the more confined version of it that Artlav came up with, I suppose I could try to make the base itself and some of the surrounding mountain at the right height, but that is way beyond me. I am no 3D modeller.

That idea Tommy mentioned sounds neat too, at least for a rocket. But I'm not sure how to go about that either.

Just sort of general digging for info and brainstorming.

 

[fort]

Bloodspray,

Take a look at Terranim8or or some others programs like that. It is ( Terranim8or at least ) easy to understand and use and you can later load your file in Anim8or and texture it.

If you add meshland to that ( but i do not know if there is limits in it about the height and the altitude of a meshe ) you could have a beginning of success.

Actually i send a mesh from a base to the antipod ( antipode in french ) so if your base is only 4500 feet up, it's the surburb...

 

[ar81]

If you bring a craft to the top of the Everest you may save a few seconds only. Space shuttle requires 2 minutes to reach about 40 kilometers.
I think it is more useful to launch from equatorial orbit.

 

[Pablo]

Most of the planes I've been in had a radar alt. Of course, the Vintage planes often don't, unless it's added on - which kind of ruins the whole "Vintage" appeal!

In real life, radar altimeters are used only for some IFR final approaches or to avoid terrain collisions. In all cases, even with the most sophisticated instruments, you will need to use by regulations (on Earth, that is...) a barometric altimeter set to values known as QNH and QFE. QNH is standard used in everything except ULM aircraft in Western countries, while QFE is also used in big planes in Russia and other coutries that follow Russian standards.

Essentially, when you set a barometric altimeter to QNH values, you will see in the dial the elevation of the airport you are in while still on the ground, while using a QFE you will see zero. i.e. the airport where I fly off most of the time is just 16 feet ASL. By setting the altimeter on QNH before taking off, I will read 16 feet; if I use QFE, I would read 0.

This means that a Radalt would give you a reading that is in some respects, conceptually similar to a QFE. The main difference between the two would be that if you have a Radalt you could perform some sort of terrain following flight path, while it would be dangerous to do so based just on QFE.

QNH and QFE are given to you by ground controllers because they are calculated based on data coming from meteo stations that might or might not be local. Those are the standards used in aviation still today, not Radalt.

Perhaps it would be nice to implement those in Orbiter; MSFS has them. But I think that they would be of rather limited value in other worlds like Mars.

 

[4throck]

If you reduce the planet sphere's diameter and then ADD the terrain altitude, via Orulex for example, the below sphere problem with the lower parts of the planet can be solved. Of course, instruments would still give you a wrong reading. Another thing that could be tried would be to define a landing pad as a spacecraft with a docking port. That would give you correct distance figures at least.