Re: [Flightgear-devel] Serious simmer
Robin van Steenbergen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sent: 21 September 2007 04:03 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Serious simmer Ampere K. Hardraade schreef: I have seen far more serious simmers. :P Ampere That basically translates as: We really want some pictures of that! All of that guy's sim is MSFS-based with third party add-on instruments, and all of the monitors on his desk are run from a single PC. If FG is going to be used in home cockpits (Which I REALLY am in favor of) we need some way to get the instruments currently in FG out in an external application, which can run a 2D panel on a separate monitor. FG of course already has the possibility of exporting data over the network and linking copies for visuals (--external-fdm) but I'm not sure to what extent all of the instruments will follow in the slaved FG copy. The most important instrument you will have to run offboard except the basic six are engine gauges, radio and possibly map navigation. Making a decent (preferably OpenGL, vector-based) framework for FG panels would be a good development step, and it need not neccesarily be in the FG branch. As long as it follows the FG spec for the current instruments it will work, and we might be able to add XML-based vector artwork for glass cockpits later (SVG instrument rendering, anyone?). We could borrow some ideas from ARINC661 here. The project would be similar to X-Panel, already developed for X-Plane, so PanelGear might be a suitable name? Obviously someone who keeps right up-to-date with FG, and reads our website :-). Try this: http://www.flightgear.org/Projects/ John Wojnaroski is particularly active in this field Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery file formats: SRTM elevation data source
Hi David,
TerraGear is really an issue for itself and I up to now have only been
successful building it on Unix systems. AFAIK it is completely missing a
build environment for MS Visual Studio.
David Pérez-Piñar López wrote:
I've been able to successfully build FlightGear without much pain - just
a couple of tweaks, as I'm working on a Windows XP / Visual Studio 2005
Express environment, and everything runs fine.
Great!
However, I've tried also the TerraGear package, a completely different
story. My interest is not just to compile it, but to update my
FlightGear scenery with more accurate data.
I don't think anybody expected you to try compiling TerraGear just for
the fun of it - let alone on a currently unsupported platform. ;-)
I've got elevation data from SRTM Data
(http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp), which gives
you data for a relatively large area into one unique file. It's a very
convenient source, as they have already done the hard work for filling
voids with interpolated elevations. As this is not the same source
TerraGear is programmed for, I was planning to reprogram the file
interface section in order to adapt it to my source.
For importing GeoTIFF'd data I have created a gdalchop utility which
uses GDAL to import elevation data from any format supported by GDAL,
including GeoTIFF. A patch is available from
http://svn.qmx-systems.com/fgfsbuilder/trunk/products/TerraGear/patches/gdal-03gdalchop.patch
It's not yet perfect as it produces artifacts for reasons I do not
understand currently and it's pretty slow due to me doing things a bit
more complicated than necessary (as I found out just recently). I
currently don't have the time and motivation to continue working on it,
but you might find this a good starting point, as an alternative to
Jon's conversion tips.
One of the problems is that the HGT files include data for all the
borders while the CGIAR files only contain data e.g. from 10 deg east to
19 deg 59 min 57 sec east, i.e. the east and north borders are typically
missing. TerraGear, however, requires the tiled elevation files (the
.arr.gz stuff) to include the border data. So merging adjacent CGIAR
tiles might be necessary before conversion.
After several attempts and many hours trying to compile TerraGear,
I have finally made it for the chop utility. However, as the data file
is different from the one used in the original implementation
of hgtchop, I will need to modify the code. For that reason, I ask you
some specific information I'm not able to infere from the code: What is
the size (lat-long) of elevation files generated by the original code?
The elevation files cover exactly one tile. The height of a tile is
always 1/8 degree of latitude and the width in degrees longitude varies
with latitude so that a tile is always about the same width in miles.
See SimGear/simgear/bucket/newbucket.hxx for a definition of
SG_BUCKET_SPAN (height in degrees latitude) and sg_bucket_span() (width
in degrees longitude).
This size must be maintained and the distance of points can be chosen to
be a constant and integral number of arcseconds which is written in the
header of the .arr.gz-file. The code for parsing and writing these files
is in TerraGear/src/Lib/Array/array.{hxx,cxx}
There is no proper documentation that I know of, but the parser and
writer code for the .btg.gz-files can be found in
SimGear/simgear/io/sg_binobj.{hxx,cxx}. However, I suspect that if
you're going for the .btg.gz files directly just because of CGIAR-files,
you might be going a bit over the top.
Cheers,
Ralf
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
On Friday 21 September 2007 18:15:56 Robin van Steenbergen wrote: For example as comparison, FS2004, as well as the FG instrument system, use stacked bitmap images which have arrangements defined in an XML file. Actually, the FG instrument system doesn't necessarily use stacked bitmap images at all. At the moment we have a superbly flexible scheme that allows us to construct fully 3d gauges in as much detail as we want; we can use hand-drawn textures or photo-based ones as we need, and can handle all sorts of odd shapes and motions without having to resort to dodgy graphics tricks (which we can also do, if we desire.) Of course, some models (particularly older ones) do use flat stacked bitmap instruments, and it's that flexibility to choose what best suits a particular application which is a very large part of what makes FG great. Why not make an application that does that externally? In the long run, if OpenGL is used as a rendering API, it could also be used to render vector-based images as well. OK - why make an application that does it externally? Sounds like extra complexity which achieves almost nothing that can't be already done. Yes, SVG instruments sound great for some applications; lots of us use SVG to draw the faces for some of our instruments, before exporting to bitmaps at a suitable resolution. But not for all of them by any stretch of the imagination; I see no gain at all for fully 3d instruments using photo-based textures, for example. The only minuscule gain I can see with SVG is that of being able to scale some instruments to ridiculous, larger than life sizes without any jaggies. I can't think of any valid reason to want to, but can already do that anyway, by choosing suitable resolution for the main face texture of a 3d instrument (pretty much all of mine should easily scale to greater than real life size without looking any worse) I'm targeting a generic audience, from a Cessna flyer to a 744 or 787 pilot. Keep the actual graphics out of the program code, but the rendering in there. That doesn't make much sense to me, perhaps I've missed your point altogether :) Also, unless I'm mistaken, you're suddenly limiting us to flat instruments? Lots of (particularly vintage) instrumentation is very far from flat, and we can already handle that very well. For speed, you could reduce this to a VM-based architecture, with the instruction set corresponding to OpenGL rendering commands and the data in memory being the A/C data pulled out of a simulator like FG, FS2004 or PS1, hence almost a full ARINC661 implementation. I'm sure you know that you can already pull any data out of the property tree that you might need, so no changes required there. On the hardware front, each DU could be driven by their own TFT display (portrait) and a Mini-ITX form factor board on the back. MiniITX boards have LVDS connections on board, and are powerful enough to run 2D graphics. If a DU fails, the network code could be programmed to detect that and let another DU take over. Some of the intelligence could be transferred from FG to the external applications and interface logic, while still keeping FG up to date on any changes, through the property system. This sounds like something that is already possible (and already done) with FG. Your original issue was, I think, a desire to have different parts of the FG 3d environment (including instruments) displayed on different screens, on a PC with multiple graphics cards and monitors. As far as I can see, it's already possible, with no extra coding, even for fully 3d cockpits. You can already set your viewpoint(s) anywhere relative to the a/c, facing any direction at any zoom level. You can have multiple views of any part of the same aircraft. Of course it should be even simpler now that we're using OSG... there was some mention in a thread in June (Impressions from LinuxTag) of using four osgViewer cameras configured in preferences.xml to output displays from one instance of FG. Mind you, I haven't seen the promised instructions materialise... it would be nice to see those - did they get onto the wiki when I wasn't looking? The one instrumentation-related thing that we definitely lack at the moment is a really flexible method of implementing glass cockpit displays within FG. Fortunately, it's not something that affects the type of aircraft I'm most interested in ;-) Cheers, AJ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
AJ MacLeod schreef: Your original issue was, I think, a desire to have different parts of the FG 3d environment (including instruments) displayed on different screens, on a PC with multiple graphics cards and monitors. As far as I can see, it's already possible, with no extra coding, even for fully 3d cockpits. You can already set your viewpoint(s) anywhere relative to the a/c, facing any direction at any zoom level. You can have multiple views of any part of the same aircraft. Of course it should be even simpler now that we're using OSG... there was some mention in a thread in June (Impressions from LinuxTag) of using four osgViewer cameras configured in preferences.xml to output displays from one instance of FG. Mind you, I haven't seen the promised instructions materialise... it would be nice to see those - did they get onto the wiki when I wasn't looking? The one instrumentation-related thing that we definitely lack at the moment is a really flexible method of implementing glass cockpit displays within FG. Fortunately, it's not something that affects the type of aircraft I'm most interested in ;-) Cheers, AJ No, my original issue was to make external instrumentation possible over the network, not on a single PC with 6 monitors on it. Distribute the computing power, allowing more processing power for the flight dynamics and visuals and a flexible instrument setup. Take a real simulator as an example: The flight dynamics are run from a system that does only that -- flight dynamics. Pure math that is, and it's mostly done as a double redundant unit instead of a single one. The only data the FDM machine will output is that relevant to flight dynamics. That's basically all of the position data and 2 levels of derivatives of it (thus including forces on the airframe). Other systems, mostly composed of real-world avionics, pick up on that data and generate the relevant instrumentation, either as an image or as a control signal for a real aircraft instrument. Mind you, most flight deck builders, including the FS200x users, do not use a single machine for all the work. More and more of FS is ripped out of the FS logic, leaving only the raw FDM and visual data up to that system. All of the system logic is done outboard communicating with FS over a network link. The only downside of this, is that FS panels themselves are defined in gauges (DLL files) which can never be used outboard because of Microsoft's closed API. There are some really good payware aircraft on the market with tremendous levels of realism, but they are all limited to that one system running FS, so they are not suitable for cockpit builders. Mind you, most of my ideas ARE targeted at glass cockpits, which are mostly composed of vector based graphics. (Historically, aircraft even had vector-driven CRT's before the flat panel era.) If glass cockpits are built up of bitmap-based graphic material, it will look ugly and unrealistic. The Citation in FG, for example, has a very clear and visible display for the PFD/ND, but you can immediately see that it doesn't look like glass. Most cockpit builders will want 2D displays since most of it is hidden behind paneling. Only a few display elements are revealed, and these should look like they belong there. You don't want to be looking 'through' the display glass at some piece of 3D cockpit, you will want to be looking AT the display glass because it is part of the cockpit hardware. Everything will have to look flat. My ultimate goal is to model a flight deck after the professional sims -- each part of the simulator is dedicated to a system. This adds both redundancy and flexibility -- if a system crashes, it doesn't take the entire simulator with it as is the case with FS2004 based setups. The data exchange doesn't stop, because it isn't tied to a single 'master' unit -- if one unit should cease to respond (function), the rest of the system is notified and possibly another unit or a hot standby might take over. Likewise, if another aircraft is being simulated, the only thing that needs to change (in principle) is the system logic and flight model, instead of needing a hard simulator reset. My proposal for the project would be to create a working framework for 2D instruments, suitable for cockpit builders. The system would be similar, if not identical in functionality, to X-Panel for X-Plane users (I would like to give you a URL but some fool took down the X-Panel pages, every Google hit turns 404), which allows X-Plane instruments to be displayed on a different system (or multiple). As for glass cockpits go, an example is either OpenGC or Project Magenta, but both of these have the design of their displays hard-coded, what I would really like to see is that GC or steam panels could be designed in a WYSIWYG graphics environment, and interactive script added later. SVG has specifications for that.
