Discussion Default bases surface tiles

[4throck]

What makes you think I've changed my mind?
I don't control what goes into the default distribution , so my only objective is to do a nice work and to get it finished. The separate releases will help in getting things organized and not to rush just because I want to get things done.
And if they are done... there's no point in keeping them to myself, is it? :thumbup:

 

[4throck]

OK, got the North America bases finished.

But I've hit on one problem: on some bases, distant pads appear elevated - about 50 meters above ground. Runway lights are also affected. Vandenbergh, that covers a large area, suffers from this. Of course, I'm using "MAPOBJECTSTOSPHERE = TRUE"

I guess that it has something to do with the fact that the earth is round :thumbup:.
Strangely enough, the blocks and runways are not affected.

Any advice? I can make the offending pads invisible...

 

[BruceJohnJennerLawso]

OK, got the North America bases finished.

But I've hit on one problem: on some bases, distant pads appear elevated - about 50 meters above ground. Runway lights are also affected. Vandenbergh, that covers a large area, suffers from this. Of course, I'm using "MAPOBJECTSTOSPHERE = TRUE"

I guess that it has something to do with the fact that the earth is round :thumbup:.
Strangely enough, the blocks and runways are not affected.

Any advice? I can make the offending pads invisible...

Well, I dont think many people do powered Earth vertical landings in orbiter, so why not eliminate them & create some nice hangar facilities for each? That would be a lot more poular IMO. Good work, cant wait :tiphat:

 

[dgatsoulis]

OK, got the North America bases finished.

But I've hit on one problem: on some bases, distant pads appear elevated - about 50 meters above ground. Runway lights are also affected. Vandenbergh, that covers a large area, suffers from this. Of course, I'm using "MAPOBJECTSTOSPHERE = TRUE"

I guess that it has something to do with the fact that the earth is round :thumbup:.
Strangely enough, the blocks and runways are not affected.

Any advice? I can make the offending pads invisible...

For some reason, runway lights don't follow the mapobjectstosphere command.
If you check Cape Canaveral you will see that the runway lights have a negative Y position.
I checked the manual and it mentions "see Error! section" but I couldn't find such a section.

Anyway, I wrote a quick calculator that finds the elevation (since it's negative, is it depression?). You can use it in the link below. Don't touch any of the red text, that's where the calculation is made.

elevation calculator

All you have to do is enter your object's x and z coordinates (the same you use in the base's config, in Orbiter the order is xyz where y is the altitude) and it will give you the Y position of the object, in order to be 1 meter above ground.

It's not 100% accurate because I'm using an approximation, but the differences from the "correct" value are small.

The example you see when you open the link, is from END2 of this runwaylights at cape canaveral

RUNWAYLIGHTS
	END1 -8220 -3 -600
	END2 -12670 -12 -3155
	WIDTH 100
	PAPI 20.0 3.0 -2000
	VASI 1.5 152 671
END

 

[astrosammy]

How did you get to that formula? I just had to do the same thing for a taxiway mesh. It works (link), but it's alway nice to see how others solve a problem.

 

[dgatsoulis]

How did you get to that formula? I just had to do the same thing for a taxiway mesh. It works (link), but it's alway nice to see how others solve a problem.

I used an approximation, since the distances are quite small relative to the Earth's circumference.
Here is a pic of the calculation.

A correct calculation that would also be lattitude dependent would be more lengthy* and in my opinion unnecessary for the purpose of placing a runway light a few kms away from the center of the base.

*for my level of math. There could be another much simpler solution that I am not aware of.

 

[csanders]

Does anyone have a list of objects that are successfully mapped with "mapobjectstosphere," and which aren't? I could do the calculation automatically in the next version of OBM.

 

[dgatsoulis]

Does anyone have a list of objects that are successfully mapped with "mapobjectstosphere," and which aren't? I could do the calculation automatically in the next version of OBM.

I checked all the objects from the OrbiterConfig.pdf list and these are the ones that appeared elevated at position 5000 0 5000 with mapobjectstosphere=true (The ones that have end1 and end2 were tested at positions 5050 0 5050 and 4950 0 4950 respectively).

LPAD1
LPAD2
LPAD2A
BEACONARRAY
RUNWAYLIGHTS
SOLARPLANT
TRAIN1
TRAIN2*

I am not sure about TRAIN2 because it's supposed to be elevated (default 11 meters), but compared to position 0 0 0 the "supports" were higher, so I'm guessing it doen't get mapped either.

 

[orb]

I am not sure about TRAIN2 because it's supposed to be elevated (default 11 meters), but compared to position 0 0 0 the "supports" were higher, so I'm guessing it doen't get mapped either.

Neither of train lines are mapped to sphere (and they are flat).

 

[4throck]

Thanks for the input. Negative altitude is the solution then :thumbup:

Just to tease you some more ;-) and regarding why have the pads on the first place:

Here's part of Vandenberg. IMHO the pads make sense, because those are the actual launch locations of many rockets.
You can launch the DG from there, or things like Velcro rockets. To land you have the runways
(and if you are using add-ons that feature detailed launch pads, there's no problem. The pad mesh will cover the default one on the ground )

---------- Post added at 19:10 ---------- Previous post was at 17:42 ----------

And here are the North America Bases :thumbup:

https://rapidshare.com/#!download|622p6|2571062028|default_north_america.rar|9698|0|0

Download and enjoy. Please remember that this is intended to be installed over a fresh Orbiter setup. And of course, it will overwrite your bases so don't say I didn't warn you!


Now I'll move on to the other continents.

 

[dgatsoulis]

Thanks 4throck, downloading now.

Thanks for the input. Negative altitude is the solution then

Yes and you can use the calculator of post #44 to find how much negative altitude you are going to need for any object, just by using it's x and z coordinates from the config file (or OBSM).

 

[4throck]

That's what I used. :thumbup: Works perfectly!

 

[ADSWNJ]

I used an approximation, since the distances are quite small relative to the Earth's circumference.
Here is a pic of the calculation.

A correct calculation that would also be lattitude dependent would be more lengthy* and in my opinion unnecessary for the purpose of placing a runway light a few kms away from the center of the base.

*for my level of math. There could be another much simpler solution that I am not aware of.

There's a similar formula for this correction for this inside Glideslope 2. Essentially it says:

Create a NRE vector (North offset, Radius of Earth center, East offset). Optionally add on the local altitude to the radius (R = RE + ALT). (e.g. Kennedy 15/33 is at 2.60m ALT. Calculate vector length L = SQRT(N^2 + R^2 + E^2). Scale vector by R / L.

Note, however, that this and the dgatsoulis equation assume a spherical earth. The equations for a more realistic oblate spheroid shaped Earth (slight bulge at the equator) from the WGS-84 standard are described in this document I've been studying:

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=0CFsQFjAG&url=http%3A%2F%2Fwww.dsto.defence.gov.au%2Fpublications%2F3951%2FDSTO-TN-0640.pdf&ei=5nrfUKLFDJKN0QG47IHADQ&usg=AFQjCNEOtiXkgOA0hqn7BSTIw_1H_wkckg&bvm=bv.1355534169,d.dmQ&cad=rja

---------- Post added at 11:41 PM ---------- Previous post was at 11:24 PM ----------

For some reason, runway lights don't follow the mapobjectstosphere command.
If you check Cape Canaveral you will see that the runway lights have a negative Y position.
I checked the manual and it mentions "see Error! section" but I couldn't find such a section.

The example you see when you open the link, is from END2 of this runwaylights at cape canaveral

RUNWAYLIGHTS
	END1 -8220 -3 -600
	END2 -12670 -12 -3155
	WIDTH 100
	PAPI 20.0 3.0 -2000
	VASI 1.5 152 671
END

Those parameters for PAPI and VASI are not cords.

For PAPI (Precision Approach Path Indicator), the numbers are the glideslope angle (20.0º here), the cone (3.0º), and the offset from the front of the runway (-2000.0 meters here).

For VASI (Visual Approach Slope Indicator), the numbers are the glideslope angle (1.5º here), the distance between the white and red lights (152 meters here), and the offset from the start of the runway (671 meters).

The reason for the negative 2km offset on the PAPI is for the shuttle's outer glideslope on final. This idea is you fly to a point 2km short of the runway, on a steep 20º descent, then pick up the 1.5º inner glideslope to glide to a really smooth touchdown.

The VASI for the Shuttle is actually a Ball/Bar system rather than a VASI, meaning the white light (the Ball), is supposed to straddle a row of red lights (the Bar). If the white is high, you are above glideslope, and if low, low. Hence the audio sample in FSIM saying "you're coming down on the ballbar" as transcribed here: http://f-sim.com/forum/viewtopic.php?f=8&t=646. It would be cool if the RUNWAYLIGHTS definition could have a BALLBAR parameter instead of a VASI parameter!

 

[4throck]

I didn't setup any PAPI or VASI but it certainly could be done, as I found some info on it regarding some runways.

Right now, I'm finishing the 4 bases in Africa: Gran Canaria, Hammaguira, Overberg and San Marco. San Marco is interesting because it is an oil platform out on the sea!

 

[dgatsoulis]

There's a similar formula for this correction for this inside Glideslope 2. Essentially it says:

Create a NRE vector (North offset, Radius of Earth center, East offset). Optionally add on the local altitude to the radius (R = RE + ALT). (e.g. Kennedy 15/33 is at 2.60m ALT. Calculate vector length L = SQRT(N^2 + R^2 + E^2). Scale vector by R / L.

Note, however, that this and the dgatsoulis equation assume a spherical earth. The equations for a more realistic oblate spheroid shaped Earth (slight bulge at the equator) from the WGS-84 standard are described in this document I've been studying:

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=0CFsQFjAG&url=http%3A%2F%2Fwww.dsto.defence.gov.au%2Fpublications%2F3951%2FDSTO-TN-0640.pdf&ei=5nrfUKLFDJKN0QG47IHADQ&usg=AFQjCNEOtiXkgOA0hqn7BSTIw_1H_wkckg&bvm=bv.1355534169,d.dmQ&cad=rja

More elegant method and an interesting read, thanks.

I was under the impression that Earth's shape was modeled in Orbiter, so I looked up how to get the lattitude dependent Radius in order to correct the previous (lazy) calculation. (And also find the true distance to the object, instead of assuming that it's equal to the chord).

Before making the calculation, I wrote a quick script in lua that returns the angular distance from the center of the base and distance from the center of the planet (in meters), so that I had a way to check if the calculation was correct. But when I run a test scenario, no matter what the lattitude was, the R was always 6371012.57 m.

2.57 meters is the altitude offset of the default DG that I used in the scenario, so that means that in Orbiter, Earth is modeled as a perfect sphere with R 6371010 m.

Those parameters for PAPI and VASI are not cords.

For PAPI (Precision Approach Path Indicator), the numbers are the glideslope angle (20.0º here), the cone (3.0º), and the offset from the front of the runway (-2000.0 meters here).

For VASI (Visual Approach Slope Indicator), the numbers are the glideslope angle (1.5º here), the distance between the white and red lights (152 meters here), and the offset from the start of the runway (671 meters).

The reason for the negative 2km offset on the PAPI is for the shuttle's outer glideslope on final. This idea is you fly to a point 2km short of the runway, on a steep 20º descent, then pick up the 1.5º inner glideslope to glide to a really smooth touchdown.

The VASI for the Shuttle is actually a Ball/Bar system rather than a VASI, meaning the white light (the Ball), is supposed to straddle a row of red lights (the Bar). If the white is high, you are above glideslope, and if low, low. Hence the audio sample in FSIM saying "you're coming down on the ballbar" as transcribed here: http://f-sim.com/forum/viewtopic.php?f=8&t=646. It would be cool if the RUNWAYLIGHTS definition could have a BALLBAR parameter instead of a VASI parameter!

Thanks for the additional info on the PAP and VAS indicators. I'm trying to create a challenge for an unpowered reentry and landing on a runway, so that's going to be very useful.
The coordinates in the calculation are actually for the END1 and END2 of the lights, the indicators are optional and they offset themselves by the amount you explained in your post.

 

[4throck]

And here are the Africa bases (Gran Canaria, Hammaguira, Overberg and San Marco). San Marco is of course impossible to do with the default base objects, because it's an oil platform! But I included it, for completeness.

This is a screenshot from Overberg, just to tease you :thumbup:

Get it here: http://rapidshare.com/files/3888067706/default_africa.rar


Next will be the European bases, perhaps in a joint release with Australia and/or South America.

 

[ADSWNJ]

Forgive a bit of deep fascination with the precision of the KSC22/KSC15 runway...

I was doing some coordinate checks to confirm my conversion factors between LLR (lat/long/radius), ECEF XYZ (Cartesian cords), Base North/East cords used in RUNWAY and RUNWAYLIGHTS definitions, and my internal NRE (North/Radius/East) cords from fixed XYZ points. We have the coordinates of the Kennedy 15/33 runway off by quite a few feet.

Have a look at these references in Google Maps on the most detailed aerial zoom, then one zoom more into street view on the runway! (Cool btw!!):

Current Coords:


NEAR END (KSC33): 28.594724 -80.681145
FAR END (KSC15): 28.634740 -80.707327
PAPI (for KSC33): 28.579126 -80.670946
VASI (for KSC33): 28.599957 -80.684568


Some observations:
1. The runway has a 1000ft (304.8m) blast pad on each end, marked with yellow chevrons prior to the runway threshold (with the full set of piano keys on it).

2. We appear to be marking the runway in Orbiter as the full length including the 2 blast pads.

3. We need a modeler guru (4th Rock perhaps) to paint the runway with chevrons for the first and last 100ft please). (Or let me know if there are addons that do this already).


Assuming the reference points should be the start/end of the runway blast pads, then here's a new set of coords to about 50cm accuracy (anal retentive, I know, but it comes with the territory flying spaceships!):


NEAR END (KSC33): 28.594652 -80.681136
FAR END (KSC15): 28.635137 -80.707620
PAPI (for KSC33): 28.581540 -80.672550
VASI (for KSC33): 28.602260 -80.686100


Converting these to base-relative coords, I come up with the following:


RUNWAY
END1 -8212 0 -599
END2 -12714 0 -3183
...

RUNWAYLIGHTS
END1 -8212 -3 -599
END2 -12714 -12 -3183
WIDTH 100
PAPI 20.0 3.0 -1682
VASI 1.5 152 974
END


I'd love for anyone to check these coords and verify please!

 

[4throck]

I understand and appreciate the attention to detail. But be cautioned that all online mapping services are unacurate. When Google changes the satellite photos, the ground "shifts" by a good amount.

Yet that technical information is welcome and really belongs on the Orbiter Wiki. :thumbup:


In my opinion, I think that things like custom textures or centimeter accuracy belong in specialized add-ons. On this case, it could be a "accurate STS Canaveral" base. For specific periods/spacecraft, the best solution is a custom base/solar system.


Now back to the bases. Here's an overview of Plesetsk. This integrates OK with the new Angara add-on for example.

And here's Salto di Quirra:

 

[Ripley]

...Get it here...

Excellent work, and I'll download them all, but why aren't you uploading them at OH?

 

[C3PO]

Excellent work, and I'll download them all, but why aren't you uploading them at OH?

+1 :thumbup:

Stellar work!!!