Re: [Flightgear-devel] Progress report on the infamous error in TriangleIntersect NAN Problem
Folks, Here's a rather long overdue follow-up to my own previous mail. On Tuesday 26 May 2009 22:37:45 I wrote: Thanks for your suggestions. I've been trying to track this down, but don't have anything firm yet. My current working hypothesis is that a stack corruption may be feeding bad data into the prepare ground cache function. As I've been tracing the problem further up the stack, I got to the point that suggests this. I'll post some more specific results later, because the core dumps are on a different machine that I don't have access to. That being the case, there's probably no bad date in the scene graph itself. I currently don't fully understand the results form the stacktrace yet. Below is a stack trace of gdb, after I placing error trapping code further upstream. My original thought, looking at this stack trace was that a stack corruption occurs somewhere between stack frames #8 and #7, but upon closer inspection, I'm not so sure anymore: At stack frame #8 _simTime has a normal value, whereas at stack frame #7, startSimTime is listed as 0 (when it should have been the same value as _simTime in frame 8). However, at stack frame 6, startStimTime is again the same as _simTime in frame 8, so this variable is passed correctly, but just printed in correctly in frame 7. On previous runs, I've seen these values being printed as NaN though, so I'm not quite comfortable as to what's going on here. I have a core file for this particular crash, so any suggestions would be welcome. Cheers, Durk (gdb) bt #0 osg::PositionAttitudeTransform::computeLocalToWorldMatrix (this=0x9d1d3b0, matrix=value optimized out) at /home/durk/src/OpenSceneGraph/src/osg/PositionAttitudeTransform.cpp:63 #1 0x7fbf16244187 in osg::Transform::computeBound (this=0x9d1d3b0) at /home/durk/src/OpenSceneGraph/src/osg/Transform.cpp:164 #2 0x7fbf162207a1 in osg::Switch::computeBound (this=0x9d1d290) at /home/durk/src/OpenSceneGraph/include/osg/Node:334 #3 0x7fbf1618df5f in osg::Group::computeBound (this=0x832d590) at /home/durk/src/OpenSceneGraph/include/osg/Node:334 #4 0x004fcb90 in FGGroundCache::CacheFill::apply (this=0x7fff21e74330, gro...@0x832d590) at /usr/local/include/osg/Node:334 #5 0x7fbf1618f393 in osg::Group::accept (this=0x832d590, n...@0x7fff21e74330) at /home/durk/src/OpenSceneGraph/include/osg/Group:38 #6 0x004f504d in FGGroundCache::prepare_ground_cache (this=0x9de29d8, startSimTime=238.200687, endSimTime=238.217355, p...@0x7fff21e74730, rad=12.576125144958496) at groundcache.cxx:355 #7 0x004ee91c in FGInterface::prepare_ground_cache_m (this=value optimized out, startSimTime=0, endSimTime=-0, pt=value optimized out, rad=-0) at flight.cxx:612 #8 0x00675aa5 in YASim::update (this=0x9de2650, dt=0.01) at YASim.cxx:213 #9 0x00427255 in fgUpdateTimeDepCalcs () at main.cxx:157 #10 0x004294af in fgMainLoop () at main.cxx:447 #11 0x004714bf in fgOSMainLoop () at fg_os_osgviewer.cxx:177 #12 0x00428bb5 in fgMainInit (argc=4, argv=0x7fff21e74d68) at main.cxx:1004 #13 0x00426a95 in main (argc=4, argv=0x7fff21e74d68) at bootstrap.cxx:216 (gdb) frame 8 #8 0x00675aa5 in YASim::update (this=0x9de2650, dt=0.01) at YASim.cxx:213 213 prepare_ground_cache_m( _simTime, _simTime + dt, xyz, vr ); (gdb) p _simTime $6 = 238.200687 (gdb) p dt $7 = 0.01 (gdb) frame 7 #7 0x004ee91c in FGInterface::prepare_ground_cache_m (this=value optimized out, startSimTime=0, endSimTime=-0, pt=value optimized out, rad=-0) at flight.cxx:612 612SGVec3d(pt), rad); (gdb) -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Internet presentation and handling[ was FlightGear presentation on the LinuxTag expo]
Hi all, I installed Joomla! yesterday on my page, for making a example of what could be flightgear.org in the next time. Joomla! is OpenSource CMS which is under GNU GPL. The look of the page can be easily changed with html and css, and there are lot of GNU GPL templates to use and change out. It is barrier-free, has already installed the possibilites to make newsfeeds, votings etc. There are modules out, so we can add galleries etc. easily. I'm sure we can also still use the current gallery. It has still place for the advertisement, but isn't so much in the foreground like we have now. For changing the content of the page, you will have to log in and you will find a wysiwyg-editor which be used from any browser, so migrating and changing the content ist just pastecopy! It is not more unsafe than other pages done with CMS or without. I'm now out of town for maybe two days, after that I will try to organize the important parts of flightgear.org and fill my example with content, so everyone can see, how flightgear.org could look and feel in near future. I think that's the best solution so far, to make flightgear.org look nice again, but easy to use for all especially Curt too! Kind regards HHS Von: Curtis Olson curtol...@gmail.com An: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Gesendet: Samstag, den 13. Juni 2009, 14:55:14 Uhr Betreff: Re: [Flightgear-devel] Internet presentation and handling[ was FlightGear presentation on the LinuxTag expo] The last time we revamped the web site, we had someone put together a demonstration page of the new layout for others to review. We decided we liked it and decided it was worth moving forward, so that person then proceeded to convert the entire site to the new layout. It was a lot of work, but it was also big step forward over what we had before. Best regards, Curt. Heiko Schulz wrote: Lol... That's actually a really cool picture! The reflection of the modern jet in the windows in the background. It wasn't my intention just to show a nice pic- I wanted you to just explain, why I'm so strong in convincing you that there are better ways to present the OpenSource FlightGear Project! The Ju52 was a great aircraft, safe in flying, possible to use as passenger aircraft and cargo aircraft, robuste, strong. It was the main aircraft for Lufthansa and it even flew from germany to china once a time. But time went one, and there came better aircrafts, which replaced the Ju52. Today it is the B737 which is the main aircraft for Lufthansa- and will be also replaced in the next years. Guess why Our current presentation on the web was good for a long time- but I think there are no better possibilities available. That's all. On the pic in front you could also try to see current flightgear.org- in the background a possible new flightgear.org. But I feel, that there is nothing that could convince you- so I give up now. You won! HHS -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Internet presentation and handling[ was FlightGear presentation on the LinuxTag expo]
Heiko Schulz ha scritto: *Hi all,* ** *I installed Joomla! yesterday on my page, for making a example of what could be flightgear.org in the next time.* ** *Joomla! is OpenSource CMS which is under GNU GPL. The look of the page can be easily changed with html and css, and there are lot of GNU GPL templates to use and change out. [...] * I don't want to enter deeply in this thread (About changing FG main web page) , but I have to say that using joomla could be a very nice idea, I know joomla quite well and we could achieve a new site style with minimum effort. -- Brisa Francesco Via Gabelli 16 22077 Olgiate Comasco (CO) http://brisa.homelinux.net france...@brisa.homelinux.net __ / / / / /___ ___ / / __/ / __ / / / __ \/ __ `__ \/ __ \ / /_/ / /___ /_/ / /___/ /_/ / / / / / / /_/ / \/_/\/\/_/ /_/ /_/\/ http://www.gl-como.it My public gpg key: http://minsky.surfnet.nl:11371/pks/lookup?op=getsearch=0xC67DC12DC4361693 -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 777 broken Was: [Simgear-cvslogs] CVS: SimGear/simgear/scene/model SGPagedLOD.cxx, 1.9, 1.10 modellib.hxx, 1.10, 1.11 modellib.cxx, 1.16, 1.17 SGReaderWriterXML.cxx, 1.19, 1.20
Hi Mathias, it appears this commit broke the autostart feature of the 777. With it, the MFD are not lighting up. It's unfortunate because I am currently working on the ground radar. Regards, -Fred Mathias Froehlich a écrit : Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/model In directory baron.flightgear.org:/tmp/cvs-serv17676/simgear/scene/model Modified Files: SGPagedLOD.cxx modellib.hxx modellib.cxx SGReaderWriterXML.cxx Log Message: Finally get rid of that member in the SGModelData callback. Move call of SGModelData::modelLoaded directly into the xml reader. Modified Files: simgear/scene/model/SGPagedLOD.cxx simgear/scene/model/modellib.hxx simgear/scene/model/modellib.cxx simgear/scene/model/SGReaderWriterXML.cxx -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] X-Plane 850 file format support committed
Hi, I committed the support to read new X-Plane 850 file format in flightgear. That doesn't mean that airports will look different in current scenery because TerraGear tools have not been updated yet, but this is the first step to support the format. Here are two screenshots comparing the ground radar with the different data : http://frbouvi.free.fr/flightsim/KSBD-810.png http://frbouvi.free.fr/flightsim/KSBD-850.png The Google Maps link: http://tinyurl.com/n9khev You should notice the smooth curves in the 850 screenshot. The parser should read current data normally, and nobody should see the difference until we change the data. Please shout if you find something broken or overlooked. (actually something is broken in the 777 ground radar, but it's not me ;-) ) Curt wrote (about linear features) : Fred, were you thinking of cutting these lines into the surface (with hard polygon edges) or drawing them over the top like with a glPolygonOffset() approach? Or something else? It would be really great to be able to add taxi lines and other markings to our airports. I didn't really thought about it yet. I am open to ideas. Does the .btg file format support the glPolygonOffset approach ? Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
You might want to look into /OpenSceneGraph/include/osgSim/OverlayNode Cheers Norman On Jun 14, 2009, at 10:19 AM, Curtis Olson wrote: Hi Fred, Glad to see someone is starting to nibble at the 8.50 format and figure it out. If you are developing code that takes the bezier outlines and can turn that into a polygon representation, then it shouldn't be terribly difficult to add that into genapts. For lines and markings, I think the easiest path in the short term will be to cut those into the surface. However, this can explode the polygon count and rendering load so we need to be careful, but it should be manageable if we don't get too crazy with lots of small segments around curves to make them look perfectly smooth. I've never played around with glPolygonOffset in the context of btg files (terragear/genapts) so I don't believe there's any support there. It's difficult because airport surfaces are curved and are not planar, so most likely any use of glPolygonOffset will not be perfect and there will be places where the lines z-fight with the underlying surface ... unless we really go crazy with a large offset value in which case the lines could bleed through some of the surfaces when they should be hidden behind them. Still it might be worth playing around with to see what kind of results are actually achievable. I wonder what tricks and approaches the gaming community uses for drawing clear and realistic roads? The problem with cutting the lines into the surface as polygons is that (1) you explode the polygon count and (2) you have hard aliased edges which can become distracting in the distance. Cooking the lines into the surface texture gets rid of the aliasing problem, but then you explode your texture memory requirements and need to do a lot of work to generate those textures on the fly, or generate them once and store them. And drawing the lines on top using glPolygonOffset is hard to do well when you are dealing with non-planer surfaces and the visual result of glPolygonOffset (at least historically) has not been consistent across different video cards and vendors. It's a difficult challenge to do well. Regards, Curt. On Sun, Jun 14, 2009 at 6:56 AM, Frederic Bouvier wrote: Hi, I committed the support to read new X-Plane 850 file format in flightgear. That doesn't mean that airports will look different in current scenery because TerraGear tools have not been updated yet, but this is the first step to support the format. Here are two screenshots comparing the ground radar with the different data : http://frbouvi.free.fr/flightsim/KSBD-810.png http://frbouvi.free.fr/flightsim/KSBD-850.png The Google Maps link: http://tinyurl.com/n9khev You should notice the smooth curves in the 850 screenshot. The parser should read current data normally, and nobody should see the difference until we change the data. Please shout if you find something broken or overlooked. (actually something is broken in the 777 ground radar, but it's not me ;-) ) Curt wrote (about linear features) : Fred, were you thinking of cutting these lines into the surface (with hard polygon edges) or drawing them over the top like with a glPolygonOffset() approach? Or something else? It would be really great to be able to add taxi lines and other markings to our airports. I didn't really thought about it yet. I am open to ideas. Does the .btg file format support the glPolygonOffset approach ? Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for
Re: [Flightgear-devel] X-Plane 850 file format support committed
Hi Fred, Glad to see someone is starting to nibble at the 8.50 format and figure it out. If you are developing code that takes the bezier outlines and can turn that into a polygon representation, then it shouldn't be terribly difficult to add that into genapts. For lines and markings, I think the easiest path in the short term will be to cut those into the surface. However, this can explode the polygon count and rendering load so we need to be careful, but it should be manageable if we don't get too crazy with lots of small segments around curves to make them look perfectly smooth. I've never played around with glPolygonOffset in the context of btg files (terragear/genapts) so I don't believe there's any support there. It's difficult because airport surfaces are curved and are not planar, so most likely any use of glPolygonOffset will not be perfect and there will be places where the lines z-fight with the underlying surface ... unless we really go crazy with a large offset value in which case the lines could bleed through some of the surfaces when they should be hidden behind them. Still it might be worth playing around with to see what kind of results are actually achievable. I wonder what tricks and approaches the gaming community uses for drawing clear and realistic roads? The problem with cutting the lines into the surface as polygons is that (1) you explode the polygon count and (2) you have hard aliased edges which can become distracting in the distance. Cooking the lines into the surface texture gets rid of the aliasing problem, but then you explode your texture memory requirements and need to do a lot of work to generate those textures on the fly, or generate them once and store them. And drawing the lines on top using glPolygonOffset is hard to do well when you are dealing with non-planer surfaces and the visual result of glPolygonOffset (at least historically) has not been consistent across different video cards and vendors. It's a difficult challenge to do well. Regards, Curt. On Sun, Jun 14, 2009 at 6:56 AM, Frederic Bouvier wrote: Hi, I committed the support to read new X-Plane 850 file format in flightgear. That doesn't mean that airports will look different in current scenery because TerraGear tools have not been updated yet, but this is the first step to support the format. Here are two screenshots comparing the ground radar with the different data : http://frbouvi.free.fr/flightsim/KSBD-810.png http://frbouvi.free.fr/flightsim/KSBD-850.png The Google Maps link: http://tinyurl.com/n9khev You should notice the smooth curves in the 850 screenshot. The parser should read current data normally, and nobody should see the difference until we change the data. Please shout if you find something broken or overlooked. (actually something is broken in the 777 ground radar, but it's not me ;-) ) Curt wrote (about linear features) : Fred, were you thinking of cutting these lines into the surface (with hard polygon edges) or drawing them over the top like with a glPolygonOffset() approach? Or something else? It would be really great to be able to add taxi lines and other markings to our airports. I didn't really thought about it yet. I am open to ideas. Does the .btg file format support the glPolygonOffset approach ? Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Airports pavement.cxx, NONE, 1.1 pavement.hxx, NONE, 1.1 apt_loader.cxx, 1.23, 1.24 Makefile.am, 1.17, 1.18 simple.cxx, 1.61, 1.62 simple.hx
On 14 Jun 2009, at 12:08, Frederic Bouvier wrote: FGPavement::FGPavement(const std::string aIdent, const SGGeod aPos) : FGPositioned(TAXIWAY, aIdent, aPos, false) Fred, are you sure we don't want to add a new FGPositioned::Type for this? I don't mind either way, it's whatever you think makes the most sense. Regards, James -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
Curtis Olson wrote: Glad to see someone is starting to nibble at the 8.50 format and figure it out. If you are developing code that takes the bezier outlines and can turn that into a polygon representation, then it shouldn't be terribly difficult to add that into genapts. I'd like to remind that we are (I am) maintaining a complete set of runways as well as taxiways/aprons at our repository known as Landcover-DB as closed polygons with beziers properly cut into smaller segments, merged together from v8.50 where available and v8.10 for the rest. Different representations (distinct runway threshold positions for example) or various combinations are available as well. These are available for export into different formats like ESRI Shapefiles and a lot more - please request if you think it might be useful for further development. If you load shapefiles into QGIS, it would, for example, look like this shot: http://foxtrot.mgras.net/bitmap/FGFS/KSFO-861.png Not that, as shown here, not all v8.50 airfields match the quality measures we would expect - just take the northern part of taxiways L (east of 19L) as an example. This doesn't mean that we should not go for v8.50, I'm just trying to point out that we should consider selecting carefully. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
Martin Spott a écrit : If you load shapefiles into QGIS, it would, for example, look like this shot: http://foxtrot.mgras.net/bitmap/FGFS/KSFO-861.png Not that, as shown here, not all v8.50 airfields match the quality measures we would expect - just take the northern part of taxiways L (east of 19L) as an example. This doesn't mean that we should not go for v8.50, I'm just trying to point out that we should consider selecting carefully. Are you sure you have the latest data, or you are not suffering a numerical precision problem ? Compare your screenshot with what is displayed in the ground radar : http://frbouvi.free.fr/flightsim/KSFO-850.png -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
Curtis Olson wrote: I wonder what tricks and approaches the gaming community uses for drawing clear and realistic roads? The problem with cutting the lines into the surface as polygons is that (1) you explode the polygon count and (2) you have hard aliased edges which can become distracting in the distance. Cooking the lines into the surface texture gets rid of the aliasing problem, but then you explode your texture memory requirements and need to do a lot of work to generate those textures on the fly You also lose the polygon material mapping if you're just going to have a surface (presumably generated from just SRTM data) with the generated texture draped over it. IMHO this is a huge benefit of what we have already, since that's what allows us to have things like amphibious aircraft, operate aircraft from roads (I'm thinking of the harrier, jaguar, air ambulance operations etc etc) and generally ensure a nice bumpy landing when you have to choose a field for your glider because you ran out of altitude before you made it back home. AFAIK this is something pretty unique to FlightGear - we should think very carefully before dropping it. Jon -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 broken Was: [Simgear-cvslogs] CVS: SimGear/simgear/scene/model SGPagedLOD.cxx, 1.9, 1.10 modellib.hxx, 1.10, 1.11 modellib.cxx, 1.16, 1.17 SGReaderWriterXML.cxx, 1.19, 1.20
The 777 works / worked here , but trying to update FG this morning gets me a : AILocalTraffic.cxx:1542: error: ‘class FGViewer’ has no member named ‘getPosition’ so I'll do more checking in a bit ... -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 broken Was: [Simgear-cvslogs] CVS: SimGear/simgear/scene/model SGPagedLOD.cxx, 1.9, 1.10 modellib.hxx, 1.10, 1.11 modellib.cxx, 1.16, 1.17 SGReaderWriterXML.cxx, 1.19, 1.20
Hi Syd, syd adams a écrit : The 777 works / worked here , but trying to update FG this morning gets me a : AILocalTraffic.cxx:1542: error: ‘class FGViewer’ has no member named ‘getPosition’ so I'll do more checking in a bit ... The broke is pretty recent ( 2009-6-11 18:53Z ) so if you didn't managed to compile last Simgear, you likely miss it. My problem, duplicated on a Linux box, is that the MFD stay black after Autostart, even if I can hear the engine sound and take off. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Airports pavement.cxx, NONE, 1.1 pavement.hxx, NONE, 1.1 apt_loader.cxx, 1.23, 1.24 Makefile.am, 1.17, 1.18 simple.cxx, 1.61, 1.62 simple.hx
James Turner a écrit : On 14 Jun 2009, at 12:08, Frederic Bouvier wrote: FGPavement::FGPavement(const std::string aIdent, const SGGeod aPos) : FGPositioned(TAXIWAY, aIdent, aPos, false) Fred, are you sure we don't want to add a new FGPositioned::Type for this? I don't mind either way, it's whatever you think makes the most sense. The two format for taxiways will coexist for a while, so I added a new time. Don't know how it will be useful though -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] startup.nas
I've had another error message for the last few weeks while starting FG , Nasal runtime error: nil used in numeric context at data/Nasal/startup.nas , line 12 so it looks like environment/metar/base-wind-speed-kt is still nil when read the first time ... I fixed it locally , but not sure who added it , so I'll leave it alone -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 broken Was: [Simgear-cvslogs] CVS: SimGear/simgear/scene/model SGPagedLOD.cxx, 1.9, 1.10 modellib.hxx, 1.10, 1.11 modellib.cxx, 1.16, 1.17 SGReaderWriterXML.cxx, 1.19, 1.20
Hi Fred , Simgear compiled ok , but I guess I should switch to simgear-cs for scenery making ... Once I get FG to compile , I'll attempt to fix the 777 , if it has problems here. The broke is pretty recent ( 2009-6-11 18:53Z ) so if you didn't managed to compile last Simgear, you likely miss it. My problem, duplicated on a Linux box, is that the MFD stay black after Autostart, even if I can hear the engine sound and take off. -Fred -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Mac crashes / corruption with CVS
CVS seems to have developed a bad bug (since 1.9.1 based on some testing) where on my nVidia-based Mac, the display server hangs completely - I can ssh in and reboot the machine from the command line, but there's no way to get the GUI back. The crashes occur after a few minutes (sometimes after just one minute, sometimes ten or fifteen), and 1.9.1 seems to be okay - as does my ATI-based Mac, running Tat's CVS macflightgear build. *Sometimes*, instead of crashing, I instead get massive rendering corruption - all geometry becomes mapped to a single point in the centre of the window, at least on one vertex - this is accompanied by long lock-ups (several seconds). Generally after some time in this corrupted state the display server will hang as before, though if I'm quick I can quit flightgear and not have to reboot. Needless to say, all this makes testing very awkward. It's possible this is related to my specific machine, i.e the 7300GT in my Mac Pro is dying. However, 1.9.1 runs okay, and I've run other OpenGL apps at deliberately high settings, and haven't triggered any corruption or problems. Oh, and the crash occurs both with a build compiled myself, and with Tat's 'official' CVS binary build, so I don't believe it's a compiler / build problem - although my build files are derived from macflightgear ones, so I guess it could be a setting I've inherited from them. Anyone have any suggestions on figuring this out? Specific CVS commits that significantly changed OSG behaviour since 1.9.1? If anyone out there with a nVidia based Mac could run the Macflightgear CVS build, and report if they experience crashes or not (with OS-X 10.5.7), that would be very useful information. Regards, James -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
Frederic Bouvier wrote: Martin Spott a écrit : http://foxtrot.mgras.net/bitmap/FGFS/KSFO-861.png Not that, as shown here, not all v8.50 airfields match the quality measures we would expect - just take the northern part of taxiways L (east of 19L) as an example. This doesn't mean that we should not go for v8.50, I'm just trying to point out that we should consider selecting carefully. Are you sure you have the latest data, or you are not suffering a numerical precision problem ? Compare your screenshot with what is displayed in the ground radar : http://frbouvi.free.fr/flightsim/KSFO-850.png Ah, thanks for comparing. My reference airfields look correct, therefore I was under the impression that the v8.50 KSFO layout is flawed. It doesn't look like a numerical precision issue but obviously there's a fault at my end. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac crashes / corruption with CVS
I am running fg on an MacBook Pro (10.5.7) equipped with an GeForce 8600M GT graphics card. I have not experienced any problems with macflightgears 1.9.1 nor with the May 19 CVS package (my 1 hour flight ended just a few minutes ago). I usually run a non-macflighgear based fg that I build frequently without any problems related to the graphics card. Jari James Turner wrote: CVS seems to have developed a bad bug (since 1.9.1 based on some testing) where on my nVidia-based Mac, the display server hangs completely - I can ssh in and reboot the machine from the command line, but there's no way to get the GUI back. The crashes occur after a few minutes (sometimes after just one minute, sometimes ten or fifteen), and 1.9.1 seems to be okay - as does my ATI-based Mac, running Tat's CVS macflightgear build. *Sometimes*, instead of crashing, I instead get massive rendering corruption - all geometry becomes mapped to a single point in the centre of the window, at least on one vertex - this is accompanied by long lock-ups (several seconds). Generally after some time in this corrupted state the display server will hang as before, though if I'm quick I can quit flightgear and not have to reboot. Needless to say, all this makes testing very awkward. It's possible this is related to my specific machine, i.e the 7300GT in my Mac Pro is dying. However, 1.9.1 runs okay, and I've run other OpenGL apps at deliberately high settings, and haven't triggered any corruption or problems. Oh, and the crash occurs both with a build compiled myself, and with Tat's 'official' CVS binary build, so I don't believe it's a compiler / build problem - although my build files are derived from macflightgear ones, so I guess it could be a setting I've inherited from them. Anyone have any suggestions on figuring this out? Specific CVS commits that significantly changed OSG behaviour since 1.9.1? If anyone out there with a nVidia based Mac could run the Macflightgear CVS build, and report if they experience crashes or not (with OS-X 10.5.7), that would be very useful information. Regards, James -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
