Here's my 2 cents:
If we cut all the curves and lines and markings into the base triangle mesh:
- Huge polygon count (large file sizes, memory footprint, etc.)
- Lots of problems with aliasing along all the line edges
- All the lines and markings will have very sharp edges. (Good if we want
to zoom in forever, but not so good from the standpoint of realistic
visuals.)
- slow terrain intersection lookups (?)
If we draw all the lines and markings on a separate layer above the runway:
- This is a common approach.
- Possible z-buffer fighting issues (which can look really bad)
- GLPolygonOffset can counter z-buffer fighting, but historically it's not
been implemented consistently by vendors so it's hard to get consistent for
everyone.
- FlightGear has non-flat runways so it's hard to cheat and just use draw
order tricks (or we could see the markings that should be obscured behind a
rise in the runway.)
- Still, this may be the most promising approach we have available to us ...
We could cook all the markings into custom textures for each airport.
- This has the advantage of no z-buffer fighting, and no hard edges on the
markings and no crazy edge aliasing problems. (Look at a power pylon from a
distance as you fly if you wonder what I mean by edge aliasing problems.)
- Would require a much bigger texture foot print.
- Would require much bigger texture storage (unless we could figure out a
way to render/generate textures on the fly.)
- Probably wouldn't be very high res, so close in ... like when taxiing or
taking off, we could have big problems with the whole texture just bluring
out and making the marking hard or impossible to distinguish from the rest
of the blurry mess.
- This approach could have the advantage though of being able to cook all
kinds of extra details into the custom textures for each airport (skid
marks, pavement flaws, paint chips, all kinds of fun stuff ...)
- I like thinking about this approach if we could get enough texture
resolution so the results aren't too blurry when the aircraft is on/near the
ground.
Curt.
On Mon, Jan 17, 2011 at 3:01 PM, Martin Spott wrote:
> Frederic Bouvier wrote:
>
> > As John said, the missing bit is scenery generation.
>
> I think it's a split task. As with almost every technical problem,
> there is _some_ way to a solution .... ;-)
>
> I'm certain we'd find a reasonable way of nicely casting the new
> X-Plane layouts into Terrain tiles without the triangle count or other
> ressource requirements going through the roof - but this is most likely
> letting us end up with something that FlightGear can't parse :-)
>
> Basically (at the risk of triggering another pointless debate) I think
> there are two problems to solve:
> a) There would be the need for supporting more 'complex' geometries in
> FlightGear Terrain, like polygons (at least) instead of triangles, at
> least until shortly before the rendering stage, to save FlightGear from
> sorting countless triangles just for one simple elevation lookup. An
> alternative solution would be to make extremely high triangle counts
> extremely cheap :-)
> b) There would be the need for drawing line features, the yellow
> taxiway lines in particular, _on_top_ of the existing runway, taxiway
> or apron textures.
>
>
> The funny side of the issue: We're not the only ones struggling with a
> 'proper' design for smooth airfield layouts:
>
> Two years ago I've been working on a (I think rather small) side
> project which involved using a custom airfield layout for in-house
> research at NASA (Ames).
> Beause they didn't have a proper solution for b) either, these folks
> decided for their OpenFlight database to add a distinct layer
> containing just the yellow lines - and to mount these approx. a dozend
> centimeters above the tarmac .... resulting in the well-known z-buffer
> fighting which you'd expect when placing flat geometries slightly above
> the terrain surface :-)
>
>
> As a consequence I suspect that most of the _infrastructure_ work for
> properly supporting modern X-Plane formats would affect FlightGear. I
> _do_ know that FlightGear is pretty much designed around having
> triangulated Terrain, therefore I don't expect the current state to
> change soon. The respective part in TerraGear might be comparably
> small, but still would require a change to the file format (unless
> extremely high triangle counts are becoming extremely cheap ;-))
>
> Cheers,
> Martin.
> --
> Unix _IS_ user friendly - it's just selective about who its friends are !
> --------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/<http://www.flightgear.org/blogs/category/personal/curt/>
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
