Re: [Flightgear-devel] No sky with last CVS version
Tim Moore a écrit : Tim Moore wrote: Frederic Bouvier wrote: Hi, in order to build the last CVS version, I got OSG 2.6.0 RC1 and compilation went fine. But I now have a display problem with the sky. It looks like the sky dome is not drawn. No sun, no stars, no moon, no blue sky. Last version I build with OSG 2.4.0 on 7/23 was fine. Here are few snapshots : Whoops, this is clearly my fault; I'll look in to it later this evening. Tim This should be fixed now. Yes, the sky is back. Thanks, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] EGNW apt.dat corrections and additions
Hello, I've just sent the following minor corrections to Robin Peel for inclusion in the next update. EGNW (Wickenby) [810 format, Unix line endings]. http://awaywiththepixies.org.uk/pub/FlightGear/Aerodromes/EGNW/EGNW-20080802.dat Summary of changes: 1. Runways - default position/length/orientation corrected (UK AIP) 2. Windsock - removed four defaults and correctly placed one unlit 3. Tower - add tower viewpoint + prevent auto drawing of tower 4. Light Beacon - add dummy green+white beacon to prevent auto creation 5. Taxiways/Apron - basic structure added 6. Comms - Wickenby Radio A/G frequncy added Reference data used (AIP) is freely available via UK/JAA NATS sources: http://www.nats-uk.ead-it.com/aip/current/ad/EGNW/EG_AD_2_EGNW_en.pdf A few points are worth a mention. The runway surface is listed as being concrete although photographs seem to indicate otherwise. I contacted the operating company concerned who did indeed confirm that the runway surface is now asphalt. Markings are a little odd looking too. Their runway is actually a runway marked within an old runway. Officially declared distances are all within those markings with no under or overrun, despite what looks suspiciously like displaced thresholds for 03 and 34. The old eastern taxiway terminates rather abruptly as what remains of it is now a public road. EFVA is progressing nicely. It this the right place to make such postings? Kind regards. Martin Fenelon. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Crash-dump with /menu/view/rendering options
Hello, With the last CVS, and OSG 2.6-rc1, nvidia driver Linux-x86-173.14.12 I get the following crash-dump if i try to use the /view/rendering options menu. *** glibc detected *** fgfsOSG: malloc(): memory corruption: 0x008e1108 *** === Backtrace: = /lib/libc.so.6[0x7f5253] /lib/libc.so.6(__libc_malloc+0x7b)[0x7f6b7b] fgfsOSG[0x86431df] fgfsOSG[0x864340e] ..SNIP.. fgfsOSG[0x8389282] fgfsOSG[0x8388407] fgfsOSG[0x80ad717] /usr/local/lib/libosgViewer.so.43 (_ZN9osgViewer6Viewer14eventTraversalEv+0x1052)[0x4b0d42] /usr/local/lib/libosgViewer.so.43(_ZN9osgViewer10ViewerBase5frameEd+0x33) [0x4bd473] /usr/local/lib/libosgViewer.so.43(_ZN9osgViewer10ViewerBase3runEv+0xad) [0x4bd5bd] /usr/local/lib/libosgViewer.so.43(_ZN9osgViewer6Viewer3runEv+0x33)[0x4ada93] fgfsOSG[0x80b6b73] fgfsOSG[0x80670be] fgfsOSG(_ZN3osg8PagedLOD8traverseERNS_11NodeVisitorE+0x468)[0x8063580] /lib/libc.so.6(__libc_start_main+0xe0)[0x7a1390] fgfsOSG(_ZN3osg8PagedLOD8traverseERNS_11NodeVisitorE+0x139)[0x8063251] === Memory map: 0011-00111000 r-xp 0011 00:00 0 [vdso] 00111000-0019a000 r-xp 08:15 6776390/usr/lib/libGL.so.173.14.12 0019a000-001b5000 rwxp 00089000 08:15 6776390/usr/lib/libGL.so.173.14.12 001b5000-001b6000 rwxp 001b5000 00:00 0 001b6000-00203000 r-xp 08:15 12210707 /usr/local/lib/libosgParticle.so.2.6.0 00203000-00205000 rw-p 0004d000 08:15 12210707 /usr/local/lib/libosgParticle.so.2.6.0 00205000-0020b000 r-xp 08:15 7791826/usr/local/lib/libOpenThreads.so.2.3.0 0020b000-0020c000 rw-p 5000 08:15 7791826/usr/local/lib/libOpenThreads.so.2.3.0 0020c000-0021 r-xp 08:15 6778463/usr/lib/libXxf86vm.so.1.0.0 0021-00211000 rw-p 3000 08:15 6778463/usr/lib/libXxf86vm.so.1.0.0 00211000-00212000 r-xp 08:15 6776479/usr/lib/tls/libnvidia-tls.so.173.14.12 00212000-00213000 rw-p 08:15 6776479/usr/lib/tls/libnvidia-tls.so.173.14.12 00213000-00214000 r-xp 08:15 6776970/usr/lib/libxcb-xlib.so.0.0.0 00214000-00215000 rw-p 08:15 6776970/usr/lib/libxcb-xlib.so.0.0.0 00215000-0023 r-xp 08:15 6776984/usr/lib/libxcb.so.1.0.0 0023-00231000 rw-p 0001a000 08:15 6776984/usr/lib/libxcb.so.1.0.0 00232000-00286000 r-xp 08:15 6783673/usr/lib/libXt.so.6.0.0 00286000-0028a000 rw-p 00054000 08:15 6783673/usr/lib/libXt.so.6.0.0 0028a000-0028c000 rwxp 00:0f 2062 /dev/zero 0029-0029f000 r-xp 08:15 6782682/usr/lib/libXext.so.6.4.0 0029f000-002a rw-p e000 08:15 6782682/usr/lib/libXext.so.6.4.0 002a-00342000 r-xp 08:15 12210701 /usr/local/lib/libosgSim.so.2.6.0 00342000-00345000 rw-p 000a1000 08:15 12210701 /usr/local/lib/libosgSim.so.2.6.0 00345000-00387000 r-xp 08:15 12210692 /usr/local/lib/libosgGA.so.2.6.0 00387000-0038b000 rw-p 00042000 08:15 12210692 /usr/local/lib/libosgGA.so.2.6.0 0038b000-003bb000 r-xp 08:15 12210704 /usr/local/lib/libosgFX.so.2.6.0 003bb000-003bd000 rw-p 0002f000 08:15 12210704 /usr/local/lib/libosgFX.so.2.6.0 003bd000-003c4000 r-xp 08:15 9886672/usr/local/lib/osgPlugins-2.6.0/osgdb_rgb.so 003c4000-003c5000 rw-p 6000 08:15 9886672/usr/local/lib/osgPlugins-2.6.0/osgdb_rgb.so 003c5000-003f5000 r-xp 08:15 6777376/usr/lib/libglut.so.3.8.0 003f5000-003fa000 rw-p 0002f000 08:15 6777376/usr/lib/libglut.so.3.8.0 003fa000-00401000 r-xp 08:12 2117565/lib/librt-2.7.so 00401000-00402000 r--p 7000 08:12 2117565/lib/librt-2.7.so 00402000-00403000 rw-p 8000 08:12 2117565/lib/librt-2.7.so 00403000-0040c000 r-xp 08:15 9888277/usr/local/lib/osgPlugins-2.6.0/osgdb_txf.so 0040c000-0040d000 rw-p 9000 08:15 9888277/usr/local/lib/osgPlugins-2.6.0/osgdb_txf.so 0040d000-00417000 r-xp 08:12 2118198/lib/libnss_files-2.7.so 00417000-00418000 r--p 9000 08:12 2118198/lib/libnss_files-2.7.so 00418000-00419000 rw-p a000 08:12 2118198/lib/libnss_files-2.7.so 00419000-0041d000 r-xp 08:12 2118196/lib/libnss_dns-2.7.so 0041d000-0041e000 r--p 3000 08:12 2118196/lib/libnss_dns-2.7.so 0041e000-0041f000 rw-p 4000 08:12 2118196/lib/libnss_dns-2.7.so 0041f000-00428000 r-xp 08:15 6783552/usr/lib/libXcursor.so.1.0.2 00428000-00429000 rw-p 8000 08:15 6783552/usr/lib/libXcursor.so.1.0.2 00429000-0042d000 r-xp 08:15 6782893/usr/lib/libXfixes.so.3.1.0 0042d000-0042e000 rw-p 3000 08:15 6782893/usr/lib/libXfixes.so.3.1.0 00432000-00448000 r-xp 08:15 6783686/usr/lib/libXmu.so.6.2.0 00448000-00449000 rw-p 00016000 08:15 6783686/usr/lib/libXmu.so.6.2.0 00449000-004e1000 r-xp 08:15 12210716 /usr/local/lib/libosgViewer.so.2.6.0 004e1000-004e6000 rw-p 00097000 08:15 12210716 /usr/local/lib/libosgViewer.so.2.6.0 004e6000-00532000 r-xp
Re: [Flightgear-devel] Crash-dump with /menu/view/rendering options
Hi Gérard, gerard robin a écrit : Hello, With the last CVS, and OSG 2.6-rc1, nvidia driver Linux-x86-173.14.12 I get the following crash-dump if i try to use the /view/rendering options menu. *** glibc detected *** fgfsOSG: malloc(): memory corruption: 0x008e1108 *** === Backtrace: = It looks like there is no debugging information in your backtrace. Try to enable debug at configuration -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash-dump with /menu/view/rendering options
It looks like there is no debugging information in your backtrace. Try
to enable debug at configuration
I've been getting similar crash, here's the backtrace under gdb:
#0 0xb7026d96 in raise () from /lib/libc.so.6
#1 0xb7028541 in abort () from /lib/libc.so.6
#2 0xb705e42b in __libc_message () from /lib/libc.so.6
#3 0xb7064007 in malloc_printerr () from /lib/libc.so.6
#4 0xb7066241 in _int_malloc () from /lib/libc.so.6
#5 0xb70677ed in malloc () from /lib/libc.so.6
#6 0x085aa743 in resize (hash=0x129e2bf0)
at ../../../../simgear/nasal/hash.c:58
#7 0x085aaaf0 in naHash_newsym (hash=0x129e2bf0, sym=0x1048b634,
val=0xbf9089b8) at ../../../../simgear/nasal/hash.c:179
#8 0x085a52f1 in setupArgs (ctx=0x10499200, f=0x10499230, args=0x10499e0c,
nargs=1) at ../../../../simgear/nasal/code.c:280
#9 0x085a546a in setupFuncall (ctx=0x10499200, nargs=1, mcall=0)
at ../../../../simgear/nasal/code.c:322
#10 0x085a6472 in run (ctx=0x10499200) at ../../../../simgear/nasal/code.c:639
#11 0x085a76aa in naCall (ctx=0x10499200, func=
{num = nan(0x567891055404c), ref = {ptr = {obj = 0x1055404c, str =
0x1055404c, vec = 0x1055404c, hash = 0x1055404c, code = 0x1055404c, func =
0x1055404c, ccode = 0x1055404c, ghost = 0x1055404c}, reftag = 2146789257}},
argc=0,
args=0x0, obj=
{num = nan(0x56789), ref = {ptr = {obj = 0x0, str = 0x0, vec =
0x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, ghost = 0x0}, reftag =
2146789257}}, locals=
{num = nan(0x56789129e2c38), ref = {ptr = {obj = 0x129e2c38, str =
0x129e2c38, vec = 0x129e2c38, hash = 0x129e2c38, code = 0x129e2c38, func =
0x129e2c38, ccode = 0x129e2c38, ghost = 0x129e2c38}, reftag = 2146789257}})
at ../../../../simgear/nasal/code.c:801
#12 0x0846aa2b in FGNasalSys::call (this=0xe7fc538, code=
{num = nan(0x567891055404c), ref = {ptr = {obj = 0x1055404c, str =
0x1055404c, vec = 0x1055404c, hash = 0x1055404c, code = 0x1055404c, func =
0x1055404c, ccode = 0x1055404c, ghost = 0x1055404c}, reftag = 2146789257}},
argc=0,
args=0x0, locals=
{num = nan(0x56789), ref = {ptr = {obj = 0x0, str = 0x0, vec =
0x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, ghost = 0x0}, reftag =
2146789257}}) at ../../../../src/Scripting/NasalSys.cxx:89
#13 0x0846b1f4 in FGNasalSys::createModule (this=0xe7fc538,
moduleName=0x129c6064 __dlg:rendering,
fileName=0x129c6064 __dlg:rendering,
src=0xe6449d8 \n if (!getprop(\/sim/gui/devel-widgets\)) {\n
cmdarg().getNode(\group[2]/group[1]\).removeChild(\checkbox\, 2);\n
}\n, len=135, arg=0xe5a4498) at ../../../../src/Scripting/NasalSys.cxx:812
#14 0x08343f8a in FGDialog (this=0x129dc2c8, props=0xe5a4498)
at ../../../../src/GUI/dialog.cxx:356
#15 0x0833c3b6 in NewGUI::showDialog (this=0xe14fdc8, [EMAIL PROTECTED])
at ../../../../src/GUI/new_gui.cxx:135
#16 0x08073dd5 in do_dialog_show (arg=0xe31c3e0)
at ../../../../src/Main/fg_commands.cxx:1104
#17 0x085cdc33 in SGBinding::fire (this=0xe5856e0)
at ../../../../simgear/structure/SGBinding.cxx:60
#18 0x08346600 in FGMenuBar::fireItem (this=0xe14fe38, item=0xe340ff8)
at ../../../../src/GUI/menubar.cxx:154
#19 0x08345ba2 in menu_callback (object=0xe340ff8)
at ../../../../src/GUI/menubar.cxx:93
#20 0x085e56fe in puOneShot::doHit (this=0xe340ff8, button=0, updown=1, x=101,
y=179) at ../../../../src/pui/puOneShot.cxx:32
#21 0x085e4338 in puObject::checkHit (this=0xe340ff8, button=0, updown=1,
x=101, y=179) at ../../../../src/pui/puObject.cxx:513
#22 0x085e6003 in puPopupMenu::checkHit (this=0xe35c318, button=0, updown=1,
x=101, y=179) at ../../../../src/pui/puPopupMenu.cxx:234
#23 0x085e1ae9 in puGroup::checkHit (this=0xe2cc5b0, button=0, updown=1,
x=144, y=-93) at ../../../../src/pui/puGroup.cxx:218
#24 0x085e1ae9 in puGroup::checkHit (this=0x88e0058, button=0, updown=1,
x=144, y=473) at ../../../../src/pui/puGroup.cxx:218
#25 0x085dee02 in puMouse (button=0, updown=1, x=144, y=127)
at ../../../../src/pui/pu.cxx:385
#26 0x08362e36 in FGInput::doMouseClick (this=0xb42d7008, b=0, updown=1,
x=144, y=127, mainWindow=true, ea=0x1297bdd0)
at ../../../../src/Input/input.cxx:326
#27 0x08361287 in mouseClickHandler (button=0, updown=1, x=144, y=127,
mainWindow=value optimized out, ea=0x1297bdd0)
at ../../../../src/Input/input.cxx:1176
#28 0x080a83b9 in flightgear::FGManipulator::handle (this=0x87174a8,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at ../../../../src/Main/FGManipulator.cxx:218
#29 0xb7778495 in osgViewer::Viewer::eventTraversal (this=0x87b2de8)
at /home/pigeon/src/OSG/OpenSceneGraph/include/osgGA/GUIEventHandler:100
#30 0xb7781c83 in osgViewer::ViewerBase::frame (this=0x87b2de8,
simulationTime=1.7976931348623157e+308)
at /home/pigeon/src/OSG/OpenSceneGraph/src/osgViewer/ViewerBase.cpp:590
#31 0xb7781fd0 in osgViewer::ViewerBase::run (this=0x87b2de8)
at
Re: [Flightgear-devel] Crash-dump with /menu/view/rendering options
* gerard robin -- Sunday 03 August 2008: With the last CVS, and OSG 2.6-rc1, nvidia driver Linux-x86-173.14.12 I get the following crash-dump if i try to use the /view/rendering options menu. Can you update $FG_ROOT/gui/dialogs/rendering.xml and try again? I don't know yet what exactly happened, but some code in there probably caused it. Not that this should have lead to a crash ... m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Cockpit displays (rendering, modelling)
After some playing around, the area of FG that I'd most like to see improved, and therefore inclined to work on, is better glass cockpit displays, and the systems behind them. I'm still reading over the code, and looking at different aircraft to get a handle on this (and, err, how difficult it's going to be) In the mean time, some questions: - in the OSG world, what is the 'right' approach for rendering cockpit displays? The KLN-89b uses a render-area-2d (and I think the weather radar does, but is currently non-functional under OSG?). The obvious candidates are a sub-scene rendered by an orthographic camera, or render texture accessed by 2D drawing. Which is the most likely to work well? In terms of things like supporting rendering displays to alternate video devices (for real cockpits), zooming displays for better visibility, and avoid Z-fighting when drawing many overlaid 2D elements. - As I understand it, the current PFD and NAV displays in the A320 / Citation / 787 / 737 are made using pretty elaborate arrangements of the current XML Panel code. I've also seen talk (I think) of people working on the G1000. What do people think is the right balance between Nasal + XML vs C++ code in this area? I think most features of even a Boeing PFD could be done purely in Nasal + XML panels, even things like the variable Max IAS indication and V-speed / flap- retraction markers. The NAV display certainly needs a C++ core for the showing Navaid DB features and the current flight plan, but the border elements and many other parts could still be built using XML. Equally OpenGC does the whole lot in compiled code, and the PFD might be simpler if a few components (airspeed and altitude tracks, for example) were available as pre-built components. - My plan would be to build some generic classes which can be extended or configured to support Boeing or Airbus displays, or other similar systems (including the G1000). My current perception is that this would be pretty doable - sizes / colours / iconography / positions of elements change, but the fundamental concepts are pretty consistent. Does this seem reasonable? Obviously supporting all the features of each system is an immense amount of work, but I think getting the common features up and running is doable in the medium term. - Any other feedback? I'm interested in docs on the G1000 and Airbus displays / FMS in particular, to see how they differ from what i know about the Boeing ones. I don't know anything about military equivalents, but maybe they are also similar enough to share a C++ core. My initial hack would be to get a NAV display running showing the current route segments and navaids overlays in a specified radius, working as a custom panel instrument. That would be enough to get the FPL/WPT/APT/FIX/NAV/etc buttons in various cockpits working, as well as the NAV display modes (compass, enroute, approach if I recall correctly). Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash-dump with /menu/view/rendering options
On dim 3 août 2008, Melchior FRANZ wrote: * gerard robin -- Sunday 03 August 2008: With the last CVS, and OSG 2.6-rc1, nvidia driver Linux-x86-173.14.12 I get the following crash-dump if i try to use the /view/rendering options menu. Can you update $FG_ROOT/gui/dialogs/rendering.xml and try again? I don't know yet what exactly happened, but some code in there probably caused it. Not that this should have lead to a crash ... m. Done, and right, thanks Melchior -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A patch to prevent multiple loading AIModels on reset
Tatsuhiro Nishioka wrote: Hi forks, I've encountered a weird fps drop in resetting on Nimitz (with --carrier=Nimitz). It happens since AIBase loads AIModels on every reset, which should not. The same problem happened on 0.9.11-pre2 and I made a patch to fix it, but the patch was not applied to CVS/OSG version. I even didn't realize that it also happen on CVS/OSG but it actually does. Anyway, enclosed is a patch to fix this issue. Please check if it works and get it committed. Hmm, I see the problem but am not completely sure not loading the models again after a reset is the right way to fix it. Personally I think that the reset should have removed them from memory in the first place. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
James Turner schreef: snipped - My plan would be to build some generic classes which can be extended or configured to support Boeing or Airbus displays, or other similar systems (including the G1000). My current perception is that this would be pretty doable - sizes / colours / iconography / positions of elements change, but the fundamental concepts are pretty consistent. Does this seem reasonable? Obviously supporting all the features of each system is an immense amount of work, but I think getting the common features up and running is doable in the medium term. - Any other feedback? I'm interested in docs on the G1000 and Airbus displays / FMS in particular, to see how they differ from what i know about the Boeing ones. I don't know anything about military equivalents, but maybe they are also similar enough to share a C++ core. My initial hack would be to get a NAV display running showing the current route segments and navaids overlays in a specified radius, working as a custom panel instrument. That would be enough to get the FPL/WPT/APT/FIX/NAV/etc buttons in various cockpits working, as well as the NAV display modes (compass, enroute, approach if I recall correctly). Regards, James I've been a lurker on this list for quite a while, and some of the FG development crew know me personally. I would be interested in helping out with this, since I am a sim builder and I think the interface for cockpit displays is probably one of the most important things missing in FG at the current time, in terms of the usability for sim building. After all, the flight dynamics and system logic of FG are far better than its Microsoft cousin. Remember, in real-world aircraft, cockpit displays are vector devices. In most sim packages, including FG and FS200x, panels are built by stacking bitmaps on top of each other, according to a specific transformation (fx. the attitude indicator consists of a static mask bitmap and an attitude card which is translated and rotated according to the aircraft's pitch/roll). Although this works very well for 'classic' mechanical gauges, it loses its function when simulating glass displays as it primarily compromises the readability of text. (this isn't a huge issue in mechanical gauges, since they have big numbers and mostly static text number plates. Glass decks, on the other hand, have a lot of transformed text) My suggestion would be to look into the option of making a vector framework, which has all the basic widgets for a glass deck implemented in C++ code. I'm guessing it would be somewhat similar to ARINC661, and the actual arrangement of these widgets could be marked up in an XML file. The framework could render to a texture (for display in a 3D virtual cockpit), a memory buffer (for direct blitting onto the screen) or to a separate device context altogether (for an external display). Network support on this would be a really interesting feature -- allowing outboard 'dumb' cockpit displays to be run off a diskless thin client. I have done some preliminary research on this and some bits of code. I currently have a working example of the Primus 1000 avionics set as seen in the Embraer ERJ-145, but it currently only connects to MSFS. Here's a pic: http://www.stoneynet.nl/openrj/openrj_screenshot.png And here's a ZIP containing the binaries, for the people interested in playing with it (Windows only): http://www.stoneynet.nl/openrj/openrj-0.9.7rc1.zip All the individual displays are plug-in files (Windows DLL files), but for the 2.0 version of the framework I'm trying to stick with UNIX support as much as I can. Most of the code inside the plugin file is just plain OpenGL commands and some math, though, and I reckon this could be easily translated into geometry files (XML or binary for embedded purposes), containing only the display engine in code. Making a moving map (NAV) display is pretty easy, BTW. The simplest, but least accurate way of doing it is to use a rectangular mapping -- mapping latitude and longitude to the X and Y axes directly. Remember that 1 minute of lat/longitude corresponds to 1 nautical mile by definition, and calculating distances is a snap (using the Pythagorean theorem). Define the clipping region of the map using glOrtho in nautical miles around the aircraft (the aircraft is positioned at the origin) and scale the coordinates up 60 times to obtain the easiest mapping. A more accurate mapping can be achieved by drawing the map in 3D, this also solves wrap-around problems, but it is (marginally) slower because of the large number of rotations involved. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
Sounds great, IMHO. I agree that MFD/glass cockpit displays aren't very well supported, and I also find the vector idea interesting. Actually, we've had several discussions on IRC about this possibility. And a Nasal interface for it would also be a good idea -- not for actually drawing the screens, but for setting up the structures. Not that I'm trying to put anything on anyone's TODO list, but you might also want to think about extending that idea for drawing HUDs. I never liked the idea of using textures for that, for the same reason that you mentioned: probably too blurry. ISTR that graphics cards manufacturers are dropping the idea of letting hardware draw the lines, and move that functionality to the drivers. But this should still be fast enough. For HUDs it would be necessary to project the image on an arbitrary object, not necessarily a rectangle. I'm working on dropping the old HUD implementation. But if the new one is soon becoming the new old one, I'll not be sad. :-) m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
On Sun, 03 Aug 2008 14:40:57 +0100 James Turner [EMAIL PROTECTED] wrote: I look forward to a better glass cockpit system. I did the Primus 1000 glass cockpits for the Citation's and 777-200 . I am experimenting with the G1000 with moving map (with pre-rendered Atlas images),but with nasal code. Ive tried different combinations of texturing and 2d panel text , but haven't been happy with any of the results. I've had visions of making a configurable glass cockpit where you could specify 2d coordinates of each item (compass rose , ai , speed tape, etc), and have them drawn in the code to a texture , but I lack the coding skill to do it. So I'm happy that someone is going to tackle this problem :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
SydSandy schreef: On Sun, 03 Aug 2008 14:40:57 +0100 James Turner [EMAIL PROTECTED] wrote: I look forward to a better glass cockpit system. I did the Primus 1000 glass cockpits for the Citation's and 777-200 . I am experimenting with the G1000 with moving map (with pre-rendered Atlas images),but with nasal code. Ive tried different combinations of texturing and 2d panel text , but haven't been happy with any of the results. I've had visions of making a configurable glass cockpit where you could specify 2d coordinates of each item (compass rose , ai , speed tape, etc), and have them drawn in the code to a texture , but I lack the coding skill to do it. So I'm happy that someone is going to tackle this problem :) Cheers The only issue I'm currently facing is how to integrate my current work into the already estabilished FG code. I'm a good OpenGL and C++ coder, but I'm new to the FG code structure. It would be nice if someone were to give me a heads-up on that. Most of my current code is Win32-specific and low level immediate mode OpenGL commands, which i reckon doesn't really work well with OSG. ;) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A patch to prevent multiple loading AIModels on reset
Hi Erik, Great to hear your idea, which makes me want to investigate on this deeper. As you said, removing models at the beginning of reset, and then loading needed models again apparently looks better to me. However, it seems it takes longer for me to investigate on this since I'm not that familiar with model loadings. Thus, I want to ask Till and Tim to find a better means of handle this issue. I'll also sneak around the code to see what is the better way. It might also takes a bit while for the better way. Plus, Durk was kindly committed my patch. (thanks!) So here is my suggestion. First, we use my patch as a temporal fix just to prevent the fps drop. Second, we investigate a reasonable means of loading and unloading AIModels on reset (and remove my patch). Any opinions? Best, Tat p.s. Tim, I've tested what you said on IRC, and I think that running last two lines of FGAIBase::init on reset would be OK so far. My patch is gonna be useless by the time the better way is introduced, but I just want to let you know. On Aug 3, 2008, at 11:24 PM, Erik Hofman wrote: Tatsuhiro Nishioka wrote: Hi forks, I've encountered a weird fps drop in resetting on Nimitz (with --carrier=Nimitz). It happens since AIBase loads AIModels on every reset, which should not. The same problem happened on 0.9.11-pre2 and I made a patch to fix it, but the patch was not applied to CVS/OSG version. I even didn't realize that it also happen on CVS/OSG but it actually does. Anyway, enclosed is a patch to fix this issue. Please check if it works and get it committed. Hmm, I see the problem but am not completely sure not loading the models again after a reset is the right way to fix it. Personally I think that the reset should have removed them from memory in the first place. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
On 3 Aug 2008, at 20:22, R. van Steenbergen wrote: The only issue I'm currently facing is how to integrate my current work into the already estabilished FG code. I'm a good OpenGL and C++ coder, but I'm new to the FG code structure. It would be nice if someone were to give me a heads-up on that. Most of my current code is Win32- specific and low level immediate mode OpenGL commands, which i reckon doesn't really work well with OSG. ;) Yeah, that's an absolute non-starter, same as the OpenGC code - low level OpenGL will not be flexible enough, or efficient in the OSG scene-graph, is my perception. I hope Tim Moore will pitch in with his opinion on the best way to do the OSG integration, separate camera feels like the best choice to me, but I need to think about the details. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
On 3 Aug 2008, at 19:58, SydSandy wrote: I look forward to a better glass cockpit system. I did the Primus 1000 glass cockpits for the Citation's and 777-200 . I am experimenting with the G1000 with moving map (with pre-rendered Atlas images),but with nasal code. Ive tried different combinations of texturing and 2d panel text , but haven't been happy with any of the results. The moving map aspect is tricky for the G1000 - including an Atlas- style renderer as another layer is possible, it'd also let me build the one GUI element I've been wanting for ages, a 'map' dialog box with navaids and airways overlaid, like the map UIs in MSFS / X- Plane / Fly. I'll definitely leave the moving map for the future, I'm afraid. I've had visions of making a configurable glass cockpit where you could specify 2d coordinates of each item (compass rose , ai , speed tape, etc), and have them drawn in the code to a texture , but I lack the coding skill to do it. So I'm happy that someone is going to tackle this problem :) That's basically the approach that feels right to me, but I need to learn / be told more about the current OSG scene to be sure. I'm also unclear how the XML panel elements are handled in the brave new OSG world - are they mapped to custom nodes (which seems like it would work pretty well) or what (I'll go read the code I guess...) The more examples of different appearances that exist for these things, the better - whatever the C++ solution is, it's going to need to be 'styled' with a set of textures and colours for each make of display. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
