Re: [Flightgear-devel] Re: Wing motion
Melchior FRANZ schrieb: Unfortunately, so far it only works with solid (unsmoothed) objects. Looks like a plib bug to me, but I have yet to find the exact reason. Maybe the normals of the faces don't get interpolated as well? (Just a stab in the dark) Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Wing motion
Hi, Josh Babcock schrieb: Especially if there are a lot of other objects attached to it. The B-29 has over a hundred objects attached to the wings. Each of those would have to be animated with the wings, and that would mean duplicates of all of them using the tween method. Just an idea, but would it help to define a specialised bending animation instead of the general purpose morph? By defining a transformation function which could bend a structure and applying it to all meshes in a given branch at least bending the wings could be made a whole lot easier for the modellers. Such a function transforming a point p into p' could be (out of the back of my head) p'=p+k*u*((p-p0)*v)^2 where p0=(p0x,p0y,p0z) defines a fixpoint of the transformation, u=(ux,uy,uz) with defines the up-axis in which direction the mesh is bent and v=(vx,vy,vz) defines the axis along which the bending increases. k*||u|| and ||v|| define the strength of the bending, where k is a floating factor controlling the bending just like the morphing factor. Hrm, no that would still leave us with the problems regarding the other animations (center-points, rotation axes), except if these would be applied before the bending. Ah, well, I'll go back to my scenery now ;-) Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Hi, Paul Surgeon schrieb: We're still stuck not being able to model airports properly. TaxiDraw is a great tool but I really don't like being limited to rectangular taxiway sections - they look awful. Work is under way for major modifications to TaxiDraw, which also target different modelling possibilities. However, this is nothing which is done in a day or even seven days ;-) Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Re] Buildings?????
Hi, Buchanan, Stuart schrieb: --- Steve Hosgood wrote: On Wed, 2005-11-23 at 18:01, Martin Spott wrote: I know this topic comes up from time to time, but it strikes me that the only way you can ever hope to handle the custom terrain scenery question is to cater for a two-layer approach: Hi Steve, Apologies if I've misunderstood your answer, but I think we can already do this by setting the FG_SCENERY environmental variable appropriately. This is actually the way I'm using the Lake Constance scenery and it's the way proposed on the Lake Constance Scenery Download site. It works. Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Re] Buildings?????
Steve Hosgood schrieb: [SNIP] OK, so what was the original poster bothered about again? Sounds like it's all working as expected. I suppose I could complain that maybe the reliance on an environment variable to point to the scenery may be great for scenery developers, but isn't so great for package maintainers who might like to try and make (say) FlightGear-LakeConstance-Scenery-0.9.9-0.rpm Rather difficult for the post-install script in a package to make sure that the users' environment gets updated to know about the new scenery. Even more difficult to remove it cleanly and correctly afterwards when they uninstall the package. Probably the idea was to have some automagic way of creating or amending that scenery search path. One way would be to have some directory, where you could put subsceneries in, e.g., /usr/share/FlightGear LakeConstance Terrain Objects SanFrancisco Terrain Objects etc. Scenery installers would just drop their stuff into that directory (let us not discuss about the actual location, we had that discussion already; we might only discuss how an installer would find the actual path on the target system) and FlightGear or some other tool would create an appropriate scenery path list from that. Ordering would have to be taken care of as well, as you wouldn't want the standard scenery on top of your custom scenery installations - well, you could, but you could then as well deactivate that custom scenery ;-) It might be possible to add something like that to fgrun, but I've only just recently found out that there is such a thing ;-) Might also be a good idea to add some meta information - author, version, (short) description, license, whatever - for display in the scenery configuration tool. Oh, and there's that other thing: I plan on adding some nice AI features to the LakeConstance scenery in the future, such as ferries on the lake, the Zeppelin making its sightseeing tours, etc. It would be great if one could just drop the scenario configuration files into that LakeConstance subdirectory - might as well be LakeConstance/AI or whatever - to have them loaded, instead of having to instruct the user to modify their preferences.xml or similar. Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Re] Buildings?????
Hi, Thomas Förster schrieb: [SNIP] The complaint was not about being able to have customized scenery. The complaint was that there is no way of customized scenery to become part of the standard scenery. That way everyone could share the joy of nicely modelled local sceneries, not just the original creator. Oh, we might very well consider customized scenery outside the standard scenery. For example, it is not possible to do photo scenery outside the US as a free package. It's just too costly. However, that's not the problem here. ;-) Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Searching for TerraGear-Bug-Hunters
Hi all, about two weeks ago Curt started preparations for a scenery regeneration run using the new shapefile data from Martin Spott's Terrain Data Database. In order to be able to accept custom scenery modifications to the standard scenery we need to get this part working. This is what he reported to me: I haven't had a chance to dig into this yet (and I'm not sure I will today) but when processing the rivers_stream database, it reports 760648 records. However, the process quit peacefully after processing only about 72000 records (i.e. 10% of the reported number of records). Any ideas. I didn't see any sort of segfault/coredump type message. I was unable to reproduce the problem up to now and we're kinda stuck. I'm therefore searching for helpers who can get TerraGear running on their system and try to reproduce the bug. You can use src/Prep/ShapeFile/process.sh for this. Download the shapefiles ftp://ftp.ihg.uni-duisburg.de/FlightGear/TGShapes/rivers_stream.tar.bz2 and optionally ftp://ftp.ihg.uni-duisburg.de/FlightGear/TGShapes/landmass_default.tar.bz2 and untar them into a new directory. Change process.sh to have SHAPEBASE point at these shapefiles and WORKBASE at a place where you want to put the results. Try it only with rivers_stream.tar.bz2 for starters, but I'm not sure whether the previous instance of shapedecode (decoding landmass) already mixes up the working directory, which could cause the crashes as well. WARNING: This test run will take many GBs of your free disk space. The last time I tried, I wasn't yet at the 72000 records mark and my disk was full (previously 5GB free). So far we found out that the polygons for lines touching the date line (180 deg longitude E/W) get mixed up, as the widened polygons for these lines cross the date line. However, we were not able to find out whether this has anything to do with the crash/termination Curt described. So far Curt saw it crash on these records: 72447, 194774, 196576 Thanks in advance. Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [0.9.9] screenshots for flightgear.org
Hi, Georg Vollnhals schrieb: http://home.arcor.de/vollnhals-bremen/FGScrSh/FGSrSh0005.jpg http://home.arcor.de/vollnhals-bremen/FGScrSh/FGSrSh0006.jpg can I trust my eyes? This must be from the lake-constance scenery...near Bregenz...cool! ;-) Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Hi, Martin Spott schrieb: Several people did comparisons between VMAP0 data and reality and it looks like VMAP0 is not very accurate at all in this area. I expect that we an offer a guide to the community in the not so distant future that explains how people can improve the landcover data and submit these improvements. Erm, yes...working on the GRASS-HowTo for Scenery Designers ;-) Didn't get far yet... Regarding the quality on VMAP0, I can't tell for the whole world, but at least in the South Germany area I have found bogus freeways and lots of important details are missing, such as landmark intersections for reporting points, whole towns and cities, etc. My hometown wasn't in there!!! ;-) With the standard scenery I couldn't find my way around my very home area...which should mean something ;-) With the altered scenery I do. Please keep in mind that carefully altering landcover data might comsume a noticeable amount of time On the other hand you will be compensated by very nice visual effects, Oh yes! :-) Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Joystick issues with throttleAxis()
Hi, some time ago a new version of the joystick configuration file for Logitech Wingman FF 3D was committed, containing a change to the throttle-handling. Shortly after that I couldn't get the engines down to idle. As I noticed, jsdemo reports that the throttle axis returns +0.3 when on idle. I'm using Linux on a 2.6.8 kernel. I thought that plib would calibrate the joystick axes to 0 in the positions they are in on construction of the plib Joystick object. However, there is no evidence on this in the plib code. I had to go back to a previous version of the configuration file and idling worked again. Maybe we should have a general calibration utility and load the resulting data on FlightGear startup. This would also spare us some of the offset-hacks in joystick configuration files. I don't have time right now (maybe within a week's time), but if nobody else jumps in I'll create a tool as soon as I have time. Best regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Joystick issues with throttleAxis()
Hi, Dave Culp wrote: On Wednesday 09 November 2005 12:58 pm, Ralf Gerlich wrote: [SNIP] Shortly after that I couldn't get the engines down to idle. As I noticed, jsdemo reports that the throttle axis returns +0.3 when on idle. I'm using Linux on a 2.6.8 kernel. That configuration file applies an offset of -0.3 prior to the scale. That shouldn't be allowed, and I guess someone's personal configuration snuck in by accident? The major change to that file was that appropriate Nasal-scripts are used on throttle and other axes and that's a Good Thing (tm). However, that effectively broke the calibration that was in there, as throttleAxis() and friends don't currently support these offsets. I was just thinking of a more general way of solving the calibration issues than putting it into the configuration files. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS make error (Cygwin)
Hi, Kevin Jones wrote: Hi, CVS FG source at 2:30pm (UK time) Monday 7th November fails to make on Cygwin with the following error: make[2]: Entering directory blah/source/src/MultiPlayer make[2]: *** No rule to make target `tiny_xdr.cpp', needed by `tiny_xdr.o'. Stop. Can anyone help? Had the same error yesterday on Linux. You need to rerun ./autogen.sh in the FlightGear source root. Hope this helps, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New Release of Lake Constance custom scenery
Hello, Georg Vollnhals schrieb: Hi Ralf, thank you and all the Lake Constance Team Members for improving that wonderful piece of (scenery) cake for VFR flyers. I just managed due to lack of freetime to make a freeflight around LOIR (to the south and north) and could clearly see what you improved when passing the borders of the scenery in the south (barrier). Flying further it really looks very odd! Hm, this actually is due to the fact that I generated all scenery tiles within the bounding box around our data. This means that we have some tiles where nothing than airports and hills and mountains covered by forest are present. I should remove the empty tiles so that the standard scenery can come through there. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New Release of Lake Constance custom scenery
Hello all, Ingrid has been working hard on the scenery data and we're proud to release a new version of the Lake Constance custom scenery. In fact it is not only a scenery of Lake Constance anymore. The new scenery has lots of the alps east of the Lake Constance, so you can fly from Fuessen (site of the well-known Castle Neuschwanstein - which is not yet in the scenery ;-) to the Lake Constance all by visual navigation. There are lots of valleys to explore. Just have a look at the status page. We even have Kempten and Memmingen. The nearest airport to Fuessen is Reutte (LOIR), a nice little grass airstrip with a challenging traffic pattern. You can find the approach plans (http://tr000127.host.inode.at/flugsportverein-reutte.at/images/anflugblatt.pdf) from the site of the Reutte aviators club at http://www.flugsportverein-reutte.at/ Follow the Lech river from Reutte to the north. LOIR lies just at that river. The Lech turns to the west and the valley opens up. North of that valley lies Fuessen, with the artificially backed-up lake Forggensee. Following the border of the Alps to the West, you will after about 40NM reach Lindau at Lake Constance (cannot miss it). Follow the northern shore towards the west and you will reach Friedrichshafen after another 10NM. Perhaps I will publish some more routes through the alps ;-) You will find that the view is absolutely breathtaking :-) The homepage of the project can be found at http://web44.netzwerteserver2.de/ The scenery is on the Download page. Have fun! Best regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Winter Textures - screenshot
Hi, Arnt Karlsen schrieb: On Sat, 22 Oct 2005 11:27:56 +0200, Ralf wrote in message I'd say we need different texture-names for lakes which freeze in the winter and those that don't. ..aye. Delay lake freezing around river mouths and speed thawing there, the currents. We want Artic ocean 'n bay 'n fjord freezing too? ;o) Erm, ok...working on custom scenery all the time I forgot that the VMAP0 data does not give us this information. %-) Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Winter Textures - screenshot
Hi, Dave Culp schrieb: screenshot: http://home.comcast.net/~davidculp2/PC7-winter.jpg BTW, my lakes are still blue. Do we need an ice-water texture? The Lake of Constance - the greatest lake in German-speaking Europe - only seldomly freezes. The last so-called Seegfrörne (lake-freezing in the local dialect) was in the 60's. I'd say we need different texture-names for lakes which freeze in the winter and those that don't. Best regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Never ending story: Building SimGear CVS under Cygwin
Hi, was this resolved somehow? I'm trying to get current FlightGear+TerraGear compiled on pure Cygwin (no -mno-cygwin) and get the same problem on compiling SimGear. I have installed opengl and freeglut and I don't find the WGL_... symbols anywhere except for simgear/screen/extensions.hxx, where it only is defined if GL_ARB_multisample is not defined. GL/glxext.h defines GL_ARB_multisample and seems to be included indirectly over some levels from GL/gl.h I applied a quick fix, removing the WGL_... #defines in extensions.hxx from the surrounding #ifdef and now SimGear compiles, but I didn't yet get to running FlightGear. BTW @Norman: What version of OpenAL did you use for preparing the OpenAL-binaries for Cygwin to be found on your site? Did you apply any patches to that? Best regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
Hi, Ampere K. Hardraade schrieb: [SNIP] Time might as well be spent on thinking of how we are going to convince Robin to use our new format instead of thinking of a way to expand Robin's database. I think that Robin could actually be pretty open for this: http://x-plane.org/home/robinp/#Future However, as he indicates in the last paragraph of that section, he has his own constraints... Best regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
Hi, Ampere K. Hardraade schrieb: [SNIP] One can use rectangular or bent taxiway sections but when you get to all the weird and wonderful taxiway layouts it's impossible to do with a generic taxiway structure. This is very apparent where taxiways intersect other taxiways, runways or aprons. The only thing that made sense to me was a 2D CAD type app like TaxiDraw which can draw polygons of any shape and size. [SNIP] I agree with the accessment that using raw polygons is about the only way to have proper taxiways. Really, a taxiway is anything but rectangular, and no matter how you mix and match a bunch of rectangles, it is simply impossible to achieve the level of complexity that you can see in real life. A CAD type application for drawing taxiways may not be a bad idea. However, I think that the process of taxiway generation should have nearly zero human involvement instead. We may not be able to reach this. However, I think that a combination of different tools for different objectives could do the trick. For example, the basic taxiway layout could be done by drawing the centerline as a polyline or spline. This data could also be used for exporting the AI data for Durk's ground AI. For all specialities this could be refined using more general geometry, such as polygons or whatever is suitable. No need to force pure polygon editing only because there may be a few places on an airport where we may need it. Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
Martin Spott schrieb: [SNIP] With the layout I've proposed you'll be able to determine everything that's needed: The taxiway direction and hence the direction of the centerline are determined by the perpendicular on the face sides of the junction, where the regular taxiways are being connected. You can determine how the centerline crosses the junction by calculating a spline between these two opposing perpendiculars. You have an exact description of the arc between the crossing taxiways and you have the ability to smoothly connect the arc to the straight part by determining the point where the tangent of the arc matches the straight taxiway boundary line. With that you almost described what I had in mind for further improvement. I'd also favour a compact format in which all such information is to be found. Sometime in the future we may have a graphics engine which supports drawing rounded taxiways on the fly using some kind of dynamic level of detail, getting rid of straight rounds. We wouldn't want to start over once again with the taxiway format. Actually, the more compact and more abstract the data format is, the easier editing will become. I don't want to draw two sides for every constant width taxiway I edit. However, we might also need more finegrained editing features for layouts as Paul showed in his screenshots. We won't be able to make a full jump from the current rectangle format to the final new format, but we should what we're aiming at. I'd also propose keeping the old genapts and editing using rectangles in there as long as the X-Plane folks haven't yet jumped on our train and as long as the majority of airports is still in this format. Also we don't want to risk the huge number of X-Plane airport designers using Taxiway now to be scared away just because we're moving on. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
Hi, Christian Mayer schrieb: Paul Surgeon schrieb: On Saturday 15 October 2005 23:44, Ralf Gerlich wrote: Hi, I hope I don't say too much if I say that there is work planned on defining taxiways by means of polylines in TaxiDraw. That's still very restrictive. It's a step in the right direction but is still far from what is needed. We need polygon editing and not just polylines. Taxiways are unfortunately too full of non-parallel sides for polylines to work properly everywhere. How would you draw these taxiways with polylines? The original intention was to produce both ground AI data and the scenery representation from these polylines. The line segments and joints should be automatically converted to an appropriate approximation using rectangles. However placing rectangles will still be available, at least in what I have in mind. I'd definitely favour a new format with polygons, proper curved centerlines, etc., but currently the X-Plane format does not support this and we currently have no way of syncing it with Robin Peel's database - except by generating polygons from Robin's data just the way we're doing it now. However, I don't think that is the intention. I'm not sure how important giving back to Robin's DB is for the FlightGear community but in the OpenSource manner I'd say we should try to find a way of not doing things twice in two communities. Polylines should be sufficient (as long as you don't need things like bridges, i.e. stay 2D). To find out if you are outside (e.g. on grass) you do a line walk. I.e. you start on the outside (e.g. from far far away) and walk on a line to the desired position. On that walk you cound how often you've crossed a polyline. Each time you cross it you change from outside to inside (or the other way round). You are probably talking about planar partitioning, where different faces are defined by separating lines. (The only links I can find in a quick google search on topological maps, planar maps or DCEL (doubly connected edge lists) are from the CGAL-manual or non-introductory papers) [SNIP] Doesn't TaxiDraw already use CGAL? With CGAL you've got all that you need for that. TaxiDraw doesn't use CGAL currently. Best regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
Hi, I hope I don't say too much if I say that there is work planned on defining taxiways by means of polylines in TaxiDraw. For starters I intended to create rectangles from that polyline data as appropriate, keeping the old format. Best regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Hi, Jon Stockill schrieb: Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. esd or artsd would allow you to share the device. I suspect you'd need to start the sound daemon, then your comms s/w (which would need to use the device read/write), then flightgear (write only). I'm starting FlightGear on Linux as esddsp fgfs which essentially detours access from /dev/dsp to the sound daemon. There is a delay in audio of about 1/2s (try the flaps), but otherwise it's fine. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] a new doc file to document the realtime wx update
Hi, Vassilii Khachaturov schrieb: I suggest to name it data/Docs/README.Real-WX Real-world Weather Update = Launch fgfs with the following two command-line switches in addition to whatever else you put there: $ fgfs --prop:/environment/params/real-world-weather-fetch=true --prop:/environment/params/control-fdm-atmosphere=true Why not --enable-real-weather-fetch? Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] a new doc file to document the realtime wx update
Hi, Vassilii Khachaturov schrieb: $ fgfs --prop:/environment/params/real-world-weather-fetch=true --prop:/environment/params/control-fdm-atmosphere=true Why not --enable-real-weather-fetch? Because I didn't know about the shorthand option :-) :-) BTW, the second property is not affected by this switch still; Hm, this is interesting. As far as I see the switch controls whether temperature, pressure and air density are passed on to the FDM - which _I_ didn't know about. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How does the weather work in FlightGear?
Hi, Mike Rawlins schrieb: Maybe the best solution would be to make the transition of cloud height, air temperature, and wind from one METAR to the next occur over some length of time (minute or so), rather than abruptly. If this is possible. I think this could be a good idea at least for clouds. Air temperature and pressure could be interpolated spacially, e.g., by IDSW or similar. Maybe there is even a possibility to realistically interpolate wind speed and direction this way. Possibly the issue about air pressure would be most interesting for realistic flights over longer distances. I don't have a pilot's license, but I know a German saying Vom Hoch in's Tief geht's schief, meaning something like flying from high pressure region into low pressure region will make you descend when you don't check your barometric pressure setting regularly. I'd say that a slow change of pressure is more likely to evade the attention of a pilot than a sudden change in altitude indication. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Some new AI traffic screen shots
Hi, Durk Talsma schrieb: Hi Folks, A few days ago I promised to put some AI traffic screenshot on my website. The site's up and running again, so here they are. This looks absolutely great. When do you think we will be able to see first versions of this in the CVS or via a patch? Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] weird crash in sgMakeLeaf()
Hi all, I did some further analysis on this bug and I found that in line 237 of leaf.cxx texcoord = texcoords[ tex_index[i] ]; tex_index[i] is negative in the case of the crash. Specifically, the value in my case is 0x8000, which looks like a short-to-int-conversion problem. (Yes, the custom scenery is pretty detailed in some parts and yes, I'm working on a reduction of vertices as well ;-) IIRC there was a change to the scenery code from short to int some time ago. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [fixed] weird crash in sgMakeLeaf()
Hi,
this patch should fix the bug.
Regards,
Ralf
Ralf Gerlich schrieb:
Hi all,
I did some further analysis on this bug and I found that in line 237 of
leaf.cxx
texcoord = texcoords[ tex_index[i] ];
tex_index[i] is negative in the case of the crash. Specifically, the
value in my case is 0x8000, which looks like a
short-to-int-conversion problem. (Yes, the custom scenery is pretty
detailed in some parts and yes, I'm working on a reduction of vertices
as well ;-)
IIRC there was a change to the scenery code from short to int some time
ago.
Regards,
Ralf
Index: simgear/io/sg_binobj.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/io/sg_binobj.cxx,v
retrieving revision 1.8
diff -u -r1.8 sg_binobj.cxx
--- simgear/io/sg_binobj.cxx 1 Oct 2005 11:41:59 - 1.8
+++ simgear/io/sg_binobj.cxx 11 Oct 2005 17:16:08 -
@@ -240,8 +240,8 @@
if ( nbytes buf.get_size() ) { buf.resize( nbytes ); }
char *ptr = buf.get_ptr();
sgReadBytes( fp, nbytes, ptr );
- int count = nbytes / (idx_size * sizeof(short));
- short *sptr = (short *)ptr;
+ int count = nbytes / (idx_size * sizeof(unsigned short));
+ unsigned short *sptr = (unsigned short *)ptr;
int_list vs; vs.clear();
int_list ns; ns.clear();
int_list cs; cs.clear();
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] weird crash in sgMakeLeaf()
Hi all, I'm getting weird SIGSEGV crashes in sgMakeLeaf, specifically in line 238 of simgear/scene/tgdb/leaf.cxx. I'm still in the progress of finding a way to reproduce this as the crash tends not to occurr sometimes, under conditions which I haven't found out yet. I suspect that it has something to do with our custom scenery, but I'm not sure yet. I'm just writing to find out whether others on this list had a similar problem. I have attached the printout of gdb so that maybe somebody can say if (s)he had a similar incident. Of course the addresses will not help, but maybe the structure of the messages. I'll come back to you if I have further information. Regards, Ralf [EMAIL PROTECTED]:~/misc/aviation$ gdb fgfs GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /home/ralfg/misc/aviation/install/bin/fgfs [Thread debugging using libthread_db enabled] [New Thread 1082866720 (LWP 10491)] opening file: /home/ralfg/misc/aviation/src/FlightGear-base/Navaids/carrier_nav.dat /home/ralfg/misc/aviation/src/FlightGear-base/Navaids/TACAN_freq.dat [New Thread 1309903792 (LWP 10494)] [New Thread 1384573872 (LWP 10495)] instrument name: adf instrument name: adf instrument name: airspeed-indicator instrument name: altimeter instrument name: attitude-indicator instrument name: clock instrument name: dme instrument name: encoder instrument name: marker-beacon instrument name: heading-indicator instrument name: KT-70 instrument name: magnetic-compass instrument name: nav-radio instrument name: nav-radio instrument name: slip-skid-ball instrument name: transponder instrument name: turn-indicator instrument name: vertical-speed-indicator instrument name: gps instrument name: wxradar instrument name: tacan Initializing Nasal Electrical System Program received signal SIGINT, Interrupt. [Switching to Thread 1082866720 (LWP 10491)] 0x404d0544 in ioctl () from /lib/tls/libc.so.6 (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/ralfg/misc/aviation/install/bin/fgfs [Thread debugging using libthread_db enabled] [New Thread 1082866720 (LWP 10496)] opening file: /home/ralfg/misc/aviation/src/FlightGear-base/Navaids/carrier_nav.dat /home/ralfg/misc/aviation/src/FlightGear-base/Navaids/TACAN_freq.dat [New Thread 1309903792 (LWP 10497)] [New Thread 1384573872 (LWP 10498)] instrument name: adf instrument name: adf instrument name: airspeed-indicator instrument name: altimeter instrument name: attitude-indicator instrument name: clock instrument name: dme instrument name: encoder instrument name: marker-beacon instrument name: heading-indicator instrument name: KT-70 instrument name: magnetic-compass instrument name: nav-radio instrument name: nav-radio instrument name: slip-skid-ball instrument name: transponder instrument name: turn-indicator instrument name: vertical-speed-indicator instrument name: gps instrument name: wxradar instrument name: tacan Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1309903792 (LWP 10497)] sgMakeLeaf ([EMAIL PROTECTED], ty=6, matlib=0x55002790, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], calc_lights=true, lights=0x53d3fbf8) at point3d.hxx:209 209 point3d.hxx: Datei oder Verzeichnis nicht gefunden. in point3d.hxx (gdb) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Microsoft artwork (!) in the 707 panel
Hello, Oliver Correll schrieb: 2. To repaint the parts I took from the package There I have one questions: When I go to the aircarft museum and take some cockpit photos. Can I use them for panel painting (like the 737 panel) ?? You will need permission from the museum or aircraft owner to use the photo commercially. At least in Germany. I'm not sure whether commercially is the right word for this. IANAL, but the German legal term is AFAIK geschäftsmäßig, which basically means anything one a regular basis, not necessarily requiring an exchange of money between provider and client. This seems to include distribution of such a photo as part of a panel for open download from the internet. Remember: IANAL. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Elevation Contours and DEM experiment results
Hi all, as we had the original discussion about elevation contours on the flightgear-devel list, I'm crossposting this to flightgear-devel and to terragear-devel, however I'd suggest replying to terragear-devel as this is essentially a TerraGear issue. After the discussion about integrating elevation contours into TerraGear-generated scenery I did some experiments using digitised elevation contours from current topographical maps and interpolations from the standard SRTM DEM data. I used GRASS to digitise contour data from scanned topographical maps and generate a DEM model with about 4m/pixel resolution for a small region using the v.surf.rst tool from GRASS. The resolution is quite arbitrary, as it is the resolution of my scanned topomaps. Then I interpolated the SRTM data for the same region and resolution using a cubic interpolation. I found that both the interpolated SRTM DEMs and the DEMs generated from the contour lines are quite similar. Generating contours from the interpolated SRTM DEMs and laying them over the digitised contours confirmed this finding. The contours do not differ substantially from each other. I then interpolated the SRTM DEMs for some other regions, generated contours and overlaid them to the topomaps. Again, the contours from the interpolated SRTM DEMs quite well match those from the topomaps - at least I think that the differences in terrain won't be noticable for the human eye. Unfortunately I've thrown away the manually digitised countour lines - being a bit frustrated by the result - and for copyright reasons I cannot post an overlay of the contours generated from the SRTM DEMs and the topomaps I'm using. I'll however repeat the digitalisation for another area and post that together with the respective SRTM DEM contours if anybody is interested in a direct comparison. I then tried to import the fitted irregular elevation grid generated by Terra into GRASS and created an appropriate DEM for a small region. v.surf.rst does a spline interpolation, which will differ substantially from the flat approximation done by Terra and FlightGear for obvious reasons. I haven't found an appropriate tool in GRASS to do a linear interpolation, however I tried v.surf.rst with a smoothing setting of 0, making the interpolated surface go directly through the points of the irregular grid instead of approximating them smoothly. I calculated the differences between this interpolation and the interpolated SRTM DEM and found a standard deviation of about 43m. The irregular grid was generated using a maximum error of 40m and a maximum number of 1000 nodes. However the maximum deviation between the two DEMs is about 240m at at least one point. However this could be due to the non-linear interpolation of the grid. My conclusions from this are twofold: 1. There is no need to digitise contour data manually instead of extracting them from SRTM if your map material is based on SRTM - which seems to be the case for all of the maps I'm using. 2. The only advantage of integrating contour lines directly into the terrain would be to effectively bypass the fitting done by Terra. I'll try to get some comparisons up with real-life photos and Terra-fitted terrain, but I already got the impression that at least in the area we're working on with our custom scenery the hills and mountains just don't look right ;-) Maybe applying an interpolation in Terra similar to the one done by GRASS could yield some better looking results. Just thinking out loud here. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
Hi, Jon Stockill schrieb: [SNIP] Here's a couple of pics, the first is looking west over the gherkin, and the second is looking out over regents park. Generation time was over an hour for that tile on a 1GHz athlon (the resource limits in fgfs-construct needed a significant increase). Memory usage was ok at around 140MB. http://flightgear.stockill.org.uk/scenery/osmroads1.jpg http://flightgear.stockill.org.uk/scenery/osmroads2.jpg This looks quite detailed. I'm not that familiar with the London area so would you say that there is a considerable amount of smaller streets missing in there? Even with not so much detailed streets - i.e., leaving all the back-streets out and having only freeways and mainstreets processed - the generation of scenery takes substantially longer than for the standard data. I have no numbers on this, but having to raise the resource limits in fgfs-construct considerably is quite a good indication. One other problem that'll probably become more serious with more detailed street-data is that the comparatively small streets not only produce lots of small triangles on the streets themselves but also raise the number of triangles on neighbouring polygons by splitting them. (Currently fgsd crashes on loading some of the more full tiles - possibly because of the sheer number of triangles; I will investigate further on that when I get the time) I currently do not have any solution for that and I know that there have been discussions before, but perhaps having more detailed scenery now may be a good reason for the experts here to reconsider this topic. It shows up a few limitations in the source data. The road segments are currently all represented seperately and not tied into a road object, this results in lots of short roads, and visible breaks on the outside of corners. This will improve as the open streetmap system matures (it's still very early days). This may be solvable by automatically snapping endpoints and recombining shorter segments into longer segments. Anyway recombination will only partially solve the problem, as on an intersection only pairs of participating line-segments can be joined. Perhaps we need a better way of making polygons from lines, much like the v.buffer operation of GRASS (http://grass.itc.it/grass61/manuals/html61_user/v.buffer.html). Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
Hi, Ampere K. Hardraade schrieb: Google has some pretty accurate taxiways for their map. Check out http://pigeond.net/flightgear/fg_server_map.html in map mode. Does anybody where Google got their data from? You can get quite detailed aerial photos for most urban areas in the USA from http://www.terraserver-usa.com David Luff's TaxiDraw has support for automatically loading such photos and showing them in the editor. However, I'm still searching for free detailed aerial photos for other areas of the world such as Germany. Here the government wants you to pay twice for the photos: Once via tax and once when you want to use the photos. The license under which you get those photos here is quite limited as well. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
Hi, Ampere K. Hardraade schrieb: I think you misunderstood. I was referring to the taxiways under map mode, not satellite mode. If you go in map mode, you will see that Google got some pretty accurate vector data for taxiways generation. Whoop, didn't see that. In that case: Yes, I misunderstood and join your inquiry ;-) Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screen RenderTexture.cpp, 1.9,1.10
Hi, Erik Hofman schrieb: Update of /var/cvs/SimGear-0.3/SimGear/simgear/screen In directory baron:/tmp/cvs-serv2961 Modified Files: RenderTexture.cpp extensions.cxx Log Message: Mathias Fröhlich: [SNIP] Then the render texture again ... glxQueryVersion turns out to return the minimum of the client libraries glx version and the servers glx version. *All* Xorg servers return 1.2 here. So we never get the glxPBuffer functions which are the only ones working with ati's drivers ... Reverted back to checking the required functions and just use them if they are there. Still prefering the glx standard variants since they work on ati's drivers ... Yay! This brought back 3D-clouds which I've been missing for a long time (using XFree86 4.3 + ATI's proprietary driver for Mobility Radeon 9600) :-) Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom Scenery for Lake Constance
Hi, Georg Vollnhals schrieb: First, thank you Ralf for improving your work. I could now fly the VFR routes of the Visual Operation Chart EDNY from IVAO-DE and get clear through the mentioned reporting points. I never before flew such precise procedures just by looking out of the sim window. :-D But when I read your mail I know that it will be a long long way for me to go to get a similar scenery for my local area as there is a lot to learn. Actually I hope to have sorted out most of the major issues so that the learning curve is not so steep for others. [SNIP] 1. As all different streets are displayed in the same way it is a luck that you cannot get the smaller streets into the scenery. Yet it is difficult to follow some bigger streets when you come to a big street crossing and have a web of streets all looking the same. It would be nice if TerraGear could render different street-types with different colours (or even better, textures). 2. Is TerraGear able to render railway-lines with a darker colour, ie. dark brown? This would be more how you see older railway-lines from air, at least in Northern Germany. Currently, TerraGear and FlightGear have only two area-types which can be used for rendering streets: Road and Freeway. Both are currently mapped to the same texture. (see materials.xml in the root of your FlightGear data-package) There is also a Railroad material which is mapped to a gravel texture. However, when changing this texture, the same texture will be used for the appropriately marked areas all over the world. I suppose that, e.g., in the USA the gravel and road textures might match the actual texture of railroads and roads there. Probably the simplest solution here would be to add new area types for localised textures. Browsing throught the terragear-devel list archives I have come about a similar discussion, but up to now I haven't seen a conclusion on that. 3. Did you change the size of the streets? They appear too broad, I tested it with a Cessna and landed, it seems they have the width of 3 x Cessna wingspan :-) Given that the wingspan of a Cessna is about 10m this is actually too wide. According to the table I'm using for automatic generation, the widest street (Autobahn/Freeway) should be about 13m wide. And FlightGear Scenery Designer tells me they are about 50m wide...which happens to be the default width in the modified shape-decide...which might indicate that I actually forgot to specify the road width in my script. Doh! OK, I'll fix that ;-) In that case, many of the streets should be distinguishable by width in the next release. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom Scenery for Lake Constance
Hi, Alex Perry schrieb: Try watching your virtual memory usage and see whether you're hitting the 2GB (or 3GB) limit within that process. If you are, it is worth patching TerraGear until it runs cleanly on all 64 bit architectures. If it isn't a memory problem, we can stick with the 32 bit for now. I already had thought about that. I have Pentium-M with 512MB of RAM and a 1GB swap-partition. Interestingly fgfs-construct does not even get the 512MB filled up - with lots of daemons and stuff using up memory in the background. Even more interestingly, when I run an strace on the fgfs-construct process, I see that the process is eventually SIGKILLed. I suspected that this is some kind of resource control on the side of the Linux kernel, which may KILL your process if it's using up too much memory of CPU time. However, a SIGKILL for CPU time excess is always preceeded by a SIGXCPU, which I cannot see in the strace-log. In addition, 'ulimit' reports that the CPU usage limit is 'unlimited'. An out-of-memory-kill should - according to the kernel source - be accompanied with a message to the console or the kernel logs, and I can't see any such message. I have even stopped all background processes I could, effectively putting my machine to single-user-mode, in order to rule out any other processes being so rude as to kill my scenery construction process. Unfortunately, that didn't help: The kill did still occur. I tried to find out whether there was some specific point at which the process is killed - perhaps there is some correlation with a previous action - using nested intervals and as few as possible test printouts in order not to modify the time-related behaviour of the code too much. However the actual point in the code where the kill occurred jumped as soon as I moved a printout marker from one place to another and the places I observed did not seem to be related to the kill in any way. I'll try running the construction on a different computer. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom Scenery for Lake Constance
Hi, Curtis L. Olson schrieb: [SNIP] It's been a while, but scan the fgfs-construct code for some sort of ulimit checking built into the code. I seem to recall there was some code there that would cause the process to self destruct if it sensed it was taking too long or consuming too much memory? This is useful in the parallel build framework so that an infinite loop (our delauney triangulator and polygon clipping routines can go degenerate at times) doesn't derail the whole build. The thresholds may need to be tweaked or even eliminated. Thanks, that was the advice I needed. :-) Heh, two things I didn't think of: 1. I had checked whether I was setting ulimits, but I hadn't checked whether fgfs-construct itself is setting ulimits. I found a statement limiting CPU usage to 120s. This matches the fact that the generation was always aborted after about 2mins. 2. I expected SIGXCPU signals from the Linux kernel, which were not sent and thus I ruled out CPU-rlimits. However, SIGXCPU is only sent if the current limit and the hard limit differ. In case of fgfs-construct both the current and the hard limit are set to 120s. The generation is on the go and I'll probably release _two_ versions of the scenery this evening (UTC+2) - one with all the backstreets and one without. Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom Scenery for Lake Constance
Hi all, The generation is on the go and I'll probably release _two_ versions of the scenery this evening (UTC+2) - one with all the backstreets and one without. Nope, only one version - without all the small backstreets - most of the white lines to be seen on the Status page. However, Curt's tip helped me getting fgfs-construct to include at least the bigger main and backstreets, so that, e.g., NOVEMBER, ECHO and SIERRA can be identified now. I tried to make a version with all the small backstreets - including the nice street-nets inside the cities and towns. fgfs-construct did succeed eventually (after setting the CPU limits _way_ higher than they were), but FlightGear crashed on loading the scenery - so did FlightGear Scenery Designer. Probably this is actually too much. The uploaded scenery without the smaller backstreets runs quite smoothly in most parts. Frame rates on my box drop down to 15FPS in some places, but tend to rise again after a few seconds. Regarding the tool for importing GRASS-data I have dumped that and instead created a patch for the TerraGear shape-decode tool which can be found on our downloads page (http://web44.netzwerteserver2.de/195.0.html) The patch enables shape-decode to handle point and line data. Let us know what you think. We're open for (constructive) criticism and suggestions. Have fun! Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom Scenery for Lake Constance
Hi, Georg Vollnhals schrieb: Hi Ralf, I am a pure FlightGear user (since very early versions) and scanning the developers mailing list regularly. After your announcement I first flew the scenery from EDNY two days ago and now downloaded, installed your improvements and did several VFR flights with my ICAO chart and a more detailled street chart. Congrats! This is really a big step forward to increase the possibility of realistic VFR flying (next version with modelled NOVEMBER and ECHO :-) ?). For those not familiar with the vicinity of EDNY: NOVEMBER and ECHO are compulsory reporting points located above significant street resp. railroad tracks. Well, placing reporting points at significant landmarks is probably custom at nearly all airports, isn't it? As I said in the original announcement of the scenery screenshots, a huge number of streets, railroads, streams and rivers were digitised. You may want to have a look at the Status-page (http://web44.netzwerteserver2.de/209.0.html) where the digitalisation status of line- and polygon-data is shown. However, those data did not make it to the current scenery release as TerraGear choked, obviously due to the massive density of data. I'm going to further investigate this - maybe with a little help from the experts on this list - and I hope that we can at some point release at least some compromise version between nearly no linedata and 1 FPS ;-) The current selection of the data subset kept is arbitrary and not necessarily sensible. At this point I'd like to emphasise the great work of my project colleague Ingrid, who has done the whole digitalisation of the streets. (I'm beginning to feel guilty for all your congratulations being attributed to me ;-) ) Regarding VFR-training we'd like to take what we get in terms of geographic data, as after all in reality you don't see only those streets on the ground which are actually on your map. I'm no pilot myself (yet? ;-), but it was confirmed to me that confusing one street with another does happend and may be a serious navigation problem. Ingrid also models the typical cloverleaf-form of freeway intersections as significant landmarks. However, in the current release the line widths for the access roads seem to be a bit underestimated so these are not that easy to identify. [SNIP] With your help (tutorial) and after getting LINUX and TerraGear to a point where I can use it I would like to do so and (naturally) share my work with all interested when there will be a place to put it. My top priorities are now modifying the shapefile-reader in TerraGear to also understand line- and point-data, as to replace the quick'n'dirty GRASS-specific tool currently mentioned on the project webpage, and then writing documentation for getting started with digitalisation with GRASS. The latter will take some time, so bear with me. I did some modifications to the GRASS-CVS-version which help for digitalisation and will make patches, scripts and GRASS-binaries for Windows/Cygwin and - if necessary - Linux available. There's still lots of general challenges left. For example, those of you who've tried the scenery may have noticed some elevation anomalies in the area of the islands and the Rhine mouth near Altenrhein (LSZR). There the water has an upwards tendency toward the land mass, which doesn't look quite realistic. Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Custom Scenery for Lake Constance
Hi, Gerard Robin schrieb: Great, You probably did spend a lot of time. Yes, we did ;-) However, the digitising effort is quite relaxing - clearing your mind of any thoughts which may bother you. Especially after a hard day at work ;-) And we learnt a lot about our own area - and still keep learning. We have a lot of towns with funny names here. Not to forget we get to fly above our home area ;-) Even on the first round trips around the scenery you can still find new details you didn't actually notice before during digitalisation. As soon as I get time I'll document the process somewhat, hoping to get others started. This is quite a good field for improvement in FlightGear if you're unable to help with the coding. Let's see what comes around with Martin Spott's PostGIS server. Perhaps we'll see more improved scenery from other areas of the world soon. For the US-areas appropriate base material in the form of arial photos is quite easy to get (terraserver-usa.com, etc.). When I get around to doing a tutorial (working with GRASS, making scenery out of it, etc.), I'll try doing some part of San Francisco for the demo scenery from the standard data package. Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Custom Scenery for Lake Constance
Hi, Oliver C. schrieb: Very nice done. Looks great. Thanks ;-) Where can i download it? I'm in the process of organising some place for the scenery files. I'll send the link when I got one. However as far as the plans go the scenery will go into the PostGIS-Database Martin Spott is currently setting up. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Custom Scenery for Lake Constance
Hi, Where can i download it? The scenery is available for download at http://web44.netzwerteserver2.de/195.0.html I'll try to prepare the files in a form fgadmin can grok. Until then you need to adapt the FG_SCENERY-environment variable or the --fg-scenery option passed to fgfs. Enjoy! Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Custom Scenery for Lake Constance
Hello, some time ago I posted that I had some project for custom scenery around Lake Constance in the most southern part of Germany going. Now that the legal issues are solved I'm proud to present the first comparison screenshots :-) http://web44.netzwerteserver2.de/196.0.html The standard scenery (on the left of the pictures) is from today. And: No, the framerates are not representative. It's quite smooth on my Laptop under Linux (ATI Mobility Radeon 9600 M10). However, it could become tricky when all the roads and streets are added, which a friend of mine digitized. Actually I had to reduce them to major freeways and railroads as TerraGear choked on the smaller roads. Interestingly it's killed some time into the process by a SIGKILL which doesn't come from itself. I already had a look into the kernel logs but no out-of-memory-kill is logged and CPU-overload-killing would have seen SIGXCPU before. Besides: I have set no limits on CPU-load and memory is far from out when the KILL happens. I'll have to figure that out. We haven't digitised all area data (population, forest, etc.) around the lake yet so at some points it's just green, but as somebody living there I can tell you: The custom scenery is far more like the real thing than the standard scenery. ;-) For example, VMAP0 has a highway going nearly all the way through the area north-west of the lake. This highway does not exist. It was planned though, but never built. We already did quite a number of flights around the new scenery and now it's actually possible to navigate visually. VMAP0 is missing some of the towns so you never know what town it is you see below you ;-) Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cygwin/Terragear/nurbs problem
Buchanan, Stuart schrieb: Hi All, I'm trying to compile TerraGear on Cygwin, after enjoying FlightGear for a while and deciding to put something back. I've already compiled/installed SimGear, and now I'm trying to compile nurbs++ 3.0.11, which is failing with the error at the bottom of the mail. I'm using gcc v3.4.4. I recall seeing a message previously suggesting that one should use gcc v3.3.3, but I haven't managed to find it again, and I can't get the cygwin setup program to allow me to downgrade to it. There is a conveniently named patch-file in the TerraGear sources which is to be applied to the nurbs++-sources when compiling with gcc 3.4.4. You might want to have a look at README.nurbs++ in TerraGear. However, when I tried compiling TerraGear,nurbs++ et al. under Cygwin the last time there was a problem with some unqualified-id being expected in stl_bvector.h, which is a header-file from the libstdc++. I didn't come to solve that. Interestingly the same header-file is used by mingw32, but no syntax error there, IIRC. Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cygwin/Terragear/nurbs problem
Buchanan, Stuart schrieb: Hi Ralf, My terragear source doesn't include that README (I've got the 0.9.8 release as opposed to a CVS version). What version were you using? Any chance you ould point me at the README and replacement .h files? The patch is here: http://cvs.terragear.org/cgi-bin/viewcvs/viewcvs.cgi/TerraGear/PATCH-nurbs%2B%2B-3.0.11-with-gcc-3.4.x?rev=1.1cvsroot=TerraGear-0.0content-type=text/vnd.viewcvs-markup and the README is here: http://cvs.terragear.org/cgi-bin/viewcvs/viewcvs.cgi/TerraGear/README.nurbs%2B%2B?rev=1.2cvsroot=TerraGear-0.0content-type=text/vnd.viewcvs-markup alternatively you could install CVS on cygwin and checkout the current CVS version of TerraGear ;-) Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Hello, 3) artificial life at airports The server gives a lot of opportunities. One of the first things which came to my mind was artificial traffic at airports. It should be fairly easy to write clients in any (network capable) language which do simulate a client. This can be simply a helicopter standing near a hangar or even a plane flying around an airport. This would disburden fgfs itself (since it does not need to create AI traffic itself) and allow an arbitrary number of artificial clients, each serving it's own airport (or whatever area), bringing life to many areas of the world without manipulating fgfs itself. I'm very far from knowledgeable about the respective source structures in FlightGear and just thinking out loud, but perhaps it would be possible to extract the AI-code already being developed inside FlightGear to an external software package which could take the task of injecting such AI clients in the network? If the code is modular enough, the AI module could be plugged into such a multiplayer-bot as well as into the main FlightGear code, where in the latter it would be used for single player mode. Alternatively FlightGear could startup a local multiplayer network on localhost if the user is not participating in a multiplayer session and wants to have AI planes flying and taxiing around. As I said: I'm thinking out loud and I have no idea of the AI/ATC-code, so bear with me *duck* ;-) Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Patch for fgjs.cxx and jsinput.[h,cxx]
Hello,
find attached a patch for fgjs.cxx and jsinput.[h,cxx] (current CVS).
The changes are:
- automatic detection of axis directionality, so that axis inputs are
appropriately inverted only when necessary
- fixed trim axis names for better understandability
- fixed signs for flaps up/down property increments
- button 0 was previously used for skipping axes and buttons in both
loops. Now button 0 can be assigned a binding (e.g., brakes). Instead,
moving any axis during the button-assignment-loop indicates skipping.
- The user is now told how to skip a control.
I have tested it with a Logitech WingMan Force 3D, but I don't see any
reason why it should not work for other sticks ;-)
Regards,
Ralf
Index: src/Input/fgjs.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/fgjs.cxx,v
retrieving revision 1.7
diff -u -r1.7 fgjs.cxx
--- src/Input/fgjs.cxx 25 Jun 2005 07:57:42 - 1.7
+++ src/Input/fgjs.cxx 18 Jul 2005 10:19:41 -
@@ -50,15 +50,18 @@
/sim/current-view/goal-pitch-offset-deg
};
+string axis_posdir[8]= { right, down/forward, right, forward,
forward, forward, left, upward };
+
+
bool half_range[8]={ false,false,false,true,true,true,false,false };
bool repeatable[8]={ false,false,false,false,false,false,true,true };
-bool invert[8]= { false,true,false,false,false,false,false,true };
+bool invert[8]= { false,false,false,false,false,false,false,false };
string button_humannames[8]= { Left Brake, Right Brake,
Flaps Up, Flaps Down,
- Elevator Trim Up, Elevator Trim Down,
+ Elevator Trim Forward, Elevator Trim
Backward,
Landing Gear Up, Landing Gear Down
};
@@ -76,7 +79,7 @@
bool button_boolean[8]={ false,false,false,false,false,false,true,true };
-float button_step[8]={ 1.0, 1.0, 0.34, -0.34, 0.001, -0.001, 0.0, 1.0 };
+float button_step[8]={ 1.0, 1.0, -0.34, 0.34, 0.001, -0.001, 0.0, 1.0 };
string button_repeat[8]={ false, false, false, false, true, true,
false, false };
@@ -379,7 +382,8 @@
for(control=0;control=7;control++) {
cout Move the control you wish to use for
axes_humannames[control]
-endl;
+ axis_posdir[control] endl;
+ cout Pressing a button skips this axis\n;
fflush( stdout );
jsi-getInput();
@@ -397,6 +401,7 @@
if (strcmp(answer,n)==0) {
control--;
} else {
+ invert[control]=!jsi-getInputAxisPositive();
if (usexml) {
writeAxisXML( xfs[jsi-getInputJoystick()], control,
jsi-getInputAxis() );
} else {
@@ -424,6 +429,7 @@
} else {
cout Press the button you wish to use for
button_humannames[control] endl;
}
+ cout Moving a joystick axis skips this button\n;
fflush( stdout );
jsi-getInput();
if(jsi-getInputButton() != -1) {
Index: src/Input/jsinput.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/jsinput.cxx,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 jsinput.cxx
--- src/Input/jsinput.cxx 10 Sep 2002 01:14:08 - 1.1.1.1
+++ src/Input/jsinput.cxx 18 Jul 2005 10:19:41 -
@@ -29,7 +29,7 @@
jsInput::~jsInput(void) {}
-int jsInput::getInput(void){
+int jsInput::getInput(){
bool gotit=false;
@@ -37,6 +37,7 @@
int i, current_button = 0, button_bits = 0;
joystick=axis=button=-1;
+ axis_positive=false;
if(pretty_display) {
printf ( +--\n ) ;
@@ -79,6 +80,7 @@
gotit=true;
joystick=jss-getCurrentJoystickId();
axis=i;
+ axis_positive=(delta0);
} else if( current_button != 0 ) {
gotit=true;
joystick=jss-getCurrentJoystickId();
@@ -102,7 +104,7 @@
ulMilliSecondSleep(1);
}
if(button_bits != 0) {
-for(int i=1;i=31;i++) {
+for(int i=0;i=31;i++) {
if( ( button_bits (1 i) ) 0 ) {
button=i;
break;
Index: src/Input/jsinput.h
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/jsinput.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 jsinput.h
--- src/Input/jsinput.h 10 Sep 2002 01:14:08 - 1.1.1.1
+++ src/Input/jsinput.h 18 Jul 2005 10:19:41 -
@@ -34,6 +34,7 @@
int button_iv[MAX_JOYSTICKS];
int joystick,axis,button;
+bool axis_positive;
float axis_threshold;
@@ -48,6 +49,7 @@
inline int getInputJoystick(void) { return joystick; }
inline int getInputAxis(void) {
Re: [Flightgear-devel] Re: Custom scenery integration
Hello, Why not just store the Elevation data in a mixed record type of a Polygon with a BLOB field ? Well, this approach certainly enables us to store and retrieve elevation data, but to my knowledge neither of both methods is suited to alter the data using the preferred tools like GRASS for example. We probably would need to build our own storage method for GRASS !? I don't see why we need to store elevation data for the whole world in the database anyway. I wouldn't think elevation data would be a typical subject for user-submitted modifications related to wide areas. If more detailed structures are desired than provided by the DEM data, corrective contour data for small areas could be stored in the database and be combined with the official DEM data, which could be stored outside the database. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Hello, Norman Vine schrieb: Martin Spott writes: Great, this is almost exactly what Frederic and I discussed while talking about his intended reorganization of FGSD :-) Hm, as long as you did not yet patent it, there is not a problem, is it? ;-) The beauty of storing things in a DB is that you can easily have a history of the changes, maintain metadata, and have an easier way to serve the data thru OGC Standard Interfaces. Also once you start making any changes you have to go thru the DB Interface anyway unless you just modify the originals. My point was that we don't have to store the DEM data in raster format. As long as there is no PostGIS support for raster data, we either need to store the raster data outside of PostGIS or store it as vector data such as contours. The whole SRTM-DEM-set stored as contours however possibly would take lots of space in the DB and throttle access to the data when generating the scenery (correct me, if I'm wrong) The original DEM-set is unlikely to change in detail, except for when a new topography mission is started (AFAIK, the German Aerospace Center is currently preparing for a mission for 1arcsec DEM data, however no free download intended) and the data is disseminated. It is questionable whether we'd want to record the changes in that. The actual user-supplied modifications would be stored in vector format in the database and would be subject to the change monitoring you stated. Probably most of the surface of the earth would not have to be touched at all ;-) Also who knows Native PostGIS support for Raster Data may not be all that far in the future :-) Well, then it depends on who is ready first: us or them ;-) In any case, any DB-support for raster data would need integration with GIS-tools in some way. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Hello, Jon Stockill schrieb: I converted a chunk of SRTM data to 10m interval contours, and overlaid this on an ordnance survey map (using mapserver) - the results are actually incredibly close - the 0 point of the two datasets is obviously slightly different, but the two datasets fit together remarkably well - Obviously I have no idea how good the data is for the rest of the world, but the UK data seems surprisingly accurate, which leads me to my question - is there really such a huge problem with our source data, or do we just need to be generating scenery with more polygons? I haven't yet tried it, but did anyone have a look at, e.g., Niagara Falls, in the standard DEM set? Given that 3arcsec data means a distance of about 60-70m between raster point centers I don't think such landmarks should look good in the scenery. In general I'm thinking about specific landmarks, which are important enough to be included for VFR flying but small enough to fall through the grid of SRTM. After all this detail might not be important enough for having to discuss it in length before going to the real work for the rest of the (virtual) world ;-) Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Custom scenery integration (was: Re: [Flightgear-devel] Re: [Terragear-devel])
Hello, Martin Spott schrieb: [SNIP] Actually, I _do_ agree that having preprocessed scenery _is_ an advantage. But it does have disadvantages as well: 1.) At the current state it appears (to me) nearly impossible to inject user-contributed additions into the scenery, 2.) I don't manage to build the necessary tools on my server ;-)) Share your problems with us, perhaps we can help ;-) Maybe the way to go might be to make it easier for everyone to build the tools (and to simplify the process of scenery generation) and to add his personal scenery improvements using common open GIS file formats but keep the preprocessed scenery as we are already used to it. I'm currently working on some more detailed scenery data for the region around Lake of Constance, Southern Germany, and I still have to check on some legal issues, but I'd love to share my experience on that with you as soon as I get some more time (been quite busy in the last few months). I'm using GRASS (http://grass.itc.it) for digitising and the preliminary results are quite interesting regarding better orientation - at least for a local ;-) I had to write an additional tool to get linedata imported from GRASS to TerraGear, but actually with all the support libraries available this is far from complex :-) Most of the exporting and scenery generation tasks is automated using scripts and a single configuration file. When the legal issues are resolved, I might be able to share the digitised data with the community and perhaps we could start a discussion on how the integration of such data into the standard scenery data can be organised and automated - for Curt's convenience ;-) Oh, and not to forget: FlightGear is an astonishing piece of software! In the meantime it has totally replaced my commercial flight simulation software (don't make me say names ;-), making it possible for me to actually drop Windoze :-) Thank you to all who contributed! Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: writing rules with --prop for nasal in fgfsrc
Hi, Gerard Robin wrote: open(/home/tux-le-boss/.fgfs/preferences.xml , O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) ^^ Did you see those blanks at the end of the filename? Are these actually in the original report? Where could these come from? Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: writing rules with --prop for nasal in fgfsrc
Gerard Robin schrieb: I can give to Ralf the prize, if everybody agree. Thanks, too much honor ;-) Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Just to be certain, these problems are now solved, aren't they? Yes, they are. At least for me, can't speak for others...;-) Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Erik Hofman schrieb: [SNIP] I had that on the back of my mind for some time now and decided to implement it today. Lines that are not needed for FlightGear are not tokenized anymore which should provide at least some speedup again. I've also changed the if tests from strings comparison to int comparisons to speed it up just slightly more. Unfortunately that seems to break skipping the blank lines which are in the standard apt.dat-files. I get an Unknown line in file:-message when the reader encounters the first blank line after the version line. Obviously in.getline() includes the carriage return (checked that with --log-level=bulk), which was previously swallowed by simgear::strutils::split(). That way !token.size() could detect the empty line. Also it seems that an empty line which consists of spaces will not be detected by the new code, but as people should not edit the apt.dat-file manually anyway, that might not be as important. One could add a note to the error message Unknown line in file: though. Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Erik Hofman schrieb: Ralf Gerlich wrote: Unfortunately that seems to break skipping the blank lines which are in the standard apt.dat-files. I get an Unknown line in file:-message when the reader encounters the first blank line after the version line. Odd, I don't see that, are you using Windows or MacOS? None of them...Linux...obviously Robin's apt.dat (DAFIF cycle 200505) contain '\r\n' at the end of the line (DOS-convention) and the istream::getline(char*,streamsize) implementation of the Linux libstdc++ for g++-3.4 reads all characters until the '\n' - at least according to the istream header file. Possibly the implementations on the other platforms using different conventions handle this differently, masking the error on some platforms. I've attached a patch for a simple fix, also fixing the problem with the space-only lines. Ralf apt_loader-patch.bin Description: Binary data ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Erik Hofman schrieb: These issues should be fixed now. That was the second alternative I wanted to propose ;-) Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
