Re: [Flightgear-devel] [PATCH] rain cone orientation
On Fri, 3 Feb 2006, Vassilii Khachaturov wrote: Rather, I wanted to make a subsection of preferences.xml dedicated to precipitation rendering, maybe smth like a /sim/rendering/precipitation then just pass an sgprop node pointer from that environment manager over to SGEnviro, and read properties inside SGEnviro from the subtree, whenever I need that? Would that be a fine thing to do? Yep, that's how it's mostly done in SimGear and makes it easy to pass an increasing number of parameters without the need to alter the function call(s). Thanks a lot! Here comes the configurability patch, tested here with today's CVS. http://www.tarunz.org/~vassilii/fg/rain.diff Please review and apply if it's fine. Changes: 1) SimGear: * environment/visual_enviro.cxx now depends on props/props.hxx, which means additional link dependency when using libsgenvironment.a (fortunately the props are already linked in in the fgfs case!) * corrected the glRotatef() order in drawRain even further (a less obvious mistake than before, which is noticed by looking skywards and wiggling the mouse in the view direction change mode) * all the magic numbers used in the rain rendering code have been provided a default (based on the old hardcoded value) in a form of a define, and a meaningfully named static member in SGEnviro * SGEnviro::config() added to init the above according to defaults or config props * minor redundant gl call in DrawCone2 optimized away (twice per frame) * documented the change in the speed parameter meaning (leftover from the last patch) * more dox added along * minor spelling: s/familly/family/g 2) FlightGear/source: adding a call to SGEnviro::config to the FGEnvironmentMgr 3) FlightGear/data: an addition to preferences.xml, listing the current defaults (i.e., it'll work the same without this one applied, but is there for the docu. sake) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/FDM UFO.cxx,1.11,1.12
Modified Files: UFO.cxx Log Message: work better with interpolated brakes [snip] double th = globals-get_controls()-get_throttle( 0 ); ! if ( globals-get_controls()-get_brake_left() 0.0 ! || globals-get_controls()-get_brake_right() 0.0 ) [snip] Wow. It never occurred to me to try differential braking in the UFO... --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Errors in 'mk_viii.cxx' ?
Hello, when compiling the current CVS tree on IRIX/MIPSpro I get several Errors in 'mk_viii.cxx': CC -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/opt/include -I/usr/freeware/include -Xcpluscomm -I/opt/FlightGear/include -I/usr/local/include -O2 -use_readonly_const -rdata_shared -woff 1001,1012,1014,1110,1116,1155,1172,1174,1234,1401 -woff 1460,1551,1552,1681 -OPT:roundoff=0:Olimit=0:div_split=ON:alias=typed:fast_io=ON -OPT:got_call_conversion=ON:reorg_common=ON:rsqrt=ON:swp=ON -LANG:exceptions=ON -I/opt/include -I/usr/freeware/include -Wl,-rpath -Wl,/usr/freeware/lib32 -Wl,-rpath -Wl,. -I/opt/FlightGear -c99 -I/opt/FlightGear/include/simgear/compatibility -D_REENTRANT -c -o mk_viii.o `test -f 'mk_viii.cxx' || echo './'`mk_viii.cxx cc-1238 CC: ERROR File = mk_viii.cxx, Line = 1841 The function MK_VIII::IOHandler::set_discrete_input is inaccessible. mk-properties_handler.tie(node, (string(inputs/discretes/) + name).c_str(), RawValueMethodsDataMK_VIII::IOHandler, bool, bool *(*this, input, MK_VIII::IOHandler::get_discrete_input, MK_VIII::IOHandler::set_discrete_input)); ^ [...] cc-1238 CC: ERROR File = mk_viii.cxx, Line = 1843 The member MK_VIII::properties_handler is inaccessible. mk-properties_handler.tie(node, (string(input-feeders/discretes/) + name).c_str(), SGRawValuePointerbool(feed)); ^ [...] cc-1238 CC: ERROR File = mk_viii.hxx, Line = 889 The function MK_VIII::VoicePlayer::Speaker::get_property(float *) const is inaccessible. MK_VIII::VoicePlayer::Speaker::get_property, ^ detected during instantiation of void MK_VIII::VoicePlayer::Speaker::tie(SGPropertyNode *, const char *, float *) at line 2136 of mk_viii.cxx [...] cc-1238 CC: ERROR File = mk_viii.hxx, Line = 890 The function MK_VIII::VoicePlayer::Speaker::set_property(float *, float) is inaccessible. MK_VIII::VoicePlayer::Speaker::set_property)); ^ detected during instantiation of void MK_VIII::VoicePlayer::Speaker::tie(SGPropertyNode *, const char *, float *) at line 2136 of mk_viii.cxx 18 errors detected in the compilation of mk_viii.cxx. Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MK VIII EGPWS emulation
Jean-Yves Lefort wrote : Feel free to commit; thanks for your work. Ok, the instrument itself is commited. Now I would like to have a formal acceptance from Syd Adams ( copied in the dest list of this mail ) before commiting the changes to the b1900d. Syd ? -Fred PS: I am out of town next week. -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Mailing archive has ceased working
It would seem our mailing archive has ceased working since February 27th. Ampere --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flaps and landing gear extend and retract with no power? OK to add voltage checks?
I would like to add a voltage check before moving the flaps or landing
gear in data/Nasal/controls.nas. The proposed changes are underlined.
flapsDown = func {
if(arg[0] == 0) { return; }
_if(getprop(/systems/electrical/outputs/flaps) 8.0) {return; }
# Dave Perry added a check for voltage to the flaps 3/4/06
_if(props.globals.getNode(/sim/flaps) != nil) {
stepProps(/controls/flight/flaps, /sim/flaps, arg[0]);
return;
}
# Hard-coded flaps movement in 3 equal steps:
val = 0.334 * arg[0] + getprop(/controls/flight/flaps);
if(val 1) { val = 1 } elsif(val 0) { val = 0 }
setprop(/controls/flight/flaps, val);
}
I think even the default generic electrical system supplies voltage to
the flaps. The landing gear may be more problematic as the gear could
be hydrolic (and most of the electrical systems in fgfs don't supply
power to the landing gear). Here is that proposed change.
gearDown = func {
_if(getprop(/systems/electrical/outputs/landing-gear) 8.0)
{return; }
# Dave Perry added a check for voltage to the flaps 3/4/06
_if (arg[0] 0) {
setprop(/controls/gear/gear-down, 0);
} elsif (arg[0] 0) {
setprop(/controls/gear/gear-down, 1);
}
}
Since the pa24-250 configs and nasal switches check for voltage for all
the other electrical devices, It bothered me that I could lower the
flaps and retract the gear with the master switch off.
If we model the electrical systems but the electrical devices continue
to work with no power, then modeling failures becomes difficult.
Comments?
Dave Perry
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flaps and landing gear extend and retract with no power? OK to add voltage checks?
Dave Perry wrote:
I would like to add a voltage check before moving the flaps or landing
gear in data/Nasal/controls.nas. The proposed changes are underlined.
flapsDown = func {
if(arg[0] == 0) { return; }
_if(getprop(/systems/electrical/outputs/flaps) 8.0) {return; }
# Dave Perry added a check for voltage to the flaps 3/4/06
_if(props.globals.getNode(/sim/flaps) != nil) {
stepProps(/controls/flight/flaps, /sim/flaps, arg[0]);
return;
}
# Hard-coded flaps movement in 3 equal steps:
val = 0.334 * arg[0] + getprop(/controls/flight/flaps);
if(val 1) { val = 1 } elsif(val 0) { val = 0 }
setprop(/controls/flight/flaps, val);
}
I think even the default generic electrical system supplies voltage to
the flaps. The landing gear may be more problematic as the gear could
be hydrolic (and most of the electrical systems in fgfs don't supply
power to the landing gear). Here is that proposed change.
gearDown = func {
_if(getprop(/systems/electrical/outputs/landing-gear) 8.0)
{return; }
# Dave Perry added a check for voltage to the flaps 3/4/06
_if (arg[0] 0) {
setprop(/controls/gear/gear-down, 0);
} elsif (arg[0] 0) {
setprop(/controls/gear/gear-down, 1);
}
}
Since the pa24-250 configs and nasal switches check for voltage for
all the other electrical devices, It bothered me that I could lower
the flaps and retract the gear with the master switch off.
If we model the electrical systems but the electrical devices continue
to work with no power, then modeling failures becomes difficult.
I'm just wondering about manual flap systems (or non-electrically
powered flap systems)? In a separate project I implimented electric
gear retraction and electric flaps, and made them so they only worked
when the electrical system was on, but in that case I bypassed the
standard gear/flap controls. This worked since the aircraft can only be
operated with a full set of hardware controls (we aren't trying to
support every joystick or other input method under the sun.)
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flaps and landing gear extend and retract with no power? OK to add voltage checks?
Dave Perry wrote: I would like to add a voltage check before moving the flaps or landing gear in data/Nasal/controls.nas. The proposed changes are underlined. Adding aircraft-specific code to the generic control mappings is a bad idea; that file is for Nasal code that is globally useful for interpreting the user's control inputs. It doesn't do system simulation. Why not do it in the aircraft configuration by driving the flaps from some other property than /controls/flight/flaps and gating that on the appropriate system-specific failure modes with some system-specific Nasal? Andy --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: Flaps and landing gear extend and retract with no power? OK to add voltage checks?
* Dave Perry -- Sunday 05 March 2006 01:41:
I would like to add a voltage check before moving the flaps or landing
gear in data/Nasal/controls.nas.
_if(getprop(/systems/electrical/outputs/flaps) 8.0) {return; }
[...]
_if(getprop(/systems/electrical/outputs/landing-gear) 8.0)
8.0 what? Ampere? I don't think such a fixed value is a good idea here.
This should IMHO be an enabled flag. The aircraft knows more about the
exact conditions and could then enable/disable this flag whenever it
thinks it should (below 8.0 thingies or 0.6 or whatever).
m.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] performance and appearance issues with point sprites
A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight:
point-spriteenhanced-lighting fps runway/taxiway lights
===
false false 18 steady pixels [1]
false true2 steady thick points [1]
truefalse 11 dim and blinking pixels [2]
truetrue11 steady thin points [3]
[1] Identical to CVS 20060126.
[2] Nice for christmas, but otherwise completely broken. This is what
I get without the patch.
[3] Best attempt at looking like a real airport, I'd use this on a
more powerful system.
Enabling line-smooth removes about 7 fps from these figures.
See the attached patch (I think point-sprite and line-smooth should be
disabled by default).
--
Jean-Yves Lefort
[EMAIL PROTECTED]
http://lefort.be.eu.org/
Index: src/Main/renderer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v
retrieving revision 1.44
diff -u -r1.44 renderer.cxx
--- src/Main/renderer.cxx 21 Feb 2006 01:19:19 - 1.44
+++ src/Main/renderer.cxx 5 Mar 2006 05:29:14 -
@@ -222,8 +222,9 @@
glFrontFace ( GL_CCW );
// Just testing ...
-if ( SGIsOpenGLExtensionSupported(GL_ARB_point_sprite) ||
- SGIsOpenGLExtensionSupported(GL_NV_point_sprite) )
+if ( (SGIsOpenGLExtensionSupported(GL_ARB_point_sprite) ||
+ SGIsOpenGLExtensionSupported(GL_NV_point_sprite))
+fgGetBool(/sim/rendering/point-sprite))
{
GLuint handle = thesky-get_sun_texture_id();
glBindTexture ( GL_TEXTURE_2D, handle ) ;
@@ -232,7 +233,8 @@
// glEnable(GL_POINT_SMOOTH);
glPointSpriteIsSupported = true;
}
-glEnable(GL_LINE_SMOOTH);
+if ( fgGetBool(/sim/rendering/line-smooth) )
+glEnable(GL_LINE_SMOOTH);
// glEnable(GL_POLYGON_SMOOTH);
glHint(GL_POLYGON_SMOOTH_HINT, GL_DONT_CARE);
glHint(GL_LINE_SMOOTH_HINT, GL_DONT_CARE);
pgprMEdUHNju5.pgp
Description: PGP signature
Re: [Flightgear-devel] FlightGear on LinuxTag; Was: FlightGear Make Process: Amazing
On Friday 03 March 2006 22:53, David Megginson wrote: On 03/03/06, Matthias Boerner [EMAIL PROTECTED] wrote: Next one: I know how it feels to fly a real aircraft but I've never used a yoke or pedals with FlightGear. Sometimes I've use other people's equipment with M$FS but I wasn't satisfied. The pedals I found there had a spring that centers the pedal position much too hard - but in a real aircraft (Cessna, Piper) you don't need strong initial forces to move the pedals out of the center position. Now: Does anyone have a recommendation for pedals and a yoke that he knows resemble the controls of a real aircraft ? if we aren't able to get any hardware for flying we can use my pedals and my joystick (Simped-F16/USB and ThrustMaster Hotas Cougar/USB). I had the CH USB yoke and pedals, but ended up donating both to our local charity store about a year ago. They took up a lot of room, were a pain to set up, and didn't make the aircraft any easier to control. All the best, David If you want decent rudder pedals then you may want to look at the Flight Link Jet Rudder Control Module from http://www.aviationsimulation.co.uk/acatalog/_Pedals.html It costs over €2000 but they're made to Boeing specs and evidently work really well. They can also be mechanically linked which is useful for cockpit builders. Paul --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Error making cvs FG
Hi Guys i can no longer build FG . This is the error im getting. Making install in Main make[2]: Entering directory `/root/files/flightgear/flightgear-cvs/source/src/Main' if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I../../src/FDM/JSBSim -I/usr/X11R6/include -I/usr/local/include -DPKGLIBDIR=\/opt/flightgear/share/FlightGear\ -g -O2 -D_REENTRANT -MT fg_commands.o -MD -MP -MF .deps/fg_commands.Tpo -c -o fg_commands.o fg_commands.cxx; \ then mv -f .deps/fg_commands.Tpo .deps/fg_commands.Po; else rm -f .deps/fg_commands.Tpo; exit 1; fi fg_commands.cxx:1307: error: expected unqualified-id before '' token fg_commands.cxx:1351: error: expected unqualified-id before '==' token fg_commands.cxx: In function 'bool do_release_cockpit_button(const SGPropertyNode*)': fg_commands.cxx:1375: error: redefinition of 'bool do_release_cockpit_button(const SGPropertyNode*)' fg_commands.cxx:1331: error: 'bool do_release_cockpit_button(const SGPropertyNode*)' previously defined here fg_commands.cxx: At global scope: fg_commands.cxx:1395: error: expected unqualified-id before '' token fg_commands.cxx:1411: error: expected constructor, destructor, or type conversion before '=' token fg_commands.cxx: In function 'void fgInitCommands()': fg_commands.cxx:1476: error: 'built_ins' was not declared in this scope make[2]: *** [fg_commands.o] Error 1 make[2]: Leaving directory `/root/files/flightgear/flightgear-cvs/source/src/Main' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/root/files/flightgear/flightgear-cvs/source/src' make: *** [install-recursive] Error 1 Hope this helps Justin Smithies --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] c172p normalized control surface positions
Hi, The attached patch restores normalized control surface positions on the c172p. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ Index: Aircraft/c172p/c172p.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c172p/c172p.xml,v retrieving revision 1.15 diff -u -r1.15 c172p.xml --- Aircraft/c172p/c172p.xml12 Jan 2006 15:07:14 - 1.15 +++ Aircraft/c172p/c172p.xml5 Mar 2006 21:24:06 - @@ -219,6 +219,19 @@ /range outputfcs/elevator-pos-rad/output /aerosurface_scale + +aerosurface_scale name=Elevator Position Normalized +inputfcs/elevator-pos-deg/input +domain + min-28/min + max23/max +/domain +range +min-1/min +max1/max +/range +outputfcs/elevator-pos-norm/output +/aerosurface_scale /channel channel name=Roll summer name=Roll Trim Sum @@ -240,6 +253,19 @@ outputfcs/left-aileron-pos-rad/output /aerosurface_scale +aerosurface_scale name=Left Aileron Position Normalized +inputfcs/left-aileron-pos-deg/input +domain + min-20/min + max15/max +/domain +range +min-1/min +max1/max +/range +outputfcs/left-aileron-pos-norm/output +/aerosurface_scale + aerosurface_scale name=Right Aileron Control inputfcs/roll-trim-sum/input gain-0.01745/gain @@ -249,6 +275,19 @@ /range outputfcs/right-aileron-pos-rad/output /aerosurface_scale + +aerosurface_scale name=Right Aileron Position Normalized +inputfcs/right-aileron-pos-deg/input +domain + min-15/min + max20/max +/domain +range +min1/min +max-1/max +/range +outputfcs/right-aileron-pos-norm/output +/aerosurface_scale /channel channel name=Yaw summer name=Yaw Trim Sum @@ -269,6 +308,19 @@ /range outputfcs/rudder-pos-rad/output /aerosurface_scale + +aerosurface_scale name=Rudder Position Normalized +inputfcs/rudder-pos-deg/input +domain + min-16/min + max16/max +/domain +range +min-1/min +max1/max +/range +outputfcs/rudder-pos-norm/output +/aerosurface_scale /channel channel name=Flaps kinematic name=Flaps Control @@ -293,6 +345,19 @@ /traverse outputfcs/flap-pos-deg/output /kinematic + +aerosurface_scale name=Flaps Position Normalized +inputfcs/flap-pos-deg/input +domain + min0/min + max30/max +/domain +range +min0/min +max1/max +/range +outputfcs/flap-pos-norm/output +/aerosurface_scale /channel /flight_control aerodynamics pgpfpq65rIgcq.pgp Description: PGP signature
[Flightgear-devel] Re: fix for exit crash
* Jean-Yves Lefort -- Sunday 05 March 2006 03:06:
The attached patch fixes a crash which occurs on exit.
Anyone else seeing this crash (which really is a deliberate abort())?
Or is it a BSD feature?
In the FGMetarEnvironmentCtrl destructor, thread-cancel() causes the
following thread-join() call to return without actually waiting on
the thread (btw, thread-cancel() does not cause the thread to exit).
It causes the thread to to be left at the next cancellation point,
that would be the wait() in the SGBlockingQueue::pop. So the guarded
mutex should automatically be unlocked and the thread left. That's
according to the documentation and works here.
+FGMetarEnvironmentCtrl::stop()
+{
+request_queue.push( string() );// ask metar thread to terminate
+thread-join();
+}
This doesn't make sense to me. You want to push an empty string
for the wait() to function as cancellation point? It should work
as such without that.
m. :-/
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiesbaden: Flightgear on LinuxTag
Tiago and I have been working on this pdf-svg to ac converter, that uses airport pdf maps to create 3Dimensional models loadable in flightgear. Those models are complete with runways and taxiways. Attached is a screenshot of the buildings at Wiesbaden. We still have a couple of bugs as you can see on the picture (wrong location and non-convex problem). We are currently trying to fix them. You guys might be interested in incorporating these buildings in the scenery for the linux show, provided we got them working correctly. Any help or suggestions that you may have are more than welcome. http://flamebunny.homelinux.net/pics/ETOU.jpgJulien
[Flightgear-devel] Ground structures pulled from diagrams.
On Mon, 6 Mar 2006 01:04:48 -0500 Ampere K. Hardraade wrote: Julien is working on a program called svg2ac. The other day, we did an experiment generating the Frankfurt airport out of an FAA's airport diagram using this program. http://flamebunny.homelinux.net/pics/EDDF.jpg As you can see, there are still some bugs that need to be ironed out, and Julien could use some help in this area. But once everything works properly, buildings' size and placement would be accurate down to the meter. This should cut down your work considerably, I would imagine. ;) If there's some way to make them not look like white boxes, but rather like real ground structures look -- whether through texturing, or just solid material colors on the polys without using textures-- I agree. Without that, I dunno. In response to something I was playing with a year or two ago, David Megginson made the point to me (and I had to concede he was right) that scenery objects that look crude (in a graphics sense) can be worse than if they weren't even there in the scene at all; they stick out against the more realistic-looking terrain, runways, etc., and break the user's suspension of disbelief. So the question is, how easy/hard will it be to edit the structures after generation -- to give them a look other than grey/white boxes? Are they going into invididual .ac files, or one big .ac file for an entire area (including many buildings)? Or is the plan to provide some generic wall/roof colors or textures to these structures when generated? -c P.S. Are the European airport diagrams really that accurate as far as the structures are concerned? The U.S. FAA airport diagrams aren't; the locations and shapes of buildings in them, and even the shapes of aprons, can sometimes be off by significant amounts (more than just a meter or two). -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear signature.asc Description: PGP signature
