Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Stainless]

Hmmmm think I may be a bit below glide slope




So that's ALSF 2  done, just ALSF 1, Calvert, Calvert Cat II, SSALR, SSALF, SALS,MALSR,MALSF,MALS,ODAL, and RAIL to do.......

 

[Stainless]

In preparation for testing some lighting algos, I have added a scattered sky.

But now I am worried I have got the ALSF 2 wrong.

Should the gantries that hold the approach lights go up with the glide slope?

Doesn't look right to me.

[Pursuivant]

Should the gantries that hold the approach lights go up with the glide slope?

Yes, at least in some cases, the approach light towers get lower as you approach the end of the runway:

https://upload.wikimedia.org/wikipedia/commons/thumb/f/f3/Approach_lights_at_EFJY_20120818.jpg/1024px-Approach_lights_at_EFJY_20120818.jpg

You can see the way that the height of the light towers taper off in the side views in this illustration:

http://www.rainierflightservice.com/blog/wp-content/uploads/2011/01/approach-lights.jpg

Sometimes, the lights will follow the contour of the terrain, so they retain a more or less constant height, as shown here:

https://i.stack.imgur.com/Kd3xE.jpg

Your ALSR2 lights might look wrong because the towers might be spaced too far apart.

As for the number of lights, while your lighting looks great for a 1940s or 1950s airport, big 21st century commercial airports are lit up like Times Square on New Years Eve. If you want to be brutally realistic, you will need to step up the number of possible individual lights by a couple of orders of magnitude (8,192? 16, 384?) to cover all the lights associated with landing systems and runways for a major commercial airport.

That assumes that you're mapping each light individually. You might be able to simplify things by using the ICAO standards to generate algorithms for the appropriate number and type of lights (e.g., treating each ALSF tower or treating each line of runway edge lights as a single "light").

Figuring out the "fiddly bits" for less common or obsolete landing systems seems like another job for future fans of your best-selling flight sim. As long as you define the broad parameters, make provisions for a particular system to be added, and make it easy for fans to "mod" the basic program, that's good enough for now.

[Stainless]

The distance between the towers is spot on, I used the official standards document to place them. I am starting to think it's just my projection matrix is wrong.

I just used a 45 degree field of view as it is what I grew up with (easy maths , 45 degrees means you can just do a (x > z) || ( y > z) visibility check)

Think I will change it and see what it looks like.

The next thing I want to add before I start messing with the N other approach lighting systems is things like runway centre lights , landing zone lights, that sort of thing.

This will give me a really good idea of how many lights I am going to need to support in the actual game.

[Unca-Fester]

Both of those are easy to export, though both will have duplicate geometry for objects.

No mesh instancing

Duplicate Geometery? I'm not sure what mesh instancing is.

P.S.  Have you thought of using FlightGear's base Airport models to speed up the process of populating modern airports? Other than converting the image formats from .png to .tga, most if not all of FG airport 3D files are in .ac format.

[Stainless]

Yes I will probably grab some of them, but they need detailing.

AC format is easy to read.

Mesh instancing is a graphics technique used a lot nowadays. Say you have 100 lights in a scene, all with the same geometry. The same mesh.

It is very wasteful to send all the geometry to the graphics card 100 times.

Instead you send the geometry once, and send 100 world view projection matrices.

This is incredibly fast compared to the original technique.

[Stainless]

Well whoever suggested using flightgear as a data source sure took over my mind.

So I downloaded the terrain database, decoded the data structure, wrote parsers for all the files, wrote scanners, and display code and ran the editor.

Nothing. Not a single pixel.

I scratched my head for a while, had a cig, drank a beer, then suddenly I realised my mistake.

Each object has an elevation stored in the data. This elevation is based on the terrain. I am just using the elevation in the airport data.

The two are not the same.

So after altering the objects elevation to match the airports elevation I started getting weird objects popping up.






They don't look quite correct yet, but they are there.

[Stainless]

These is getting extremely frustrating.

The objects are there, they are the correct size now, but everything looks just a little out of position.

Really annoying me.

I have Latitude, Longitude, and Heading.

Should be trivial, but it isn't......










If anyone knows Shoreham (EGKA) could you have a look at tell me how far out I am please.

And yes I know that is a boat, not sure why it is there either......

[Stainless]

So this is damn frustrating

This is the official map of the airport





And this is my map.






Pretty close.

But when you swap to 3D and look at the objects..... not right







I ONLY HAVE LOCATION AND ORIENTATION!!!! HOW CAN IT BE WRONG ????

[whistler]

If you alter the orientation slightly, do objects rotate only or do they also relocate a little? Perhaps their rotational pivot point is not at the center. But you would have figured this out already I am sure

[Stainless]

All I have is

OBJECT_SHARED lines
Adds shared objects to the tile.

Example:

 OBJECT_SHARED Models/Airport/tower.xml -122.501090 37.514830 15.5 0.00
Syntax:

 OBJECT_SHARED <object-path> <longitude> <latitude> <elevation-m> <heading-deg> <pitch-deg> <roll-deg>
<object-path> is relative to the data directory (FG_ROOT).
<longitude> and <latitude> are in degrees using WGS-84 standard coordinate systems, available from most online-maps.
<elevation-m> is in meter and relative to mean sea-level (in the fgfs world).
<heading-deg> is in degree, counter-clockwise with North being 0.0.
<pitch-deg> and <roll-deg> are in degree and optional.

Apart from the heading being in a stupid format ..... should be simple.
 

[whistler]

You probably have to apply a small factor to get the heading (yaw I supposed) right?
 
I would play with Models/Airport/tower.xml -122.501090 37.514830 15.5 0.10 0.10 0.10 values and see if these do what they are supposed to do. Location of the objects seem pretty accurate (from a global scale), you are just missing a small adjustment.

If you get the objects manually positioned into place, probably the values used will tell what is missing and/or where..