Re: [Flightgear-devel] Re: [Terragear-devel]
Jon Stockill ha scritto: Robicd wrote: I am sad because I see Jon Stockill's repository almost stopped getting new contributes. I guess it's because of some obstacles (not in John's repository itself) which common people don't like to cope with. I do have some more contributions to add - but things have been rathet hectic at work the last week - I should manage to import them today or tomorrow. Well, that's a relief. I'll post you some more in the next week too :-) I really do believe a repository like this one should be encouraged and supported. There are many people out there who like producing 3d stuff and others who like getting those stuff into a simulator scenery. The repository is a way to meet both needs. cheers, Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Christian Mayer wrote: > Norman Vine schrieb: >> Why not just store the Elevation data in a mixed record type of a >> Polygon with a BLOB field ? > > I wouldn't store contour lines as you'll allways loose precision by > converting the data (DEM -> contour lines -> triangle mesh). Oh, I still believe that hand-crafted contour lines give us some of the highest precision we can get. If you force the triangulator to let the contour lines lie precisely in the triangulated surface (without any weighing), then you'll inevitably get the desired result. "Norman Vine" wrote: > I agree you don't have to but there are advantages to doing so, the way you > do this is to store the DEM as a BLOB whose polygon is a PostGIS object. > > Note this allows you to use PostGIS spatial functions > > Any way just a suggestion for a way to bring TerraGear into the world > of the main stream Open Source GIS standards Just for the understanding: Does this mean you are going to define an area via the polygon and store the DEM as a BLOB that fits exactly into this polygon ? I didn't realize that this was already common use does todays OpenSource GIS software really handle DEM's this way ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Norman Vine schrieb: > Martin Spott writes: > >>I'm currently uncertain if we really can store the _whole_ scenery in >>PostGIS. Our elevation data currently comes as raster data but maybe >>it makes sense to convert that into contour lines - which we finally >>can store in such a database as well. Does this make sense, Norman, or >>will this eliminate our ability to alter the data with 'common' tools ? > > > Why not just store the Elevation data in a mixed record type of a > Polygon with a BLOB field ? I wouldn't store contour lines as you'll allways loose precision by converting the data (DEM -> contour lines -> triangle mesh). Beeing able to change the elevation data can be important, especially when you are puting a finer grid over the data. I dunno what is possible with PostGIS but the most intuitive solution would be to store additional elevation data on arbitrary positions. Then the resulting mesh could be calculated by a weighted average (using the 2D distance) of the cutom elevation and the underlaying DEM. CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCyYSZlhWtxOxWNFcRAvW6AKCL/lc6zq4xuDtHKnE5bRMkjh9amQCdG9Vy 9e8Ihp/XgLydtYH5yEvSTbg= =pR6o -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
On Monday, 4 July 2005 15:04, Jon Stockill wrote: > 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? SRTM3 is very coarse. What I had problems with were airports that are on hill tops or steep terrrain. One example being KAVX. One would need a DEM with a <= 5m sample spacing and about 1 meter vertical accuracy around such airports. SRTM's vertical accuracy is only guaranteed to be within 16 meters! It's usually within 10 meters but that is still a large error when dealing on a micro scale. Also what about custom mods like Alcatraz? There is going to be a need to custom tweak scenery with regards to both the DEM and the vector overlays (roads, rivers, railroads, powerlines, etc). Having everything in one DB with a single TG exporter interface is going to make life a lot easier in the long run in my opinion and there are numerous advantages which haven't been discussed yet. Regards Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Custom scenery integration
Ralf Gerlich writes: > > 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. I agree you don't have to but there are advantages to doing so, the way you do this is to store the DEM as a BLOB whose polygon is a PostGIS object. Note this allows you to use PostGIS spatial functions Any way just a suggestion for a way to bring TerraGear into the world of the main stream Open Source GIS standards Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] optimisation of FlightGear code
Hi folks, Hopefully I would like to start a discussion of Flightgear code optimisation. My first thoughts are that fgfs divides logically into a number of sub-systems: a) Flight Dynamics Modelling (FDM) b) Exterior View c) Cockpit input and output ie joystick controls,switches and displays. d) Motion system but for time being I am going to disregard the last!! These sub-systems could be physically separated into "processes" (programs, threads - whatever you like to call them) and inter-linked with IPC eg tcp/ip, Unix sockets,etc. This would enable: 1) a critical block analysis (CBA) to be run on each sub-system to identify the most frequently used code which can then be optimised by any number of techniques. eg compiler optimisation,manual optimisation, re-writing in a more "efficient language" (without wishing to start a flame war, C++ and Object Orientated languages may be ideal for code development but I know of no object orientated hardware so they may not get the best out of the available hardware.) 2) running the different sub-systems on different inter-linked computers and indeed on different hardware (Intel is not famed for its floating point arithmetic so FDM may be better on PowerPC,UltraSPARC etc but there is a great range of graphics hardware which makes Linux/Intel flexible for "view" and "cockpit"). 3) tuning the "frame" rate of individual sub-systems (the FDM itself may benefit from different and variable frame rate for the "lateral" and "rotational" elements of the aerodynamical derivative integrations) These are just my first thoughts without tracking through every line of code as yet so maybe some of this has already been done? I dont want to repeat things that have already been chewed over so any ideas would be welcome. cheers Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Ralf Gerlich wrote: > 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? ;-) Hmmm, maybe I should switch over to a different business :-) > 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 ;-) I agree, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: gui colors
* Melchior FRANZ -- Monday 04 July 2005 09:38: > (2) our gui font doesn't look good in bright color dark background. This is as good as fixed. We can now use plib's pixmap fonts. But now the question arises: why don't we use them everywhere? They are much sharper and do also look good white on dark. The only problem is that plib has only a 12 and a 18 pt Helvetica font. We'd have to make one in between and include in fgfs. But this isn't rocket science. 14 pt would probably be fine. http://members.aon.at/mfranz/fgfs_gui4.jpg [41 kB](12pt font) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Runway Light Control
Hi, I have somes questions regarding RUNWAY lights: 1) Can I turn on the Runway Lights during day Time? 2) Can I change the Runway Lights Brightness? 3) Does the PAPI, VASI and others lights has independent brightness control? Regards, FS - This mail sent through IMP: http://horde.org/imp/ ___ 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
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
[Flightgear-devel] Re: gui colors
* Erik Hofman -- Monday 04 July 2005 14:06: > Melchior FRANZ wrote: > > > http://members.aon.at/mfranz/fgfs_gui3.jpg [65 kB] > > Ahh. Pretty! > > Seriously, why would you want to remove it, all in all it seems like a > good idea to me. OK, then let's not remove it. I'll have to fix it yet, though, because this was a quick-hack. And before all: I'll have to fix that plib bug first, because for bright text on dark background, it seems we need to use pixmap fonts. This would of course be configurable, too -- the current font should remain functional, and the current look still default. Alternatively, tweaking the glAlphaFunc() parameters for plib fonts might make texture fonts acceptable on dark background, but getting this into plib is probably not feasible in a lifetime. Also, I have yet to understand the relation of gui and new_gui, etc. and find out where to put what. Andy probably has a lot to say about this topic. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Ralf Gerlich wrote: 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. 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? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Terragear-devel]
Robicd wrote: I am sad because I see Jon Stockill's repository almost stopped getting new contributes. I guess it's because of some obstacles (not in John's repository itself) which common people don't like to cope with. I do have some more contributions to add - but things have been rathet hectic at work the last week - I should manage to import them today or tomorrow. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
"Norman Vine" wrote: > Also who knows Native PostGIS support for Raster Data may not be all > that far in the future :-) I typically expect that _you_ know much more of what happens on this terrain than I do :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gui colors
Melchior FRANZ wrote: http://members.aon.at/mfranz/fgfs_gui3.jpg [65 kB] Ahh. Pretty! Seriously, why would you want to remove it, all in all it seems like a good idea to me. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Custom scenery integration
Martin Spott writes: > > Ralf Gerlich wrote: > > > 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. > > Great, this is almost exactly what Frederic and I discussed while > talking about his intended reorganization of FGSD :-) 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. Then again since FGFS is just a 'game' Also who knows Native PostGIS support for Raster Data may not be all that far in the future :-) Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Ralf Gerlich wrote: > 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. Great, this is almost exactly what Frederic and I discussed while talking about his intended reorganization of FGSD :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: gui colors
* Harald JOHNSEN -- Monday 04 July 2005 10:47: > Melchior FRANZ wrote: > >The plan is to read the dialog background/foreground color from > >preferences.xml (or gui/color.xml) and make it changeable at runtime, > So there will be one customizable color theme and 2 or 3 preset themes > like on some TV (old school, mars theme, acid theme, etc) ? Not really themes, but simply settable properties. With all the different possibilities to set properties (config files, Nasal, property picker, ...). Of course, one could prepare different config files with color definitions and load these. But ... > >Before this would be possible, other problems would have to be solved, > >though: It turned out that (1) too many dialogs don't use FGDialog at > >all (e.g. property picker), and (2) our gui font doesn't look good in > >bright color dark background. > Perhaps the font should be selectable too, but this will surely add a > few problems in the layout of some dialogs. Yes. The layout isn't the main problem, it's clever enough (just needed a few tweaks). The problem is that all the texture fonts look bad on darker background. The only alternative would be to use the built-in plib fonts (PUFONT_9_BY_15 etc.), but these have problems with clipping. Probably all not worth it. Before I remove it all again, here's a screenshot (the colors are read from $FG_ROOT/gui/colors.xml): http://members.aon.at/mfranz/fgfs_gui3.jpg [65 kB] m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] gui colors
Melchior FRANZ wrote: It would be nice if we could make the dialog colors user settable. I've abstracted the process of reading colors from the property tree out into a function in dialog.cxx: void getColor(const SGPropertyNode * prop, sgVec4 color); This reads a .. structure from a property node and merges it into the color array. (props may be zero.) But should this rather go to fg_props.cxx!? So that colors for different purposes could be read by it, too, such as HUD color, or splash screen progress text color (not that this is an important feature)? Yes make the properties readable for the different rendering code. The plan is to read the dialog background/foreground color from preferences.xml (or gui/color.xml) and make it changeable at runtime, because the light blue dialogs are suboptimal for some cases (flying over reddish mars, night, otherwise dark sceneries). It can be quite unpleasant if you are flying in dark/night scenery, in a dark room, and then a big bright dialog pops up. So there will be one customizable color theme and 2 or 3 preset themes like on some TV (old school, mars theme, acid theme, etc) ? Before this would be possible, other problems would have to be solved, though: It turned out that (1) too many dialogs don't use FGDialog at all (e.g. property picker), and (2) our gui font doesn't look good in bright color dark background. :-/ m. Perhaps the font should be selectable too, but this will surely add a few problems in the layout of some dialogs. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] gui colors
It would be nice if we could make the dialog colors user settable. I've abstracted the process of reading colors from the property tree out into a function in dialog.cxx: void getColor(const SGPropertyNode * prop, sgVec4 color); This reads a .. structure from a property node and merges it into the color array. (props may be zero.) But should this rather go to fg_props.cxx!? So that colors for different purposes could be read by it, too, such as HUD color, or splash screen progress text color (not that this is an important feature)? The plan is to read the dialog background/foreground color from preferences.xml (or gui/color.xml) and make it changeable at runtime, because the light blue dialogs are suboptimal for some cases (flying over reddish mars, night, otherwise dark sceneries). It can be quite unpleasant if you are flying in dark/night scenery, in a dark room, and then a big bright dialog pops up. Before this would be possible, other problems would have to be solved, though: It turned out that (1) too many dialogs don't use FGDialog at all (e.g. property picker), and (2) our gui font doesn't look good in bright color dark background. :-/ m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
