Interesting discussion. By the way, I highly recommend
http://xplanescenery.blogspot.com/ Ben Supnik is the main graphics guy for
XPlane and a very good writer; obviously they encounter many of the same
issues.
Terrain rendering has quite a bit of headroom in terms of raw number of
polygons. That part of the "rendering engine" is reasonably well optimized.
But there are good reasons not to carve polygons into the terrain for every
taxiway marking. Curt makes a very good point about aliasing of sharp
features vs. blurring of the same features when viewed close up.
Intersection queries can be a real bottleneck if we are not careful. Mathias
did a lot of good work to optimize these queries without any change to the
.btg format by building "bounding volume hull" trees at load time. I think
we could gain performance by pushing some of this work back to scenery
generation time.
One of the problems we have with bumping up the polygon count is that we
don't have an LOD scheme for terrain, and creating one is hard because our
terrain skin is irregular.
I've said before that the best way forward is to have a very regular
height-field for terrain and generate the textures for areas of terrain
on-the-fly. This will be a lot of work for someone.
Airports don't need to handled in the same way as "normal" terrain. They
could be treated more like a complex model with arbitrary geometry.
We have access to many texture units these days, so not everything has to
be baked into a single texture.
Tim
On Tue, Jan 18, 2011 at 5:26 PM, Curtis Olson <curtol...@gmail.com> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
