Worldwind Scenery

[BrendaEM]

I think that utilizing Nasa's Worldwind terrain is the the way to go for Flightgear.

Presently, Worldwind is Windows only--this is not fair that the American people should pay extra for a proprietary monopoly operating system.

On WW's site, Sun made a demo for a flight simulator using WWs terrain--the demo is poor, but ask yourself, should not the same data be available for open source projects too?

Worldwinds terrain, would make an excellent starter terrain. The terrain IS large, but that's the point. Mirroring the terrain for Flightgear might be costly in bandwidth, but should all this come together, perhaps I can donate something toward bandwidth.

(And thank you for working on Flightgear.)

[Ampere]

There's an opensource multiplaform program that's similar in nature to both WorldWind and Google Earth, and it's called OssimPlanet (formerly osgPlanet). I think it uses WorldWind database, and theoretically, FlightGear could make use that for terrain visualization.

Realistically speaking though, I don't see the possibility of FlightGear switching from the current scenery system. Aside from the difficulties of modifying FlightGear to use the new sceneries, I think too much effort has been put into FlightGear's own scenery generation program and that there would be a huge resistance to abandone it.

[BrendaEM]

I am not suggesting to totally abandon the current scenery system, but to augment it with a base of scenery of WorldWind data. The current system can still be used for buildings, static and moving models, and airport overlays. The current scenery downloading website can be still used to download new areas.

Sadly, if Flightgear does not move forward in using real scenery, it's not going to make its mark.

[I realize X-Plane is still using tiled scenery, but how much longer can they do so, and stand against the upcoming MegaScenery add-ons?]

[I still miss FlightUnlimited 2 and 3 from looking glass. The scenery for the San Francisco bay area was more than adequate for VFR. The uncompressed data occupied 2 GB, but included dozens of airports. Most current computers have drives large enough to store thousands square miles of real scenery.

The computers that most serious flight-simmers use are more cutting edge than the average machine. ]

[Ampere]

I am not suggesting to totally abandon the current scenery system, but to augment it with a base of scenery of WorldWind data. The current system can still be used for buildings, static and moving models, and airport overlays. The current scenery downloading website can be still used to download new areas.

I was referring to the scenery building tool -- TerrarGear when I talked about abandonment.

FlightGear uses TerraGear to build the scenery that only FlightGear can understand. WorldWind also handles its own terrain data differently. So, to handle WorldWind data, the current scenery system would most likely need to be completely overhauled, which means TerraGear would no longer be used to produce the scenery thus becoming useless. Too much effort have been put into TerraGear that I don't think it would be abandoned for anything else.

Sadly, if Flightgear does not move forward in using real scenery, it's not going to make its mark.

If this is your actual question, then yes, FlightGear does use real scenery.

[BrendaEM]

Yes, I am suggesting the current scenery should be overhauled.

Why spend time creating vector overlays for streams and highways that are already represented in more accurate, and better appearing data?

I know that Microsoft might not like if Flightgear becomes all it can be, or someday earn FAA approval, but it should grow anyway.

The data is out there : )
Sometimes you have to wake up and smell the topography : )

[BrendaEM]

For hahas, I composited a picture with Worldwind's urban ortho scenery using the A-10 plane in Flightgear.

[Harald]

Since fg is using an irregular grid for the terrain, it can use a regular grid without changing a line of code (regular grid is a prerequisite to use any kind of photo scenery). Wait...that was done years ago, check the old ss on the site.
The truth is that photo scenery are mostly awfull. Sure you can show nice photos, they are nice only at the right altitude. So this could be a nice addition for some local scenery, but not for the golbal scenery.

HJ.

[BrendaEM]

Flight Unlimited 2, a ten year old program had good scenery at all altitudes except for at ground levels. That's where overlay textures work well.

This isn't perfect, but it's the last thing that pilot is going to see, because they aren't making it over that hill.


Should not Flightgear be able to equal this 10 year old effort?

[martin]

Flight Unlimited 2, a ten year old program had good scenery at all altitudes except for at ground levels. That's where overlay textures work well.
[...]
Should not Flightgear be able to equal this 10 year old effort?

Certainly, FlightGear even should get better. BUT, the decision, which route to take, should be made carefully. Simply putting loads of aerial and/or satellite imagery into FlightGear won't work out because neither your harddisk nor the memory bandwidth nor the graphics board in your computer will be able to handle it.
Look at this sort of 'flight simulation':

http://ossim.telascience.org/ossimdata/nhv/DSCF0129.JPG

They _are_ using images instead of tiled textures for their setup - and in order to handle the load they connect their display systems using 10 Gig Ethernet to a terribly fast storage system that holds _terabytes_ of imagery. Using images for a _very_ limited terrain area might work out, but for a flight simulator that comes with global scenery coverage and is supposed to run on desktop computers this is certainly not the right scale
The approach to get things working on small computers is a different one: Create a coverage using detailed polygons and fill these with tiled textures. The Custom Scenery Project:

http://www.custom-scenery.org/Satellite-Image.304.0.html

is aiming at developing tools to generate such polygon data - the development process is far from being ready for general consumption but things look quite promising. Actually, for OpenSource projects that have _so_ few developers - this is primarily a single person and I'm trying to arrange some support for him - you have to think in terms of years instead of months or weeks for such sophisticated and complicated development to get into a releasble state.

Regards, Martin.

[curt]

Let me add one more comment. You can make satellite scenery that looks great from 5000' above ground level, but for the transition to lower levels and landing/taxiing, this same scenery just turns into one big blurry unintelligable mush. Even if you get really high resolution imagery, you have the same problem. As you touch down, all that seemingly photorealistic 3d stuff just flattens out weirdly and disappears. What's worse, if there is a 737 taking off or taxiing in your image, it will always be there. Shadows, seasons, time of day, are all "cooked" into the imagery and can never be changed.

Adding 3d buildings and other objects so they mesh seamlessly with the imagery and don't cause artifacts or other weirdness takes immense manual effort. Cleaning up runways and taxiways takes immense effort.

This photo-real scenery can look awsome from the air, but the deeper you get into it, the more you realize it has it's own set of difficult and almost unacceptable limitations.

From a larger perspective, there's no problem building an alternate scenery engine for FlightGear. There is enough value to photo-real, that I'm not suggesting we never consider it. But there are tremendous problems and issues to overcome, not to mention the huge size of the imagery data.

Curt.

[martin]

From a larger perspective, there's no problem building an alternate scenery engine for FlightGear.

Actually I even _expect_ such thing to happen in the next one or two years.

What the Custom Scenery Project and I are currently working towards is making FlightGear's Scenery generation tools much more 'generic' while still maintaining compatibility with earlier data formats (like VPF/HGT). This allows us for example to use more accurate elevation data (SRTMv3 GeoTIFFs) or to read vector data directly from a PostGIS database in order to generate FlightGear Scenery.
A while later probably we'll have a loader for the current FlightGear Scenery format right inside OpenSceneGraph, collision detection will take place in OSG and as collisions occur (and for ground handling) FlightGear is just dealing with some callbacks from OSG.

The next consequence would be to allow FlightGear to load every terrain format that OSG has a loader for (like OpenFlight databases) or to let the OSG "VirtualPlanetBuilder" deal with terrain loading - which explicitly and intentionally includes the mentioned formats (GeoTIFF/PostGIS) which already can be used with the Custom Scenery Project's development branch of FlightGear's terrain tools.

Cheers, Martin,

[Ampere]

http://www.custom-scenery.org/Satellite-Image.304.0.html

is aiming at developing tools to generate such polygon data - the development process is far from being ready for general consumption but things look quite promising.

I am impressed. The project is very well documented so far.

[martin]

The next consequence would be to allow FlightGear to load every terrain format that OSG has a loader for (like OpenFlight databases)

Is this now possible that OSG is implemented in 1.9.1? Is there documentation on how to do this?

In Theory: Well, it's _almost_ possible to load arbitrary OpenFlight terrain databases. Getting the translation and projection right is still a bit tricky .... I'm involved into manually adapting a custom OpenFlight database for a paying customer but I don't expect any tutorial to show up as long as there are no tools ready for general consumption,

Martin.

[martin]

Is getting the translation and projection to work a FG issue or an issue with the openflight scenery format?

It's neither an issue with one or the other, it simply has to be done because FlightGear Scenery and typical OpenFlight databases usually are organized in different ways,

Martin.