Re: [Flightgear-devel] FG,OSG,MacOS X compile problem
On Wed, 2008-01-09 at 15:28 +1100, Ulrich Hertlein wrote: > Hello list, > > this is sort-of a n00b question so please be patient; I've been using OSG for > years but only just started with FG... (snip) > After some digging it appears that for some reason 'APIENTRY' is not > #defined properly and is causing the compiler to cough up these > errors. (I assume the rest is just follow-up errors.) This was discussed on 28 Jun 2007 Here's the sourceforge archive: http://sourceforge.net/mailarchive/forum.php?thread_name=a6589cd60706281451g75c85a94v3896303dc9308ab2%40mail.gmail.com&forum_name=flightgear-devel Good luck, and welcome aboard! Ron - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear 1.0 LiveCD - beta - for testing
Hello, I am working on a live CD for FlightGear 1.0 - I have a working beta based on Puppy Linux. It has graphics card detection and configuration for nVidia, ATI, and some Intel. I have managed to squeeze this into a 300 meg iso. Your comments and criticism is welcome. The download can be found here: http://puppylinux.ca/tpp/jb4x4/iso/FlightPup-v1.iso I have a couple of forum threads started at Puppy Linux and FlightGear http://www.murga-linux.com/puppy/viewtopic.php?t=25221 http://www.flightgear.org/forums/viewtopic.php?t=838 Or feel free to contact me directly, Thank you for considering my project, John Baumert - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG,OSG,MacOS X compile problem
Hello list, this is sort-of a n00b question so please be patient; I've been using OSG for years but only just started with FG... I'm using OSG SVN trunk on MacOS X and it works fine for my other projects, so I'm pretty sure this is not an issue with the OSG installation. However when attempting to compile FlightGear (from CVS) it gives me a weird error compiling 'ATC/atis.cxx' (it's not this file that's causing the trouble, it's just the first that includes OSG headers): /usr/local/include/osg/BufferObject:191: error: expected ')' before '*' token /usr/local/include/osg/BufferObject:192: error: expected ')' before '*' token /usr/local/include/osg/BufferObject:193: error: expected ')' before '*' token /usr/local/include/osg/BufferObject:194: error: expected ')' before '*' token ...(goes on for a bit) /usr/local/include/osg/BufferObject:203: error: 'GenBuffersProc' does not name a type /usr/local/include/osg/BufferObject:204: error: 'BindBufferProc' does not name a type ...(similar GL-related complaints) After some digging it appears that for some reason 'APIENTRY' is not #defined properly and is causing the compiler to cough up these errors. (I assume the rest is just follow-up errors.) Is anyone running a similar config (MacOS X, OSG trunk, DarwinPorts) or can maybe shed some light on the issue? Thanks in advance, /uli - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
On Jan 7, 2008, at 7:15 PM, LeeE wrote: > On Monday 07 January 2008 22:28, Curtis Olson wrote: >> On Jan 7, 2008 3:51 PM, Frederic Bouvier <> wrote: >>> If we keep the same triangle budget for every tile, we will >>> have sparse data and >>> features at the equator and much more than what is really >>> needed at the poles, >>> just because the area covered by each tile will vary greatly ( >>> proportional to >>> 1/cos( lat ) if my math is ok ) >> >> My gut feeling is that once you get up (or down) into the >> latittudes where the tiles get significantly skinny, the >> resolution of the available data drops of significantly. We >> really don't have a per-tile triangle budget anyway. The only >> place where I see this making a difference is the concentration >> of terrain elevation points would increase, but this is up in an >> area where we only have very low res terrain data anyway. SRTM >> drops out beyond +/- 60 degrees latitude. >> >> Regards, >> >> Curt. > > Yup - I downloaded lots of SRTM data to play with in GRASS and > above/below +/- 60 lat it isn't there. For the SRTM mission the shuttle was at an inclination of 57 degrees, which I believe was the maximum that the shuttle could reach. At that inclination it could not "see" much higher latitudes. > > > There doesn't seem to be any alternative source of suitable data > either so I don't see how FG can cover the poles. > > (the reason I was looking was because I was interested in the Mt > Erebus volcano - FG is quite good for looking at volcanos and other > large scale geological features from the air - at some point I'll > get together a list of volcanos and astroblemes for the 'places to > fly' section of the FG docs/wiki) > > LeeE > > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ch53e update
I just posted an update to the Super Stallion at: http://jrbabcock.home.comcast.net/~jrbabcock/flightgear/ch53e/ch53e-rollup.20080108.tgz I don't know who is doing cvs commits now, I would appreciate if someone could do this one for me. The file contains a unified diff and many new files and modified images. There is also a text file curchn containing a list of changes in this update. Josh PS, also some new pics at http://jrbabcock.home.comcast.net/~jrbabcock/flightgear/ch53e/progress/progress.html - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having < 4 fuel tanks
On Tue, 8 Jan 2008 11:13:56 -0600 Curtis Olson wrote: > > > One possibility ... if you have a --native-fdm= option, it is blindly > grabbing data from 1 - MAX_TANKS (which is currently 4). So that could > be creating the nodes if they don't exist so it can fill the data into > the structure. No --native-fdm option here. "fgfs --aircraft=ufo" is enough to give me the same } Nasal runtime error: props.setDoubleValue() with non-number } at /home/cmetzler/Projects/FlightGear-0.9/data//Nasal/props.nas, line 26 } called from: /home/cmetzler/Projects/FlightGear-0.9/data//Nasal/fuel.nas, line 93 } called from: /home/cmetzler/Projects/FlightGear-0.9/data//Nasal/fuel.nas, line 124 that Lee sees. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear signature.asc Description: PGP signature - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having < 4 fuel tanks
On Jan 7, 2008 9:05 PM, LeeE <[EMAIL PROTECTED]> wrote: > > More information is helpful & useful - thanks. > > Yeah - script based routines for things like fuel handling doesn't > seem right but Nasal, because of the timer functions, is > effectively real-time - it's just a question of resolution - for > fuel handling 1/3 sec seems reasonable. > > Not @ you John, but the bottom line regarding this bug is that four > fuel tanks nodes are created by default but they're not fully > populated when they are created - they cannot be. The fuel tank > nodes cannot be fully populated until the fdm config is parsed > because the number of fuel tanks, and their capacities, depends > upon each individual aircraft. > > I can see how it may be necessary to declare a single initial fuel > tank node as a template but declaring four seems irrational. > > The best hits I found in the source, having found nothing in the > config data, were those two bits of code I pasted above but if they > are not relevant to the problem then we need to look elsewhere. > > For sure, four incomplete fuel tank nodes are _not_ being created by > magic:) > > Sorry to all for being a nag but it is a bit of a fundamental bug. > One possibility ... if you have a --native-fdm= option, it is blindly grabbing data from 1 - MAX_TANKS (which is currently 4). So that could be creating the nodes if they don't exist so it can fill the data into the structure. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG OSG => Error: Not able to create requested visual.
On mar 8 janvier 2008, Tim Moore wrote: > gerard robin wrote: > | On mar 8 janvier 2008, Tim Moore wrote: > |> gerard robin wrote: > |> | Hello, > |> | > |> | I was afaik, and i just built the last FG-OSG , unfortunately i get a > |> | crash during loading: > |> | fgfs --aircraft=c172p > |> | Error: Not able to create requested visual. > |> | Erreur de segmentation > |> | > |> | What the matter ? > |> | I do use the last OSG 2.2 stable. > |> | > |> | Happy new year. > |> > |> Set your DISPLAY variable to :0.0 (not a smiley) > |> > |> Tim > | > | Oups, :( > | > | I never had to do it before. > | > | The "loading scenery objects" takes a lot of time, > | is it right ? or is it anything wrong in my system? > > If you were on IRC, I'd tell you to read flightgear-devel :) > > The DISPLAY problem is caused by new code in FG that checks the display > variable and bug in OSG, fixed in OSG SVN. > > The slow scenery loading is caused by switching to the OSG DatabasePager, > plus some problems in OSG that are fixed in OSG 2.3. > > Tim > Oh, Right, Since i have rebuilt my computers room i have lost the old mails, which explain (but does not excuse) my ignorance. For some reasons i only work with stable OSG versions so i will wait for the next one. Regards -- Gérard http://pagesperso-orange.fr/GRTux/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG OSG => Error: Not able to create requested visual.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 gerard robin wrote: | On mar 8 janvier 2008, Tim Moore wrote: |> gerard robin wrote: |> | Hello, |> | |> | I was afaik, and i just built the last FG-OSG , unfortunately i get a |> | crash during loading: |> | fgfs --aircraft=c172p |> | Error: Not able to create requested visual. |> | Erreur de segmentation |> | |> | What the matter ? |> | I do use the last OSG 2.2 stable. |> | |> | Happy new year. |> |> Set your DISPLAY variable to :0.0 (not a smiley) |> |> Tim |> | Oups, :( | | I never had to do it before. | | The "loading scenery objects" takes a lot of time, | is it right ? or is it anything wrong in my system? If you were on IRC, I'd tell you to read flightgear-devel :) The DISPLAY problem is caused by new code in FG that checks the display variable and bug in OSG, fixed in OSG SVN. The slow scenery loading is caused by switching to the OSG DatabasePager, plus some problems in OSG that are fixed in OSG 2.3. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHg5QFeDhWHdXrDRURAlbZAJ4qNyXUEwrlPOMQ94hxiCxLEcepwgCfVKZc uftdPMKVW6PXH1t9y1SNtZY= =p8ph -END PGP SIGNATURE- - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme
Frederic Bouvier wrote: > Selon Ralf Gerlich : > > >> The alternative would be to scale the number of vertices passed to >> TerraFit by cos(lat)... > > I was thinking of this solution : regular lon/lat tile scheme but variable > number of resulting vertices per tile. That's what I meant ;-) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme
Ralf Gerlich wrote: > Currently we have tile borders that are representable as polygon - more > strictly as rectangles - which makes clipping easy. The new tile borders > could not be well-approximated using polygons. We could try creating > clipping polygons that approximate the borders down to an error of > SG_EPSILON, but I'm not sure if that is practicable. We could also define the tiles to be non-rectangular, but - as Lee mentioned - trapezoidal resp. as triangular. The width of the northern edge would be cos(nlat) and the width of the southern edge would be cos(slat), with nlat being the northern latitude of the tile and slat being the southern latitude of the tile. Cheers, Ralf - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme
Selon Ralf Gerlich : > The alternative would be to scale the number of vertices passed to > TerraFit by cos(lat)... I was thinking of this solution : regular lon/lat tile scheme but variable number of resulting vertices per tile. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG OSG => Error: Not able to create requested visual.
On mar 8 janvier 2008, Tim Moore wrote: > gerard robin wrote: > | Hello, > | > | I was afaik, and i just built the last FG-OSG , unfortunately i get a > | crash during loading: > | fgfs --aircraft=c172p > | Error: Not able to create requested visual. > | Erreur de segmentation > | > | What the matter ? > | I do use the last OSG 2.2 stable. > | > | Happy new year. > > Set your DISPLAY variable to :0.0 (not a smiley) > > Tim > Oups, :( I never had to do it before. The "loading scenery objects" takes a lot of time, is it right ? or is it anything wrong in my system? Regards -- Gérard http://pagesperso-orange.fr/GRTux/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme
Hi! Curtis Olson wrote: > On Jan 8, 2008 1:22 AM, Frederic Bouvier <> wrote: > > I was thinking about the parameter we pass to "Terra" to simplify the > initial grid. IIRC, this parameter is always the same, leaving all > *.arr.gz files with the same number of vertices. > > > Yes, that's a good point, and something definitely to think about if > we made such a tile layout switch. So then we should not use geographical coordinates but rather use a mercator projection, assuming the earth is round, such as: y=dlat x=dlon*cos(dlat) and then impose a grid on that. If I understood it correctly, that is what Fred originally wanted to propose. That would give us a grid in which tile widths vary with their actual linear width. There are some problems with that. What comes to my mind first is that tiles would not be rectangular anymore. They would not be in the geographic coordinate system and at least for the border tiles they would not be in the projected coordinate system. This would lead to clipping problems in TerraGear which - if not solved accurately - could lead to z-fighting-problems or gaps at tile borders, if tiles overlap or "underlap" (is that a word? probably not). Currently we have tile borders that are representable as polygon - more strictly as rectangles - which makes clipping easy. The new tile borders could not be well-approximated using polygons. We could try creating clipping polygons that approximate the borders down to an error of SG_EPSILON, but I'm not sure if that is practicable. The alternative, of using clat, the center latitude of a tile ring as follows y=dlat x=dlon*cos(clat) would give us rectangular tiles at least in geographic coordinates, but would also lead us to the same problem Curt already mentioned: Curtis Olson wrote: > The big problem with the current system is that at every latitude > boundary where the number of tile subdivisions changes per degree, we > have ugly gaps because the tile edge matching code simply can't > account for 2 tiles matching up to 1 tile ... an oversight in the > original scheme. The alternative would be to scale the number of vertices passed to TerraFit by cos(lat)... Cheers, Ralf - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
On Jan 8, 2008 1:22 AM, Frederic Bouvier <> wrote: > I was thinking about the parameter we pass to "Terra" to simplify the > initial > grid. IIRC, this parameter is always the same, leaving all *.arr.gz files > with > the same number of vertices. > Yes, that's a good point, and something definitely to think about if we made such a tile layout switch. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG OSG => Error: Not able to create requested visual.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 gerard robin wrote: | | | Hello, | | I was afaik, and i just built the last FG-OSG , unfortunately i get a crash | during loading: | fgfs --aircraft=c172p | Error: Not able to create requested visual. | Erreur de segmentation | | What the matter ? | I do use the last OSG 2.2 stable. | | Happy new year. | Set your DISPLAY variable to :0.0 (not a smiley) Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHg3poeDhWHdXrDRURAiAGAJ9Z+3lcEXW5V/Dg+AwuaExnNb9RzACghkgv 20mdQ8hEikUXpsoKpYEU3QQ= =wrb3 -END PGP SIGNATURE- - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG OSG => Error: Not able to create requested visual.
Hello, I was afaik, and i just built the last FG-OSG , unfortunately i get a crash during loading: fgfs --aircraft=c172p Error: Not able to create requested visual. Erreur de segmentation What the matter ? I do use the last OSG 2.2 stable. Happy new year. -- Gérard http://pagesperso-orange.fr/GRTux/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme
LeeE wrote: > Yup - I downloaded lots of SRTM data to play with in GRASS and > above/below +/- 60 lat it isn't there. > > There doesn't seem to be any alternative source of suitable data > either so I don't see how FG can cover the poles. FG can cover the poles - and has been doing so for years -, but only in terms of landcover definition, not in terms of elevation. It's not realistic, but the same could be said of using the SRTM data for deserts, which change their shape all the time. I'm sure there are sources for the pole, just with the problem that we can't use them in a legal sense. Cheers, Ralf - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme
Hi! Frederic Bouvier wrote: > Selon Curtis Olson : >> My gut feeling is that once you get up (or down) into the latittudes where >> the tiles get significantly skinny, the resolution of the available data >> drops of significantly. We really don't have a per-tile triangle budget >> anyway. The only place where I see this making a difference is the >> concentration of terrain elevation points would increase, but this is up in >> an area where we only have very low res terrain data anyway. SRTM drops out >> beyond +/- 60 degrees latitude. > > I was thinking about the parameter we pass to "Terra" to simplify the initial > grid. IIRC, this parameter is always the same, leaving all *.arr.gz files with > the same number of vertices. Well, from my experience the elevation grid is not the main driver in terms of triangles. In terms of triangles per area, probably the linear features (roads, rivers, railways, etc.) are much more intensive than the basic elevation grid provided by Terra. Further, the width of the tiles is not necessarily proportionally related to the number of triangles, as vegetation and buildup clearly drop in the latitudes farther north and south. If we really can now afford having tiles of different size in terms of linear measure, I would very much favour a regular grid in the latitude-longitude space. That would leave us with only slight changes in SGBucket with only very small adaptations necessary in the rest of the code (FlightGear, TerraGear), assuming that it uses only the interface of SGBucket as it should and not making any further assumptions about its workings. And it would solve the TerraGear neighbour-problems Curt mentioned earlier in the thread. The problems we have regarding the degeneration of quad-tiles at the pole to actually triangular tiles and the fact that the earth surface is sperical and infinite and not flat and finite would remain, but could be worked around much more easily with such a simple and before all consistent grid definition. Cheers, Ralf - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear hangs on startup (Was: Random Objects OSG patch)
Tim Moore wrote: > If you are going to enable random objects, I recommend using OSG 2.3 or > later. Otherwise, > set the environment variable OSG_DATABASE_PAGER_DRAWABLE=VertexArrays Installing OSG 2.3.1 did indeed do the trick but it's still slower at startup than I was used to. I think I'll disable random object for now. Thanks for the help Tim. Erik - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
