[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 martin.sp...@mgras.net wrote: From: Martin Spott martin.sp...@mgras.net 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#174; 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#174; 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] Make relief map go up instead of down? (was Re: Shaders experiments)
Frederic Bouvier wrote: Fixed. What do you think of the night lighting ? It's not entirely what I hoped for, for example the park is completely lit now. Maybe it would be an idea to use the light value as a contrast enhancer for the lit areas? Erik -- Download Intel#174; 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#174; 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#174; 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] Make relief map go up instead of down? (was Re: Shaders experiments)
- Erik Hofman a écrit : Frederic Bouvier wrote: Fixed. What do you think of the night lighting ? It's not entirely what I hoped for, for example the park is completely lit now. Maybe it would be an idea to use the light value as a contrast enhancer for the lit areas? The lit areas are in the blue channel of the relief map texture (the z component of the normal is reconstructed from the x and y components locates in the red and green channels), so a better designer/artist could do a better job than me. For the moment, I only took the floor of the height map with a small decay at the border. The emissive color is also hard-coded in the shader. What do you mean by contrast enhancer ? -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- Download Intel#174; 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] Make relief map go up instead of down? (was Re: Shaders experiments)
Frederic Bouvier wrote: What do you mean by contrast enhancer ? Now all lit pixels are lit equally. What I was suggesting would lit lighter pixels more than darker pixels (I expect multiplying by the gray-scaled pixel color would suffice). Erik -- Download Intel#174; 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] Make relief map go up instead of down? (was Re: Shaders experiments)
- Erik Hofman a écrit : Frederic Bouvier wrote: What do you mean by contrast enhancer ? Now all lit pixels are lit equally. Not exactly. What I was suggesting would lit lighter pixels more than darker pixels (I expect multiplying by the gray-scaled pixel color would suffice). The blue channel has the emission factor. One can redo the map to achieve the effect you are suggesting. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- Download Intel#174; 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] Make relief map go up instead of down? (was Re: Shaders experiments)
Frederic Bouvier wrote: The blue channel has the emission factor. One can redo the map to achieve the effect you are suggesting. I think I was thinking more something in the line of this patch. Erik Index: urban.frag === RCS file: /var/cvs/FlightGear-0.9/data/Shaders/urban.frag,v retrieving revision 1.3 diff -p -u -r1.3 urban.frag --- urban.frag 23 Mar 2010 22:20:24 - 1.3 +++ urban.frag 24 Mar 2010 12:31:13 - @@ -92,6 +92,8 @@ void main (void) if ( shadow_factor 1.0 ) ambient_light = constantColor + gl_LightSource[0].diffuse * shadow_factor * vec4(diffuse, 1.0); float emission_factor = (1.0 - smoothstep(0.15, 0.25, reflectance)) * emis; +vec4 tc = texture2D(BaseTex, uv); +emission_factor *= 0.5*pow(tc.r+0.8*tc.g+0.2*tc.b, 2) -0.2; ambient_light += (emission_factor * vec4(0.75, 0.59, 0.05, 0.0)); vec4 finalColor = texture2D(BaseTex, uv) * ambient_light; -- Download Intel#174; 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#174; 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#174; 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 ge...@deltasoft.com 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#174; 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 ge...@deltasoft.com 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#174; 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#174; 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#174; 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] Head up: METAR weather
I just fixed a bug that probably revealed itself when the atmosphere model was changed. I noticed, that flying with real weather fetch enabled was very unpleasant when METAR changed. Now the sea-level temperature and dewpoint changes are also smootly interpolated to it's new values. I also reduced the rate of change for the pressure interpolation. Please check, if it works as soft for you as it does for me. Torsten -- Download Intel#174; 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] Head up: METAR weather
On 24 Mar 2010, at 14:31, Torsten Dreyer wrote: I just fixed a bug that probably revealed itself when the atmosphere model was changed. I noticed, that flying with real weather fetch enabled was very unpleasant when METAR changed. Now the sea-level temperature and dewpoint changes are also smootly interpolated to it's new values. I also reduced the rate of change for the pressure interpolation. Please check, if it works as soft for you as it does for me. Excellent - no more alarming AP behaviour in the 777 at cruise when the metar updates and altitude jumps 400ft! James -- Download Intel#174; 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#174; 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#174; 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#174; 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 martin.sp...@mgras.netwrote: 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#174; 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#174; 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 martin.sp...@mgras.net wrote: From: Martin Spott martin.sp...@mgras.net 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#174; 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#174; 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] Translating getstart.pdf to German
I searched for a good, affordable FlightGear tutorial for my German friends - but was not very lucky. So I made up my mind to translate the FlightGear Standard getstart.pdf. Because translating that 218 pages may not be done in a couple of weeks I just want to make aware of that I started - so that we might avoid multiples of such a bigger task. As soon as I have a complete first draft i will make it accessible here for reviews etc. And especially provide suggested changes to the original to Stuart and or Martin. joe -- Download Intel#174; 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#174; 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 martin.sp...@mgras.netwrote: 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#174; 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#174; 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 martin.sp...@mgras.netwrote: 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#174; 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, 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#174; 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 curtol...@gmail.com 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 anything too fancy. I'm a fan of Chunked LOD approaches
Re: [Flightgear-devel] apt.dat format
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. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; 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] English Electric Lightning no longer runs
Using latest CVS on windows . The EE Lightning aircraft starts OK, all controls and views seem normal, but when the engines reach about 60% rpm Flightgear crashes. This fault is quite new and was not here about one month ago. For many month now I have been unable to run Flightgear in debug mode as it crashes in soundmgr_openall.cxx at line 486 :- if ( sample-is_file() ) free(sample_data); Erik is aware of this, but nobody else has reported this particular problem. This crash occurs before the cockpit view appears. Unfortunately this means that I can't find much about the cause of the crash. So far I have had a good go at the Lightning nasal files. The electrical system had no var statements, and one or two were missing in the others. All this to no avail. According to the lightning-electrical.nas file, the electrical generators should cut in at 58%, and this is my only clue. Does anyone have any clues? Alan -- Download Intel#174; 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 curtol...@gmail.com 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#174; 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] Wiki link
Just a heads up to who controls it. (Curt?) The link to the wiki from the main website appears to be broken, and has been for some time. It links to: http://wiki.flightgear.org/flightgear_wiki/index.php?title=Main_Page when I believe simply linking to: http://wiki.flightgear.org would be adequate. -- Delusional Mail (http://www.delusionalmind.com) -- Download Intel#174; 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] English Electric Lightning no longer runs
Alan Teeder wrote Using latest CVS on windows . The EE Lightning aircraft starts OK, all controls and views seem normal, but when the engines reach about 60% rpm Flightgear crashes. This fault is quite new and was not here about one month ago. For many month now I have been unable to run Flightgear in debug mode as it crashes in soundmgr_openall.cxx at line 486 :- if ( sample-is_file() ) free(sample_data); Erik is aware of this, but nobody else has reported this particular problem. This crash occurs before the cockpit view appears. Unfortunately this means that I can't find much about the cause of the crash. So far I have had a good go at the Lightning nasal files. The electrical system had no var statements, and one or two were missing in the others. All this to no avail. According to the lightning-electrical.nas file, the electrical generators should cut in at 58%, and this is my only clue. Does anyone have any clues? Bad news - works perfectly here on XP with cvs as of a few minutes ago! Checking to see if I can break it still though. Vivian -- Download Intel#174; 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 fredfgf...@free.frwrote: - Curtis Olson curtol...@gmail.com 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 : 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#174; 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#174; 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] English Electric Lightning no longer runs
On 24 Mar 2010, at 22:09, Vivian Meazza wrote: Bad news - works perfectly here on XP with cvs as of a few minutes ago! Checking to see if I can break it still though. I was using the Lightning to test my mach-calculations code earlier today (Mac, latest CVS code) and it seemed fine. James -- Download Intel#174; 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 timoor...@gmail.com 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#174; 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
