Re: [Flightgear-devel] apt.dat format
Michael Sgier wrote: > it does not matter if I release my apt.dats ( Sion, Bern etc. ) under > GPL or not. [nonsense removed] Your interest in FlightGear, as far as I have learned from various sources, boils down to nothing but serving as a vehicle for you to build a payware add-on business ontop of it. There's nothing wrong about such a plan, as long as you properly comply with the license - you are certainly taking the license into account, don't you !? BUT, as long as you refuse to respect the rules of development on basis of the GPL, how dow do you even _dare_ to tell us what _we_ should take into account !? As long as you stick with this attituude, I think you'd probably better look out for another place to drop your recommendations at, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
it does not matter if I release my apt.dats ( Sion, Bern etc. ) under GPL or not. I'm undecided for now and would have to ask about the objects (Suisse 2004) to be GPLed anyway. A lot of new airports are not GPL and probably never will be. So something alike the x-plane approach with custom scenery should be taken into account. Only think about freeware like: http://sirx.flightsimulatorcenter.com/aeroporti.aspx But that's future music anyway...which would certainly attract crowds. As soon as the new format works I'll certainly try/experiment with the upcoming scripts from "radi" to convert x-plane sceneries. Cheers Michael On Tue, 3/30/10, HB-GRAL wrote: From: HB-GRAL Subject: Re: [Flightgear-devel] apt.dat format To: "FlightGear developers discussions" Date: Tuesday, March 30, 2010, 10:14 AM Michael Sgier schrieb: > I'm really looking forward to see new airports in FG, maybe on top of a new > scenery, Fred? > Hello Michael Thanks for your offer to help for a better scenery. Can you start to publish your airports/data/objects now under GPL? So others can also contribute and start to work on scenery around. Thanks- Yves -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Michael Sgier schrieb: > I'm really looking forward to see new airports in FG, maybe on top of a new > scenery, Fred? > Hello Michael Thanks for your offer to help for a better scenery. Can you start to publish your airports/data/objects now under GPL? So others can also contribute and start to work on scenery around. Thanks- Yves -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Thanks. Yes the 850 format looks way better. Anyone using x-plane knows what i mean. I'm really looking forward to see new airports in FG, maybe on top of a new scenery, Fred? Let me know if I can do something to help or even to only test on my 2 years old PC with a GeForce 8800GTS 512MB etc. On x-plane, streets (openstreetmap), airports etc. have no impact on FPS at all. At least not on my system. Current graphics cards can easily handle thousands of vertices as found in recent, detailed 3D planes etc. Cheers Michael --- On Mon, 3/29/10, Martin Spott wrote: From: Martin Spott Subject: Re: [Flightgear-devel] apt.dat format To: flightgear-devel@lists.sourceforge.net Date: Monday, March 29, 2010, 10:05 PM As a service to those who'd like to dedicate their time for comparing v8.10 and v8.50 layouts (I don't know if anyone's interested at all), I have now added both to the web map. This is a v8.10 sample: http://mapserver.flightgear.org/map/?lon=-122.37563&lat=37.61927&zoom=15&layers=B00TT And the same in v8.50: http://mapserver.flightgear.org/map/?lon=-122.37563&lat=37.61927&zoom=15&layers=B00FTFFFT Note that Robin's current airfield database still contains a lot of v8.10-formatted taxiways, so a multitude of fields look the same in both layers (open the so-called layer-switcher via the "+" sign on the upper right to choose from a variety of different layers). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
As a service to those who'd like to dedicate their time for comparing v8.10 and v8.50 layouts (I don't know if anyone's interested at all), I have now added both to the web map. This is a v8.10 sample: http://mapserver.flightgear.org/map/?lon=-122.37563&lat=37.61927&zoom=15&layers=B00TT And the same in v8.50: http://mapserver.flightgear.org/map/?lon=-122.37563&lat=37.61927&zoom=15&layers=B00FTFFFT Note that Robin's current airfield database still contains a lot of v8.10-formatted taxiways, so a multitude of fields look the same in both layers (open the so-called layer-switcher via the "+" sign on the upper right to choose from a variety of different layers). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Yea cool stuff Frederic! Although somehow stammering FPS? I could test with my
GeForce 8800 GTS 512MB, Intel core duo 8500 and compare to x-plane.
For SIRX (http://sirx.flightsimulatorcenter.com/aeroporti.aspx) and apt.dat 8.5
in general this looks like a good improvement to me?
--- On Wed, 3/24/10, Frederic Bouvier wrote:
From: Frederic Bouvier
Subject: Re: [Flightgear-devel] apt.dat format
To: "FlightGear developers discussions"
Date: Wednesday, March 24, 2010, 11:30 PM
#yiv241533927 p {margin:0;}
- "Tim Moore" a écrit :
> What about ROAM2 that combine big chunk and seamless joins without skirt.
> This
> is what I did in this (already posted) video :
> http://www.youtube.com/watch?v=7WYH27KyUBk
>
> It's pretty cool. It's not clear to me how much work on the CPU is happening
> at run time. The hard part will be getting FlightGear to give up on
> triangulated irregular networks (TINs).
Here, every tile (the numbered triangle in the video) has been computed once
before, and were stored in 16-bit monochrome png images, along with the
texture. At run time, the png is read and a single mesh (a single strip in
fact) of 65536 vertices is built. First version was creating btg files, but the
amount of storage need was insane and load time was worse.
-Fred
--
Frédéric Bouvier
http://my.fotolia.com/frfoto/ Photo gallery - album photo
http://www.youtube.com/user/fgfred64 Videos
-Inline Attachment Follows-
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
-Inline Attachment Follows-
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
- "Tim Moore" a écrit : > What about ROAM2 that combine big chunk and seamless joins without skirt. > This > is what I did in this (already posted) video : > http://www.youtube.com/watch?v=7WYH27KyUBk > > It's pretty cool. It's not clear to me how much work on the CPU is happening > at run time. The hard part will be getting FlightGear to give up on > triangulated irregular networks (TINs). Here, every tile (the numbered triangle in the video) has been computed once before, and were stored in 16-bit monochrome png images, along with the texture. At run time, the png is read and a single mesh (a single strip in fact) of 65536 vertices is built. First version was creating btg files, but the amount of storage need was insane and load time was worse. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, Mar 24, 2010 at 10:43 PM, Frederic Bouvier wrote: > > - "Curtis Olson" a écrit : > > On Wed, Mar 24, 2010 at 3:38 PM, Tim Moore wrote: > > >> >> > >> I think skirts at a slightly less-than-vertical angle are the way to go. >> It doesn't matter if skirts of adjacent tiles intersect. >> > >> > > > If I had to pick a way to handle the seams between different LOD tiles, I > think I'd lean towards skirts too ... angles slightly out shouldn't hurt > anything, I like that idea. I would create a skirt that replicates the > edge, but extending down some safe distance and then out just a small bit. > The color and texture coordinates for the bottom of the skirt should > duplicate that of the matching edge. > > >> > >> I don't think we need to do anything too fancy. I'm a fan of "Chunked LOD" >> approaches that switch in different pieces of a mesh instead of changing >> discrete polygons. But a real LOD scheme that goes all the way out to the >> full earth would let us fully integrate with OSG's DatabasePager and allow >> us to easily support terrain paging for multiple views. >> > >> > > > Yes, there definitely are reasons a LOD scheme would be nice to have. > > > What about ROAM2 that combine big chunk and seamless joins without skirt. This > is what I did in this (already posted) video : > > It's pretty cool. It's not clear to me how much work on the CPU is happening at run time. The hard part will be getting FlightGear to give up on triangulated irregular networks (TINs). > > http://www.youtube.com/watch?v=7WYH27KyUBk > The development of this engine stalled for more than a year. > > That's OK, my terrain engine has been stalled for longer than that :) Tim > -Fred > -- > Frédéric Bouvier > http://my.fotolia.com/frfoto/ Photo gallery - album photo > http://www.youtube.com/user/fgfred64 Videos > > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
- "Curtis Olson" a écrit : > On Wed, Mar 24, 2010 at 3:38 PM, Tim Moore < timoor...@gmail.com > wrote: > > I think skirts at a slightly less-than-vertical angle are the way to go. It doesn't matter if skirts of adjacent tiles intersect. > > If I had to pick a way to handle the seams between different LOD tiles, I > think I'd lean towards skirts too ... angles slightly out shouldn't hurt > anything, I like that idea. I would create a skirt that replicates the edge, > but extending down some safe distance and then out just a small bit. The > color and texture coordinates for the bottom of the skirt should duplicate > that of the matching edge. > I don't think we need to do anything too fancy. I'm a fan of "Chunked LOD" approaches that switch in different pieces of a mesh instead of changing discrete polygons. But a real LOD scheme that goes all the way out to the full earth would let us fully integrate with OSG's DatabasePager and allow us to easily support terrain paging for multiple views. > > Yes, there definitely are reasons a LOD scheme would be nice to have. What about ROAM2 that combine big chunk and seamless joins without skirt. This is what I did in this (already posted) video : http://www.youtube.com/watch?v=7WYH27KyUBk The development of this engine stalled for more than a year. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, Mar 24, 2010 at 3:38 PM, Tim Moore wrote: > I think skirts at a slightly less-than-vertical angle are the way to go. It > doesn't matter if skirts of adjacent tiles intersect. > If I had to pick a way to handle the seams between different LOD tiles, I think I'd lean towards skirts too ... angles slightly out shouldn't hurt anything, I like that idea. I would create a skirt that replicates the edge, but extending down some safe distance and then out just a small bit. The color and texture coordinates for the bottom of the skirt should duplicate that of the matching edge. > I don't think we need to do anything too fancy. I'm a fan of "Chunked LOD" > approaches that switch in different pieces of a mesh instead of changing > discrete polygons. But a real LOD scheme that goes all the way out to the > full earth would let us fully integrate with OSG's DatabasePager and allow > us to easily support terrain paging for multiple views. > Yes, there definitely are reasons a LOD scheme would be nice to have. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, Mar 24, 2010 at 5:13 PM, Curtis Olson wrote: > On Wed, Mar 24, 2010 at 10:41 AM, Tim Moore wrote: > >> While on this subject, do you scenery guys have any thoughts about >> different levels-of-detail in scenery tiles? >> > > Yes, in the initial scenery design phase we had a very extended discussion > about level of detail. There are many ways to do this, but consider ... > > - Any static level of detail scheme is going to have to account for tile > edge matching. This is a non-trivial (tm) problem. No matter what you do > will yield artifacts and issues matching up the edge of a tile at a higher > level of detail with a tile at a lower level of detail. There are a number > of ways to work this. We could create skirts around all tiles to try to > hide the problem, but you will still see feature discontinuities depending > on what angle the seam is viewed from. You could create transition ribbons > that bridge the polygon edge of one tile to the polygon edge of another > tile, but the number of permutations are high, so this is difficult to deal > with. You could turn off clearing the depth buffer each frame and not draw > sky below the horizon and just let the open pixels in the cracks smear along > from the previous frame. We had a SME (subject matter expert) at the time > who detailed about a dozen different approaches along with their pluses and > minuses. > > I think skirts at a slightly less-than-vertical angle are the way to go. It doesn't matter if skirts of adjacent tiles intersect. > His recommendation (as someone who had been there, done that for just about > every possible approach) was that he had the best overall results just using > a simple single level of detail scheme. > > Not long after we committed to our single level of detail (triangle soup) > sort of terrain meshing approach, ROAM type approaches became more and more > popular. These approaches minimized the amount of geometry that had to be > pushed across the system bus to the graphics card each frame and thus > maximized details and rendering rates. There we some really neat demos > floating around the implemented variations of the basic scheme that expanded > or collapsed triangles depending on various screen space and distance > parameters. Initially most of these schemes were for small areas, they > didn't account for larger round world environments, and didn't have good > ways to handle features cut into them (like airports or land use areas.) > Over time, there were dynamic level of details algorithms that did start to > account for some of these more difficult challenges that our original scheme > already accounted for. > > But then the world of graphics cards changed again, and consumer level > graphics cards started storing more geometry and scene information right on > the card. This meant less work every frame pushing the geometry across the > system bus, and graphics cards could draw much more geometry each frame than > previous generations of graphics cards could do. > > (My interpretation) This ability of newer graphics cards to draw insane > numbers of polygons every frame tipped the balance of power away from ROAM > (dynamic level of detail schemes intended to minimize polygon count) and > back towards triangle soup approaches. So good news, FlightGear's terrain > scheme is back in style again! Well sort of anyway. > > ROAM, and any scheme that computes triangles on the CPU, is definitely out of fashion. People are still working hard on level-of-detail for terrain, but these days the interest is in methods that run entirely on the GPU. If you have a detailed near field, you will quickly overwhelm your GPU with the n-squared number of polys if you try to keep that detail over the entire scene. > As Tim points out, there are still good reasons to implement some sort of > level of detail scheme. It would be great to draw terrain out to 200+ miles > so we can see a high mountain at a great distance just like real life. It > would be great to be able to do orbital simulations and accurately draw the > earth from the perspective of outer space. > > If this indeed is something we think is worth exploring then we should come > full circle to the discussion we had in the late 1990's about exactly the > best way to handle the seams between adjacent tiles of differing levels of > details. Note this is a much different challenge from drawing stand-alone > models at different levels of detail at different distances. In a tiled > word scheme, it is the seams between adjacent tiles that get you. (And as I > mentioned before, FlightGear isn't 100% immune to problems at tile seams ... > we've done our best to hide and minimize these, but even so some issues have > snuck through and exist today.) If we want to have this discussion we > should probably split it off into a separate thread because the number of > issues to consider explodes into a big discussion on it's own. > > I don't think we need to do
Re: [Flightgear-devel] apt.dat format
On Wed, 24 Mar 2010, Curtis Olson wrote: > Yes ... the less paying work I do, the more my wife complains; and the less > FlightGear work I do, the more all of you complain. :-) One way or another > there's always someone beating me up on any given day. :-) > You could remind her that not only do we outnumber her, but we saw you first? *laughs* g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, Mar 24, 2010 at 1:43 PM, Martin Spott wrote: > The topic you're talking about is highly familiar to me (even without > thinking about LOD), it's teasing me almost every second week, so you > can be assured that we're seriously going to take care about it :-) > > The basic idea for coping with it is indeed to build an 'empty' grid of > tile boundaries - in the first step, just containing elevation data, > land cover to follow at a later step - to which all the corresponding > tiles have to match. > Obviously this leads to an increased triangle count at the tile borders > of lower detailed tiles, in order to match this elevation grid, but > together with the ability to build tiles of wider coverage this effect > should be easily outweighed by far. > The downside (or the thing to watch out for) is as the number of points in the tile is reduced relative to the number of pre-defined points along the edge, you will begin to have "star" type patterns emerge. As an extreme example, imagine a low-detail tile with only a single elevation point at the center. In that case you will have a series of long skinny triangles radiating from the center of the tile out to the edges in a star type pattern. If the tile edges change slope from point to point, then these long skinny triangles will could/will have significant slope differences compared to the adjacent triangles. Add diffuse lighting effects and suddenly these long skinny triangles jump out at you and look very unnatural. I've tried hard to minimize these in the current scenery generation scheme, but in a few places they still show up ... often when there is an interior point that lies very close, but not quite on the edge of a tile. But like any engineering approach, you have to pick a way to do it, and you get all the good and all the bad. The trick is to maximize the good aspects and do whatever you can to minimize and hide the deficiencies. So in this case, you probably have to find a balance and not build low level of detail tiles with too few interior points ... it may take some experimentation and tuning. The polygon clipping library is segfaulting - even though the data it's > being fed is topologically consistent - and it's author (of the > library) has been unable to provide a clue wether it could be fixed. > Therefore the step you mention here has been without option and the > delay is mostly caused by the fact that the involved people are facing > varying workload during their day job - which is not always predictable > when you're working on a freelance basis. > > That's life. Cheers, Yes ... the less paying work I do, the more my wife complains; and the less FlightGear work I do, the more all of you complain. :-) One way or another there's always someone beating me up on any given day. :-) But it's all in good fun most of the time. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Hi Curt,
Curtis Olson wrote:
> What you describe covers the aspect of managing and selecting different LOD
> versions of the same tile, however I believe the much more difficult issue
> is selecting and implementing a scheme to address the seams/cracks between
> two tiles of differing LOD's.
The topic you're talking about is highly familiar to me (even without
thinking about LOD), it's teasing me almost every second week, so you
can be assured that we're seriously going to take care about it :-)
The basic idea for coping with it is indeed to build an 'empty' grid of
tile boundaries - in the first step, just containing elevation data,
land cover to follow at a later step - to which all the corresponding
tiles have to match.
Obviously this leads to an increased triangle count at the tile borders
of lower detailed tiles, in order to match this elevation grid, but
together with the ability to build tiles of wider coverage this effect
should be easily outweighed by far.
> [...] The only real point I wish to make in this reply is to
> caution that with the current world scenery system there are many difficult
> issues that have been thought about and addressed ("solved" may be too
> strong of a word in many cases.)
While we're at it I'd like to point out that we're regularly getting
bitten by the way how some of these issues have been addressed in the
past (I don't plan to go into detail here). Therefore we're obviously
feeling a noticeable impetus to make the Scenery build system less
static.
This doesn't mean that we're planning to revamp the entire Scenery
layout in a single, huge step. Instead we're aiming at turning every
individual processing step from a mandatory item into an option, thus
allowing for incremental improvements.
> Even something "small" like redoing the current polygon clipping approach
> has turned into much more effort perhaps than what was original anticipated.
> Certainly the "old" approach had it's limitations and difficulties, but I
> was able to nurse it through the entire world scenery data set to produce a
> full build. Life has gotten more complex as people have defined more
> detailed polygon areas which magnifies the short comings of the original
> approach, but I suspect the real issues are less in the polygon clipping
> routines themselves and occur more down stream in the later processing of
> those clipped areas.
The polygon clipping library is segfaulting - even though the data it's
being fed is topologically consistent - and it's author (of the
library) has been unable to provide a clue wether it could be fixed.
Therefore the step you mention here has been without option and the
delay is mostly caused by the fact that the involved people are facing
varying workload during their day job - which is not always predictable
when you're working on a freelance basis.
That's life. Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, Mar 24, 2010 at 12:37 PM, Martin Spott wrote:
> We do. The current idea is 'simply' to render a certain range of
> sceneries at differently detailed levels (by doing polygon
> simplification at database level) and to connect these sceneries into
> some XML structure which takes care of the LOD-vs-distance equation.
> This tree is meant to be built at tile-level, which means that every
> tile is no more referenced by the corresponding .stg-file but instead
> by an XML file which refers to the various binary scenery tiles - in
> whichever file format might be appropriate (certainly starting with our
> well-known BTG).
> Sooner or later we'd like to drop the fixed tile numbering scheme -
> still keeping it as an option, but not mandantory - in favour of a
> schema where the area which is covered by the respective tiles is being
> defined in the respective XML files, thus allowing for variants where
> low-detail tiles may cover a wider area.
Hi Martin,
What you describe covers the aspect of managing and selecting different LOD
versions of the same tile, however I believe the much more difficult issue
is selecting and implementing a scheme to address the seams/cracks between
two tiles of differing LOD's.
And getting rid of the fixed tile numbering/layout scheme certainly would
add flexibility, but you would have to recover the entire world with some
new scheme should you choose to diverge from the existing scheme. It would
be hard to handle the transitions between an area covered with the old
scheme and an area covered with the new scheme. I'll be the first to point
out that there are many aspects of the current scheme that are sub optimal,
my point is not to defend the current approach here ... I have had various
ideas for new schemes from time to time too. I just want to add information
and perspective for those that are interested in this area of FlightGear.
What I would be in favor of doing is extending the scenery management
interface so we can turn off the existing scheme and turn on one of possibly
many alternative schemes. There are many other approaches to doing world
scenery and some of them are very tantalizing and would be fun to explore.
As you know there has been a tremendous amount of thought and effort that
has gone into the current scheme, from the lowest level of obtaining and
organizing raw GIS data to processing that data and finding ways to
seamlessly merge it together and resolve conflicts ... all the way to
generating 3d scenery out of the back end and rendering it in real time.
The system is far from perfect and the door is left wide open for someone
to build something newer or better. Martin and Jon and others have been
working on better systems to manage the raw data that feeds into the
terragear system. The only real point I wish to make in this reply is to
caution that with the current world scenery system there are many difficult
issues that have been thought about and addressed ("solved" may be too
strong of a word in many cases.) There are many issues that wouldn't even
be considered in the immediate discussion because they have always just
appeared to work and no one has had a problem or given them any thought at
all.
Even something "small" like redoing the current polygon clipping approach
has turned into much more effort perhaps than what was original anticipated.
Certainly the "old" approach had it's limitations and difficulties, but I
was able to nurse it through the entire world scenery data set to produce a
full build. Life has gotten more complex as people have defined more
detailed polygon areas which magnifies the short comings of the original
approach, but I suspect the real issues are less in the polygon clipping
routines themselves and occur more down stream in the later processing of
those clipped areas.
When you come up with an algorithm, and then throw the entire world at it,
you will most certainly run into every possible degenerate case imaginable,
and quite a few that are hard to even imagine. :-)
So I appreciate that people are thinking about some of these issues and
discussing possible improvements, and hopefully I can add some perspective
to the discussion to keep in mind some of the additional challenges that
should be considered.
Best regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Tim Moore wrote: > On Wed, Mar 24, 2010 at 4:19 PM, Martin Spott wrote: >> A couple of months ago I've done a few tests: Compiling X-Plane's >> current layout of KSFO (being a prominent example), including all the >> yellow taxi lines, into a triangluated surface leads to approx. 50k >> triangles just for the pure airfield. Now add the effect which Ralf has >> been explaining on this page: >> >> http://www.custom-scenery.org/Triangle-Counts.272.0.html >> >> and we'll end up with a _much_ higher triangle count than we're >> used to. According to past experience with inserting OSM line data for >> the (major) roads I'd say that FlightGear is currently not ready for >> this representation of curved shapes - especially not for mainstream >> Scenery which is supposed to run on a wide range of hardware. >> >> No offense, but the hardware described on Ralf's page is not exactly > cutting edge. True, the hardware is outdated, the entire article is already a couple of years old, but the basic effect still applies. > Of course, this is a huge apples-to-oranges comparison, but it should give > food for thought about why fg seems to choke on large numbers of polys in > the scenery. While on this subject, do you scenery guys have any thoughts > about different levels-of-detail in scenery tiles? We do. The current idea is 'simply' to render a certain range of sceneries at differently detailed levels (by doing polygon simplification at database level) and to connect these sceneries into some XML structure which takes care of the LOD-vs-distance equation. This tree is meant to be built at tile-level, which means that every tile is no more referenced by the corresponding .stg-file but instead by an XML file which refers to the various binary scenery tiles - in whichever file format might be appropriate (certainly starting with our well-known BTG). Sooner or later we'd like to drop the fixed tile numbering scheme - still keeping it as an option, but not mandantory - in favour of a schema where the area which is covered by the respective tiles is being defined in the respective XML files, thus allowing for variants where low-detail tiles may cover a wider area. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Curtis Olson wrote: [... airport elevation ...] > Judging by the total lack of end user comments in this area, I think we > ended up with a pretty good balance of naturally fitting a nice surface to > the terrain data and blending it into the surrounding terrain. Agreed. > The system is automated though so it's not always perfect and I'm sure there > are airports that could use some tweaking. One idea that I had (and haven't > acted on) was to allow specifying a set of "fit parameters" for individual > airports where the default parameters didn't do a good job. This is most prominently interesting for airstrips like LFLJ (Courchevel) which has a slope of slightly below 20 %. An appropriate procedure is already planned - but not yet implemented. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, Mar 24, 2010 at 10:41 AM, Tim Moore wrote: > While on this subject, do you scenery guys have any thoughts about > different levels-of-detail in scenery tiles? > Yes, in the initial scenery design phase we had a very extended discussion about level of detail. There are many ways to do this, but consider ... - Any static level of detail scheme is going to have to account for tile edge matching. This is a non-trivial (tm) problem. No matter what you do will yield artifacts and issues matching up the edge of a tile at a higher level of detail with a tile at a lower level of detail. There are a number of ways to work this. We could create skirts around all tiles to try to hide the problem, but you will still see feature discontinuities depending on what angle the seam is viewed from. You could create transition ribbons that bridge the polygon edge of one tile to the polygon edge of another tile, but the number of permutations are high, so this is difficult to deal with. You could turn off clearing the depth buffer each frame and not draw sky below the horizon and just let the open pixels in the cracks smear along from the previous frame. We had a SME (subject matter expert) at the time who detailed about a dozen different approaches along with their pluses and minuses. His recommendation (as someone who had been there, done that for just about every possible approach) was that he had the best overall results just using a simple single level of detail scheme. Not long after we committed to our single level of detail (triangle soup) sort of terrain meshing approach, ROAM type approaches became more and more popular. These approaches minimized the amount of geometry that had to be pushed across the system bus to the graphics card each frame and thus maximized details and rendering rates. There we some really neat demos floating around the implemented variations of the basic scheme that expanded or collapsed triangles depending on various screen space and distance parameters. Initially most of these schemes were for small areas, they didn't account for larger round world environments, and didn't have good ways to handle features cut into them (like airports or land use areas.) Over time, there were dynamic level of details algorithms that did start to account for some of these more difficult challenges that our original scheme already accounted for. But then the world of graphics cards changed again, and consumer level graphics cards started storing more geometry and scene information right on the card. This meant less work every frame pushing the geometry across the system bus, and graphics cards could draw much more geometry each frame than previous generations of graphics cards could do. (My interpretation) This ability of newer graphics cards to draw insane numbers of polygons every frame tipped the balance of power away from ROAM (dynamic level of detail schemes intended to minimize polygon count) and back towards triangle soup approaches. So good news, FlightGear's terrain scheme is back in style again! Well sort of anyway. As Tim points out, there are still good reasons to implement some sort of level of detail scheme. It would be great to draw terrain out to 200+ miles so we can see a high mountain at a great distance just like real life. It would be great to be able to do orbital simulations and accurately draw the earth from the perspective of outer space. If this indeed is something we think is worth exploring then we should come full circle to the discussion we had in the late 1990's about exactly the best way to handle the seams between adjacent tiles of differing levels of details. Note this is a much different challenge from drawing stand-alone models at different levels of detail at different distances. In a tiled word scheme, it is the seams between adjacent tiles that get you. (And as I mentioned before, FlightGear isn't 100% immune to problems at tile seams ... we've done our best to hide and minimize these, but even so some issues have snuck through and exist today.) If we want to have this discussion we should probably split it off into a separate thread because the number of issues to consider explodes into a big discussion on it's own. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Thanks for the answers. I don't know how x-plane does handle the 8.5 apt.dat but apparently it works well. I heard also the scenery mesh to be different? This is to advanced stuff for me, but hopefully some of you find a solution in the near future. Cheers Michael --- On Wed, 3/24/10, Martin Spott wrote: From: Martin Spott Subject: Re: [Flightgear-devel] apt.dat format To: flightgear-devel@lists.sourceforge.net Date: Wednesday, March 24, 2010, 4:19 PM Erik Hofman wrote: > Tim Moore wrote: >> I think the point is that the tools that build BTG files don't use the >> new format. > > Well maybe, just maybe it can be modified to output to ac3d or something > similar (or even btg format itself). Problem is that casting curved shapes into triangles, the way our Scenery is currently set up, results in a pretty high triangle count. A couple of months ago I've done a few tests: Compiling X-Plane's current layout of KSFO (being a prominent example), including all the yellow taxi lines, into a triangluated surface leads to approx. 50k triangles just for the pure airfield. Now add the effect which Ralf has been explaining on this page: http://www.custom-scenery.org/Triangle-Counts.272.0.html and we'll end up with a _much_ higher triangle count than we're used to. According to past experience with inserting OSM line data for the (major) roads I'd say that FlightGear is currently not ready for this representation of curved shapes - especially not for mainstream Scenery which is supposed to run on a wide range of hardware. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
> Problem is that casting curved shapes into triangles, the way our > Scenery is currently set up, results in a pretty high triangle count. If your really using curves as input, you can sample as many...or as few points on that curve as you wish...hence as many or as few triangles you wish. There is no 1:1 mapping of curves to triangles..just sample at whatever resolution you wish. In x-plane the amount of points sampled can be configured at run-time by the users rendering preferences...he can control how many tris are generated and hence how smooth or coarse the curves will be represented. Since flightgear uses a static pregenerated mesh for terrain and airports we couldn't offer that dynamic lod like x-plane without so some major changes I think. However, in our case one 'can' just choose a reasonably coarse sample rate that does not result in an overly dense meshdoes not need to be perfectly smooth mesh / curve with millions of tris. No reason to sample hundreds or thousands of points for a 90 degree curve8-10 would probably look just finecertainly better than what we have currently. In other words..don't sample the curve every mm or cm...maybe every meter or two..or more...would have to experiment to find a good middle ground... cheers -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, Mar 24, 2010 at 4:19 PM, Martin Spott wrote: > Erik Hofman wrote: > > Tim Moore wrote: > > >> I think the point is that the tools that build BTG files don't use the > >> new format. > > > > Well maybe, just maybe it can be modified to output to ac3d or something > > similar (or even btg format itself). > > Problem is that casting curved shapes into triangles, the way our > Scenery is currently set up, results in a pretty high triangle count. > > A couple of months ago I've done a few tests: Compiling X-Plane's > current layout of KSFO (being a prominent example), including all the > yellow taxi lines, into a triangluated surface leads to approx. 50k > triangles just for the pure airfield. Now add the effect which Ralf has > been explaining on this page: > > http://www.custom-scenery.org/Triangle-Counts.272.0.html > > and we'll end up with a _much_ higher triangle count than we're > used to. According to past experience with inserting OSM line data for > the (major) roads I'd say that FlightGear is currently not ready for > this representation of curved shapes - especially not for mainstream > Scenery which is supposed to run on a wide range of hardware. > > No offense, but the hardware described on Ralf's page is not exactly cutting edge. For an example of a million poly mesh displayed on a reasonable 2 year old laptop (nvidia 8600M), see http://shiny-dynamics.blogspot.com/2010/03/vertex-cache-optimization-for-osg.html. Of course, this is a huge apples-to-oranges comparison, but it should give food for thought about why fg seems to choke on large numbers of polys in the scenery. While on this subject, do you scenery guys have any thoughts about different levels-of-detail in scenery tiles? Tim -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, Mar 24, 2010 at 9:30 AM, Erik Hofman wrote: > I think I forgot about the missing elevation data. So it would still > need post-processing. One of the cool things (I think) that the current airport generator tool does is lay the airport surface over the DEM terrain in a nicely behaved way. We can't use the raw terrain elevations directly because there are tremendous artifacts and noise for each elevation post ... up to 5-10 meters variation. That may not sound like a lot, but if you use the raw elevation data to define the airport surface and then put yourself at the end of the runway and look down the length of it, you see terrible spikes and sawtooth type patterns that repeat over and over again down the entire runway. It is totally unacceptable. However it's important to fit the airport to the underlying terrain so that the airport surface matches up reasonably well at the boundaries with the surrounding terrain. You don't want an airport that is sitting on a pedestal or dug into a deep hole. It needs to blend in naturally with the surrounding terrain. The airport elevation defined in the FAA database is for one single spot on the airport, and for smaller airports and especially for private airstrips, it can be 10's of meters off. In addition you have challenging cases like Albuquerque, NM (KABQ.) KABQ has *significant* elevation changes across different portions of the airport area. In addition there is a valley that cuts away an area between two crossing runways and that is also very difficult to deal with. The solution I came up with that seemed to work the best across a broad range of challenging airports was to take a 3d polynomial equation and do a least squares fit to the noisy terrain data. This produces a function that approximates the underlaying terrain. It's also a smooth function so there are no hard seams or creases in the airport surface. The trick is to pick a polynomial with enough degrees of freedom to adequately fit the terrain surface (to avoid cliffs at the airport edges) but not so many degrees of freedom that it would respond to the noise in the terrain data and produce extraneous artifacts. Judging by the total lack of end user comments in this area, I think we ended up with a pretty good balance of naturally fitting a nice surface to the terrain data and blending it into the surrounding terrain. The system is automated though so it's not always perfect and I'm sure there are airports that could use some tweaking. One idea that I had (and haven't acted on) was to allow specifying a set of "fit parameters" for individual airports where the default parameters didn't do a good job. Another issue is that when an airport area spans the boundary between two tiles, then there can be some small mismatches along the edges of the one of the tiles ... the fitting algorithm doesn't do a perfect "crackless" fit against the adjacent tile hole edges like it can when the airport is completely contained within a single tile. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
James Turner wrote: > On 24 Mar 2010, at 08:52, Martin Spott wrote: >> The other reason is the lack of developer manpower, > [...], I'm afraid - too many things on my plate which I consider > more important/interesting. I didn't mean to blame you or anyone else, I'm just trying to make interested people (anyone interested !? ;-) aware of where the actuall 'issue' is hiding. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Erik Hofman wrote: > Tim Moore wrote: >> I think the point is that the tools that build BTG files don't use the >> new format. > > Well maybe, just maybe it can be modified to output to ac3d or something > similar (or even btg format itself). Problem is that casting curved shapes into triangles, the way our Scenery is currently set up, results in a pretty high triangle count. A couple of months ago I've done a few tests: Compiling X-Plane's current layout of KSFO (being a prominent example), including all the yellow taxi lines, into a triangluated surface leads to approx. 50k triangles just for the pure airfield. Now add the effect which Ralf has been explaining on this page: http://www.custom-scenery.org/Triangle-Counts.272.0.html and we'll end up with a _much_ higher triangle count than we're used to. According to past experience with inserting OSM line data for the (major) roads I'd say that FlightGear is currently not ready for this representation of curved shapes - especially not for mainstream Scenery which is supposed to run on a wide range of hardware. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Erik Hofman wrote: > Well maybe, just maybe it can be modified to output to ac3d or something > similar (or even btg format itself). I think I forgot about the missing elevation data. So it would still need post-processing. Erik -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Gene Buckle wrote: > As far as I can tell, the airports that you create with WED are written > out using the current apt.dat file format. at least to the current file format as being used at X-Plane, that's true. The primary issue here is that having airfields written into an 'apt.dat' file still doesn't make an airport for/in FlightGear Scenery ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Tim Moore wrote: > On Wed, Mar 24, 2010 at 2:53 PM, Gene Buckle > On Wed, 24 Mar 2010, Martin Spott wrote: > > Gene Buckle wrote: > >> On Wed, 24 Mar 2010, Frederic Bouvier wrote: > > > Fred is that only in the CVS or also in 2.0. All working? > >>> > >>> This code is in 2.0.0. But as far as I know, the scenery tools > are not > >>> ready, and can't generate airports from that format > >> > >> WED (World Editor) from X-Plane can. :) > > > > Please explain - do you mean WED can generate airports for > FlightGear ? > > > As far as I can tell, the airports that you create with WED are written > out using the current apt.dat file format. I seem to recall that it's > also an open source tool. > > I think the point is that the tools that build BTG files don't use the > new format. Well maybe, just maybe it can be modified to output to ac3d or something similar (or even btg format itself). Erik -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, 24 Mar 2010, Tim Moore wrote: > On Wed, Mar 24, 2010 at 2:53 PM, Gene Buckle wrote: > >> On Wed, 24 Mar 2010, Martin Spott wrote: >> >>> Gene Buckle wrote: On Wed, 24 Mar 2010, Frederic Bouvier wrote: >>> >> Fred is that only in the CVS or also in 2.0. All working? > > This code is in 2.0.0. But as far as I know, the scenery tools are not > ready, and can't generate airports from that format WED (World Editor) from X-Plane can. :) >>> >>> Please explain - do you mean WED can generate airports for FlightGear ? >>> >> As far as I can tell, the airports that you create with WED are written >> out using the current apt.dat file format. I seem to recall that it's >> also an open source tool. >> >> g. >> >> I think the point is that the tools that build BTG files don't use the new > format. > Ahh, ok. Thanks for the clarification Tim. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, Mar 24, 2010 at 2:53 PM, Gene Buckle wrote: > On Wed, 24 Mar 2010, Martin Spott wrote: > > > Gene Buckle wrote: > >> On Wed, 24 Mar 2010, Frederic Bouvier wrote: > > > Fred is that only in the CVS or also in 2.0. All working? > >>> > >>> This code is in 2.0.0. But as far as I know, the scenery tools are not > >>> ready, and can't generate airports from that format > >> > >> WED (World Editor) from X-Plane can. :) > > > > Please explain - do you mean WED can generate airports for FlightGear ? > > > As far as I can tell, the airports that you create with WED are written > out using the current apt.dat file format. I seem to recall that it's > also an open source tool. > > g. > > I think the point is that the tools that build BTG files don't use the new format. Tim -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, 24 Mar 2010, Martin Spott wrote: > Gene Buckle wrote: >> On Wed, 24 Mar 2010, Frederic Bouvier wrote: > Fred is that only in the CVS or also in 2.0. All working? >>> >>> This code is in 2.0.0. But as far as I know, the scenery tools are not >>> ready, and can't generate airports from that format >> >> WED (World Editor) from X-Plane can. :) > > Please explain - do you mean WED can generate airports for FlightGear ? > As far as I can tell, the airports that you create with WED are written out using the current apt.dat file format. I seem to recall that it's also an open source tool. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Gene Buckle wrote: > On Wed, 24 Mar 2010, Frederic Bouvier wrote: >>> Fred is that only in the CVS or also in 2.0. All working? >> >> This code is in 2.0.0. But as far as I know, the scenery tools are not >> ready, and can't generate airports from that format > > WED (World Editor) from X-Plane can. :) Please explain - do you mean WED can generate airports for FlightGear ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On Wed, 24 Mar 2010, Frederic Bouvier wrote: >> Fred is that only in the CVS or also in 2.0. All working? > > This code is in 2.0.0. But as far as I know, the scenery tools are not > ready, and can't generate airports from that format WED (World Editor) from X-Plane can. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
On 24 Mar 2010, at 08:52, Martin Spott wrote: >> Ooh good. Fred is that only in the CVS or also in 2.0. All working? >> You did also the 3D relief? Cool I'm looking forward to try this. > > So far it's just a parser. As far as I can tell there's no plan how the > Scenery is supposed to be set up, for example, in order to draw the > taxiway lines on top of the tarmac - which is one among other reasons > why the Scenery toolchain currently doesn't support the v8.50+ Apt.Dat > formats. > > The other reason is the lack of developer manpower, For what it's worth, I am happy to do any nav.data or apt.data additional changes, since I'm familiar with the code, but I believe Fred has already done the hard work there (I haven't looked at the specs to see if there's anything else). The TerraGear side is the real complexity and I'm definitely not volunteering to that that aspect on, I'm afraid - too many things on my plate which I consider more important/interesting. Regards, James -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
Michael Sgier wrote: > Ooh good. Fred is that only in the CVS or also in 2.0. All working? > You did also the 3D relief? Cool I'm looking forward to try this. So far it's just a parser. As far as I can tell there's no plan how the Scenery is supposed to be set up, for example, in order to draw the taxiway lines on top of the tarmac - which is one among other reasons why the Scenery toolchain currently doesn't support the v8.50+ Apt.Dat formats. The other reason is the lack of developer manpower, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
> Fred is that only in the CVS or also in 2.0. All working? This code is in 2.0.0. But as far as I know, the scenery tools are not ready, and can't generate airports from that format -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] apt.dat format
Hi Fred, Geoff and Radi Ooh good. Fred is that only in the CVS or also in 2.0. All working? You did also the 3D relief? Cool I'm looking forward to try this. Well if so we should encourage people to use the new apt format. Rounded taxiways with centerlines look so much better. As WED is openSource as well, there's no problem of using this until Taxidraw has catched up. http://scenery.x-plane.com/beta.php http://scenery.x-plane.com/tools.php Anyone for KSFO? I've done some airports with WED which I intend to bring to FG. But for some buildings I've to ask about GPL. If they should not be available as GPL I ask about a link or download section. Geoff could you integrate such? I like the X-Plane.org way to have an image to check out the region or download. Radi has apparently done some scripts for x-plane conversion. I hope I can use this, as my sceneries consist of virtually thousands of little obj... Thanks and cheers Michael --- On Tue, 3/23/10, Martin Spott wrote: From: Martin Spott Subject: Re: [Flightgear-devel] Bug: nav[12] selected radial To: flightgear-devel@lists.sourceforge.net Date: Tuesday, March 23, 2010, 4:10 PM Curtis Olson wrote: > On Tue, Mar 23, 2010 at 1:15 AM, Michael Sgier wrote: >> are you, or someone else, working on integrating the new apt.dat format as >> of x-plane 9? > > > A few of us have been in correspondence with Ben Supnik from time to time, > but as far as I know, no one within FlightGear has tackled the new x-plane 9 > apt and navaid data formats. Fred has modified FlightGear's internal parser accordingly: http://mapserver.flightgear.org/git/gitweb.pl?p=flightgear;a=commit;h=e2c5b0ae5f60fd67a2b5d714a69bf96dce4bb9fa I didn't check if he's supporting linear features as well or 'just' the pavement. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
