Re: [Flightgear-devel] Rain and snow videos or photos
- Original Message - From: "Ampere K. Hardraade" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" Sent: Monday, January 24, 2005 4:40 PM Subject: Re: [Flightgear-devel] Rain and snow videos or photos > On January 24, 2005 06:16 pm, Roman Grigoriev wrote: > > Thanx Ampere! > > The main thing I got - blur on terrain and objects and blurry runway lights > > and also reflections from wet runway. Ok I try to implement it ;-) > > Thanx > Speaking of blur, is there someway to apply antialiasing effect in the area > bounded by the windshield? Good idea Ampere! It can be easily done. You have to prepared texture mask for clear windshild and blend it in fragment stage. I try it and post some screenshots. Bye Roman > > > > Ampere > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] AirportList
OK, I appear to have the Select Airport from List
option working properly (as far as I can tell). I'm
not completely happy with the solution, as I have had
to declare a constant for PUCLASS_LIST that could be
reassigned within plib. I have used a value at the top
end of the scale to try to reduce the risk, but it is
still possible that this could be broken by changes to
plib.
I'll include the diffs here in case this is worth
using, or in case anyone would like to offer any
advice or suggestions.
regards
Andrew
Index: GUI/AirportList.cxx
===
RCS file:
/var/cvs/FlightGear-0.9/source/src/GUI/AirportList.cxx,v
retrieving revision 1.8
diff -r1.8 AirportList.cxx
25c25
<
---
>
44c44
< AirportList::getStringValue ()
---
> AirportList::getListStringValue ()
46c46
< return (char
*)_airports->getAirport(getIntegerValue())->_id.c_str();
---
> return (char
*)_airports->getAirport(getListIntegerValue())->_id.c_str();
Index: GUI/AirportList.hxx
===
RCS file:
/var/cvs/FlightGear-0.9/source/src/GUI/AirportList.hxx,v
retrieving revision 1.1
diff -r1.1 AirportList.hxx
18c18
< virtual char * getStringValue ();
---
> virtual char * getListStringValue ();
Index: GUI/dialog.cxx
===
RCS file:
/var/cvs/FlightGear-0.9/source/src/GUI/dialog.cxx,v
retrieving revision 1.17
diff -r1.17 dialog.cxx
138c138,147
<
node->setStringValue(object->getStringValue());
---
> // Special case to handle lists, as
getStringValue cannot be overridden
> if(object->getType() & PUCLASS_LIST)
> {
> node->setStringValue(((puList *)
object)->getListStringValue());
> }
> else
> {
>
node->setStringValue(object->getStringValue());
> }
>
401c410
return puTextBox;
Index: GUI/puList.cxx
===
RCS file:
/var/cvs/FlightGear-0.9/source/src/GUI/puList.cxx,v
retrieving revision 1.1
diff -r1.1 puList.cxx
55a56
> type |= PUCLASS_LIST;
61a63
> type |= PUCLASS_LIST;
78c80
< puList::getStringValue ()
---
> puList::getListStringValue ()
82a85,90
> int
> puList::getListIntegerValue()
> {
> return _list_box->getIntegerValue();
> }
>
Index: GUI/puList.hxx
===
RCS file:
/var/cvs/FlightGear-0.9/source/src/GUI/puList.hxx,v
retrieving revision 1.4
diff -r1.4 puList.hxx
11a12,13
> # define PUCLASS_LIST 0x8000 // Hopefully
this value will never be used by plib
>
27c29,30
< virtual char * getStringValue ();
---
> virtual char * getListStringValue ();
> virtual int getListIntegerValue();
Index: gui/dialogs/airports.xml
===
RCS file:
/var/cvs/FlightGear-0.9/data/gui/dialogs/airports.xml,v
retrieving revision 1.3
diff -r1.3 airports.xml
1c1
<
---
>
5d4
<
9,12c8,9
<
<
<
---
>
17d13
<
21,22c17,19
< true
<
---
>
> true
>
28,30c25,36
< property-assign
<
/sim/presets/longitude-deg
< -
---
> nasal
>
>
setprop("/sim/presets/longitude-deg",
-);
> setprop("/sim/presets/latitude-deg",
-);
> setprop("/sim/presets/altitude-ft",
-);
> setprop("/sim/presets/airspeed-kt",
0);
>
setprop("/sim/presets/offset-distance", 0);
>
setprop("/sim/presets/offset-azimuth", 0);
>
setprop("/sim/presets/glideslope-deg", 0);
> setprop("/sim/presets/heading-deg",
0);
>
setprop("/sim/presets/runway",
"");
>
33,35c39
< property-assign
< /sim/presets/latitude-deg
< -
---
> dialog-apply
38,40c42
< property-assign
< /sim/presets/altitude-ft
< -
---
> presets-commit
43,46c45
< dialog-apply
<
<
< presets-commit
---
> dialog-close
49,51c48,50
<
< true
<
---
>
> true
>
56c55
< dialog-close
---
> dialog-close
59,60c58,60
<
< true
---
>
> true
>
___
ALL-NEW Yahoo! Messenger - all new features - even more fun!
http://uk.messenger.yahoo.com
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun improvements
Paul Surgeon wrote: > On Tuesday, 25 January 2005 02:29, Tiago Gusmão wrote: > > After reading the glPointSize doc, I think the problem is in using point > > sizes bigger than 1 and point antialiasing at the same time > > I can't test it now, can someone do it? just disable GL_POINT_SMOOTH and > > see it there is an fps improvement > > Bingo! > With GL_POINT_SMOOTH disabled the enhanced lighting runs at exactly the > same > speed as non-enhanced lighting. (40 fps sitting on 28R at KSFO) > Are there any unwanted effects elsewhere, or can this be used as a patch to our code? Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Please use meaningful subject lines
Hi, with sometimes more than a hundred daily posts I'm far from reading them all. Usually I just glance over the subject, read some 2 or 3 posts from the start of a thread and then decide to ignore (or follow) it completely. Having now found out that e.g. under the subject 'fgrun improvements' things like frame rate drops for specific video cards, enhanced lighting at airports etc. were discussed makes me wonder what I have missed in other threads.. :-( So please, if you find that the topic of the post doesn't find the subject line, don't hesitate to change it. Probably in the form "Topic YYY (was: Topic XXX)". Or even better start a new thread. Thank you, Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please use meaningful subject lines
> ... > So please, if you find that the topic of the post doesn't find the subject > ... --- doesn't find +++ doesn't match :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AirportList
Quoting Andrew Midosn: > OK, I appear to have the Select Airport from List > option working properly (as far as I can tell). I'm > not completely happy with the solution, as I have had > to declare a constant for PUCLASS_LIST that could be > reassigned within plib. I have used a value at the top > end of the scale to try to reduce the risk, but it is > still possible that this could be broken by changes to > plib. > > I'll include the diffs here in case this is worth > using, or in case anyone would like to offer any > advice or suggestions. Hi Andrew, Thanks for your efforts. I just have practical remarks regarding patch post to the list. Use unidiff ( -u ) because all those > are confusing mail readers that interpret added lines as message quote Attach the file because many lines are split Better yet, send directly to one maintainer with CVS write access This way you will avoid the frustration of having your patch ignored just because it is unusable without a man-month worth of effort to rebuild something that could be understood by the patch utility. Regards, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Tuesday, 25 January 2005 10:33, Vivian Meazza wrote: > Paul Surgeon wrote: > > On Tuesday, 25 January 2005 02:29, Tiago Gusmão wrote: > > > After reading the glPointSize doc, I think the problem is in using > > > point sizes bigger than 1 and point antialiasing at the same time > > > I can't test it now, can someone do it? just disable GL_POINT_SMOOTH > > > and see it there is an fps improvement > > > > Bingo! > > With GL_POINT_SMOOTH disabled the enhanced lighting runs at exactly the > > same > > speed as non-enhanced lighting. (40 fps sitting on 28R at KSFO) > > Are there any unwanted effects elsewhere, or can this be used as a patch to > our code? Well the endhanced lighting with GL_POINT_SMOOTH looks awful on my Ti 4200. Big square shaped polygons. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please use meaningful subject lines
But that breaks the message threading capabilites of mail readers which some people dislike. One ends up with 2 or 3 threads on the same topic and you have to jump between them. Paul On Tuesday, 25 January 2005 11:14, Thomas Förster wrote: > Hi, > > with sometimes more than a hundred daily posts I'm far from reading them > all. Usually I just glance over the subject, read some 2 or 3 posts from > the start of a thread and then decide to ignore (or follow) it completely. > > Having now found out that e.g. under the subject 'fgrun improvements' > things like frame rate drops for specific video cards, enhanced lighting at > airports etc. were discussed makes me wonder what I have missed in other > threads.. :-( > > So please, if you find that the topic of the post doesn't find the subject > line, don't hesitate to change it. Probably in the form "Topic YYY (was: > Topic XXX)". Or even better start a new thread. > > Thank you, > Thomas > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How to convert from WGS84 coordinates?
Manuel Massing ha scritto: Hello Robicd, I've made a .ase 3d object (a Villa of my town) for a scenery. I have a satellite picture of the place where the Villa resides, which has "datum wgs84" coordinates of the two corners of the bitmap. I really don't know how to convert such coordinates (1st corner is 353620.2/4225543.6, 2nd corner is 354212.2/4225976.1) to a format suitable for a .stg file. These coordinates don't mean much by themselves, you need to know which projection they relate to. Probably a UTM projection in your case. You're right, the picture shows a Projection field too. Complete infos are: Datum: WGS84 Projection: NUTM33 Coordinate top left x: 353620.2 y: 4225543.6 Coordinate bottom right x: 354212.2 y: 4225976.1 Scale: 1:2944 Is this enough for making a correct unit conversion? I would like to comprehend what all those units mean but ... I guess there's no Coordinates-MiniHowto :-( There should be one. > I would > recommend you install gdal (http://www.gdal.org/), and use gdalinfo to > get projection information for your file. You can than use > gdal_translate + gdalinfo or a proj4 tool to convert between projected > or pixel coordinates and lat/lon. I'll take a look. cheers, Manuel The Agriculture Department of the State I lieve in (which is Italy) offers for free those aerial/satellite pictures which are not the same quality as the Keyhole's ones but are pretty good anyway. The whole state is covered, resolution is not very high but there are rumours about near future enhancements of the content. I think I can't redistribute those images being non GPLd but they're free for personal use and they look very nice :-) I promise, I will write down a howto as soon as I get them texturizing my landscape in FGFS :-) Thx, Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Tuesday, 25 January 2005 12:11, you wrote: > On Tuesday, 25 January 2005 10:33, Vivian Meazza wrote: > > Paul Surgeon wrote: > > > On Tuesday, 25 January 2005 02:29, Tiago Gusmão wrote: > > > > After reading the glPointSize doc, I think the problem is in using > > > > point sizes bigger than 1 and point antialiasing at the same time > > > > I can't test it now, can someone do it? just disable GL_POINT_SMOOTH > > > > and see it there is an fps improvement > > > > > > Bingo! > > > With GL_POINT_SMOOTH disabled the enhanced lighting runs at exactly the > > > same > > > speed as non-enhanced lighting. (40 fps sitting on 28R at KSFO) > > > > Are there any unwanted effects elsewhere, or can this be used as a patch > > to our code? > > Well the endhanced lighting with GL_POINT_SMOOTH looks awful on my Ti 4200. > Big square shaped polygons. > > Paul Oops! I meant enhanced runway lighting looks awful *WITHOUT* GL_POINT_SMOOTH enabled. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AirportList
--- Frederic Bouvier <[EMAIL PROTECTED]> wrote: > Thanks for your efforts. I just have practical > remarks regarding patch post to > the list. > > Use unidiff ( -u ) because all those > are confusing > mail readers that interpret > added lines as message quote > > Attach the file because many lines are split > > Better yet, send directly to one maintainer with CVS > write access > > This way you will avoid the frustration of having > your patch ignored just > because it is unusable without a man-month worth of > effort to rebuild something > that could be understood by the patch utility. Thanks for the advice. I'll try and sort that out when I get back from work. Who would be the best person to send the diffs to? Regards Andrew ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: AirportList
* Andrew Midosn -- Tuesday 25 January 2005 09:28: > 59,60c58,60 > < > < true > --- > > > > true > > ... and make sure that you don't accidentally send the patch to the developer whose coding style you are "correcting" along with your functional changes, especially if these changes are completely unrelated. m. :-] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AirportList
Quoting Andrew Midosn: > --- Frederic Bouvier <[EMAIL PROTECTED]> wrote: > > > Thanks for your efforts. I just have practical > > remarks regarding patch post to > > the list. > > > > Use unidiff ( -u ) because all those > are confusing > > mail readers that interpret > > added lines as message quote > > > > Attach the file because many lines are split > > > > Better yet, send directly to one maintainer with CVS > > write access > > > > This way you will avoid the frustration of having > > your patch ignored just > > because it is unusable without a man-month worth of > > effort to rebuild something > > that could be understood by the patch utility. > > Thanks for the advice. I'll try and sort that out when > I get back from work. Who would be the best person to > send the diffs to? It depends of the patch. Curt and Erik have full access ( with DavidM but he is offline for several weeks ). Some specific modules have their own maintainer with write access restricted to the directory they manage ( Andy for yasim, DaveL for ATC, Jim can access the base package ). You can have a look at flightgear-cvslog for a track of who is doing what. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Getting the right View position and orientation
Hi Jim, >It may help for you to explain more about what you are trying to do. Is this >exhaust smoke from a moving aircraft model? Probably I'm the one to help you >since I rewrote most of the viewer a couple years ago, but I just don't >understand what you are asking. > >This is may not help, since I am guessing about what you are trying to do, but >take a look at the code in SimGear/scene/model to see how to place an ssg >object (ssgBranch) in the scene. This can be used for both stationary and >moving objects. I'm trying to add the smoke like the one of the acrobatic aircrafts (for example, the Frecce Tricolori). To do that I've used a modified version of the ssgaParticleSystem. I'm able to correctly place the objects - they appear "inside" the aircraft - and their position doesn't change when the aircraft moves (in the first attempt, I've add the particle system to the aircraft node into the nodegraph of PLIB, but this doesn't work right). Instead, I've add a function that moves randmly the particles into the 3D space. My main problem is that the particles doesn't rotate to follow the point of view of the user so they are visible only when their normal points to the user. I've watched the code that rotates the particles into the ssgaParticleSystem.cxx file and I've found that the tecnique used rotates the objects using the data stored into the GL_MODELVIEW matrix. I've printed it on the screen and, in FlightGear this matrix is always the identity matrix: I've found the problem, but I'm not able to find a solution. I've watched the code of the billboard animation, the viewer manager and the viewer files, but I'n not able to get the rotation and the position of the point of view into the space. If I could get this data, I'll able to create a matrix like the GL_MODELVIEW and use it to rotate the objects. Thanks, Luca Navighi a 2 MEGA e i primi 3 mesi sono GRATIS. Scegli Libero Adsl Flat senza limiti su http://www.libero.it ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please use meaningful subject lines
Thomas F?rster wrote: > with sometimes more than a hundred daily posts I'm far from reading them all. > Usually I just glance over the subject, read some 2 or 3 posts from the start > of a thread and then decide to ignore (or follow) it completely. I am running a Mail2News gateway at home for many years now to host the mailing lists I am subscribed to and I am very satisfied with this solution. If enough people are interested I might consider to offer NNTP over SSL for subscribers, 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: --aircraft=ufo in system.fgfsrc is ignored
Hi,
As always, thank you all for a great flight simulator +++
Have been enjoying it, and your exchange here for 'yonks' ;=))
RE: --aircraft=ufo in system.fgfsrc is ignored
To change a 'feature', one that has been mentioned here many
times, and again recently, place the following code block
into fgInitFGAircraft (in fg_init.cxx), at about
line 343, just before the fgSetString("/sim/aircraft" ...
+
if ( aircraft.empty() ) {
// Check for $fg_root/system.fgfsrc
SGPath sysconf( globals->get_fg_root() );
sysconf.append( "system.fgfsrc" );
aircraft = fgScanForOption( "--aircraft=", sysconf.str() );
}
+
If this behaviour change is agreed, then maybe someone who has
tested the patch, can send a diff to Curt, or directly
update CVS ...
In its favour, I would argue this means FG can be run without
a command line, provided FG_ROOT has been set in the
environment, and that seems to me, as it should be ... ;=))
Perhaps the only counter, is that system.fgfsrc is read twice,
but so are others, like .fgfsrc, for other (local) options ...
or system.fgfsrc should .nt. be used for 'aircraft' ?
It certainly paves the way for fgrun to simply write the
system.fgfsrc, and run the binary with a minimum of command
line parameters ... and leaves a persistent file 'trace'
of what fgrun 'requested' of FG ... more info benefit ...
Continue to enjoy ...
Regards,
Geoff.
_
SEEK: Now with over 60,000 dream jobs! Click here:
http://ninemsn.seek.com.au?hotmail
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Quoting Geoff Air: > It certainly paves the way for fgrun to simply write the > system.fgfsrc, and run the binary with a minimum of command > line parameters ... and leaves a persistent file 'trace' > of what fgrun 'requested' of FG ... more info benefit ... Because some argued, and I mostly agree, that fgrun shouldn't overwrite user's preferences, command line options are now used. This is why I want to keep the command line textbox : people can see what's going on and can provide these informations when asking for support. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: AirportList
--- Melchior FRANZ <[EMAIL PROTECTED]> wrote: > * Andrew Midosn -- Tuesday 25 January 2005 09:28: > > 59,60c58,60 > > < > > < true > > --- > > > > > > true > > > > > ... and make sure that you don't accidentally send > the patch to the > developer whose coding style you are "correcting" > along with your > functional changes, especially if these changes are > completely unrelated. > > m. :-] Ooops - I didn't notice that! I suspect it was the XML editor I was using deciding to enforce its own style. I certainly don't remember making any changes to that part of the file. I would normally try to adopt the coding style of the file I'm editing as far as possible - it's just polite. I'll go back to using vi I think - that's usually quite well behaved. Regards Andrew ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please use meaningful subject lines
On Tue, 25 Jan 2005 12:13:49 +0200 Paul Surgeon wrote: > > But that breaks the message threading capabilites of mail readers which > some people dislike. > One ends up with 2 or 3 threads on the same topic and you have to jump > between them. Most mailreaders these days thread not on the subject, but on the References: or In-Reply-To: headers or stuff like that. But out of consideration to ones that thread on Subject:, one can solve this the way Usenet folks have for ages -- use the "was:" convention. e.g. given a thread with subject Subject: fgrun improvements when someone in the thread starts to discuss lighting, they can change the subject line to Subject enhanced lighting fps (was: fgrun improvements) If *that* isn't enough, then we're talking about trying to accomodate bugged/broken mail readers. -c -- 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 pgptEOjQgAuo5.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Frederic Bouvier wrote: > Quoting Geoff Air: >> It certainly paves the way for fgrun to simply write the >> system.fgfsrc, and run the binary with a minimum of command >> line parameters ... and leaves a persistent file 'trace' >> of what fgrun 'requested' of FG ... more info benefit ... > > Because some argued, and I mostly agree, that fgrun shouldn't overwrite user's > preferences, command line options are now used. Nevertheless the proposed make much sense for those who don't use FGrun but configure FlightGear using the system.fgfsrc instead. Thanks, Geoff, 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] Problem solved about particle system
Hi, at last I solved the billboarding problem about the particles. I've changed some settings into the ssgSimpleState object, used to add the texture to particles, and the size of the bounding sphere. Now, even with the data stored into the GL_MODELVIEW matrix the objects are always visible. So, I don't need to get the view position and orientation data to correctly rotate the objects. Thanks, Luca Navighi a 2 MEGA e i primi 3 mesi sono GRATIS. Scegli Libero Adsl Flat senza limiti su http://www.libero.it ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Martin Spott wrote: > Frederic Bouvier wrote: > > Quoting Geoff Air: > > >> It certainly paves the way for fgrun to simply write the > >> system.fgfsrc, and run the binary with a minimum of command > >> line parameters ... and leaves a persistent file 'trace' > >> of what fgrun 'requested' of FG ... more info benefit ... > > > > Because some argued, and I mostly agree, that fgrun shouldn't overwrite > user's > > preferences, command line options are now used. > > Nevertheless the proposed make much sense for those who don't use > FGrun but configure FlightGear using the system.fgfsrc instead. I was not arguing against the patch but reacting to the idea that fgrun should overwrite system.fgfsrc or any user file. But... The fact that Geoff tells that the file is read twice ring a little bell in my mind. I think the issue was raised sometimes ago and could have unwanted side effects I can't recollect for the moment. A search in the mailing list archives maybe will enlight us more. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Andy Ross said: > Jim Wilson wrote: > > If you look at that manual the diagram in Section I that shows > > the control box, indicates at #12 "Prop Control" (I've only got > > about 6 pages from that manual). That's the blue knob with the > > P on it in the model. The control box indicates "Max RPM" with > > the blue knob all the way forward. > > > > What does the manual say about that control? > > Here's the relevant section: > > PROPELLER. > > The airplane is equipped with an 11-foot 2-inch diameter, > four-bladed, constant-speed, Hamilton Standard Hydroatic > propeller of the nonfeathering type. A propeller governor > mechanically controleld from teh cockpit admits engine oil to the > propeller dome for pitch changes necessary to maintain a constant > engine sped. Engine oil pressure is used to aid th ecentrifugal > twisting moment of the blades toward low pitch (increase rpm), an > dboosted engine oil pressure through the governor moves the > blades toward high pitch (decrease rpm). > > Propeller Control. > > A propeller control (12, figure 1-4) located on teh throttle > quadrant, is mechanically linked to the governor. The control > setting determines the engine rpm, which is maintained constant > by the propeller governor. The propeller control may be > positioned at INCREASE or DECREASE or to any intermediate > position. > > The range of RPM settings I see in the performance tables is > 1600-3000, so those are probably reasonable numbers to use for > the min/max range. I'm sure real planes would vary due to > calibration issues anyway. > The min/max range, does that refer to engine RPM or propellor? Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Frederic Bouvier wrote: > But... The fact that Geoff tells that the file is read twice ring a little > bell > in my mind. I think the issue was raised sometimes ago and could have unwanted > side effects I can't recollect for the moment. It makes sense - especially in the context of the claim, that $HOME/.fgfsrc on Unix a read more than once as well. See, as nice as the XML configuration system is, it _must_ bring such a 'feature' to the developer. In order to figure which command line paramters you are allowed to use you have first to determine $FG_ROOT. If $FG_ROOT is defined by the $HOME/.fgfsrc alias 'system.fgfsrc', then you have to red that file first, look for $FG_ROOT, read the necessary details and then reread the config file in order to figure which of the details is being triggered in the config. There's nothing abnormal with such a procedure. Well, it might be cleaner to create an array to store the parameters that you read from the config file and later do multiple reads on this array but the basic approach is the same, 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: --aircraft=ufo in system.fgfsrc is ignored
Quoting Martin Spott: > Frederic Bouvier wrote: > > > But... The fact that Geoff tells that the file is read twice ring a little > bell > > in my mind. I think the issue was raised sometimes ago and could have > unwanted > > side effects I can't recollect for the moment. > > It makes sense - especially in the context of the claim, that > $HOME/.fgfsrc on Unix a read more than once as well. > See, as nice as the XML configuration system is, it _must_ bring such > a 'feature' to the developer. In order to figure which command line > paramters you are allowed to use you have first to determine $FG_ROOT. > If $FG_ROOT is defined by the $HOME/.fgfsrc alias 'system.fgfsrc', then > you have to red that file first, look for $FG_ROOT, read the necessary > details and then reread the config file in order to figure which of the > details is being triggered in the config. > > There's nothing abnormal with such a procedure. Well, it might be > cleaner to create an array to store the parameters that you read from > the config file and later do multiple reads on this array but the basic > approach is the same, I was not clear. Reading the file twice is not a problem. Loading an aircraft twice might be. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Disabling functionality
Hey All, I'm new to FlightGear, and am trying to use it as an image generator for a simulator I'm developing...I've got it configured to take inputs from a UDP port to fly, but I want to disable a lot of features so that all FlightGear does is draw scenery. In particular, I want to completely remove the instrument panel, the menus at the top, disable sounds, bypass the flight model (for the sake of execution speed) and so forth. But whenever I try to comment things out of the .xml files, I get errors. It's easy to change things, but it seems that removing them creates problems. For instance, menubar.xml seems happy with this: but then it draws a small grey box at the corner of the screen. If I comment any more out, I get errors. Commenting an entire airplane out doesn't seem to work, eitherand when I try to remove the panel, it reverts to a different panel. Can anyone point me in the right direction to get this working? Thanks. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Disabling functionality
Drew wrote: > Can anyone point me in the right direction to get this working? 1.) # ~> fgfs --help --verbose | grep disable 2.) fgfs --aircraft=ufo --disable. 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: Disabling functionality
* Drew -- Tuesday 25 January 2005 18:11: > [...] I want to completely remove [...] the menus at the top [...] $ fgfs --prop:/sim/menubar/visibility=0 Enable with F10. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Disabling functionality
wow, that was quick and helpful, thanks guys. On Tue, 25 Jan 2005 17:36:48 + (UTC), Martin Spott <[EMAIL PROTECTED]> wrote: > Drew wrote: > > > Can anyone point me in the right direction to get this working? > > 1.) # ~> fgfs --help --verbose | grep disable > 2.) fgfs --aircraft=ufo --disable. > > 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 mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Jim Wilson wrote: > The min/max range, does that refer to engine RPM or propellor? Propeller. It's a setting for the governor. With the newer syntax, the engine and propeller are separate XML tags, so hopefully it should be clearer which is which. If an attribute on the propeller tag takes engine RPM, then that would be a bug. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How to convert from WGS84 coordinates?
> You're right, the picture shows a Projection field too. Complete infos are:
>
> Datum: WGS84
> Projection: NUTM33
>
> Coordinate top left
> x: 353620.2 y: 4225543.6
>
> Coordinate bottom right
> x: 354212.2 y: 4225976.1
Those are odd looking numbers. The WGS84 standard specifies a
"datum", which is a mapping of lat/lon/altitude coordinates to a 3D
cartisian coordinate system. Specifically, it calls the zero-altitude
surface ("sea level", sorta, although it doesn't always coincide with
actual MSL in all areas) a slightly flattened ellipsoid with an
exactly specified equation.
That said, WGS84 numbers are still plain looking latitude and
longitude values, usually written in degrees. They aren't ever called
"x" or "y" (which for obvious reasons is really confusing). My guess
is that those numbers are arbitrary 2D coordinates used by the
satellite photo software. Or maybe they're well-specified 2D
coordinates in the NUTM33 projection* about which I know nothing.
* A projection is not the same thing as a datum. It is a mapping of
2D (!) lat/lon values to a 2D cartesian surface. Becuase this
transformation is lossy, projections get really, really complicated.
Many are specified with giant lookup tables and/or curve fitting.
I'd hunt around in the documentation you have for the photo to try to
figure out what it's talking about.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Andy Ross said: > Jim Wilson wrote: > > The min/max range, does that refer to engine RPM or propellor? > > Propeller. It's a setting for the governor. With the newer syntax, > the engine and propeller are separate XML tags, so hopefully it should > be clearer which is which. If an attribute on the propeller tag takes > engine RPM, then that would be a bug. :) > But those numbers you gave me seem to be engine RPM numbers. Sorry for the confusion. The gear ratio is 0.479 and the merlin max rpm is 3000 rpm. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] How to convert from WGS84 coordinates?
Andy Ross writes: > > > > You're right, the picture shows a Projection field too. Complete infos are: > > > > Datum: WGS84 > > Projection: NUTM33 > > > > Coordinate top left > > x: 353620.2 y: 4225543.6 > > > > Coordinate bottom right > > x: 354212.2 y: 4225976.1 > > Those are odd looking numbers. These are UTM North Zone 33 http://www.dmap.co.uk/utmworld.htm You probably will want to warp these into LatLon space http://www.remotesensing.org/gdal/gdal_utilities.html#gdalwarp is a quality tool for doing this, there are others HTH Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Jim Wilson wrote: > But those numbers you gave me seem to be engine RPM numbers. Sorry > for the confusion. The gear ratio is 0.479 and the merlin max rpm > is 3000 rpm. Ah, I get it. Sorry for the confusion. :) I guess the gauge in the cockpit shows engine speed, but the YASim file wants propeller RPMs in the propeller tag, so the proper range would be ~766-1437 or so. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] YASim prop thrust
Jim Wilson wrote > Andy Ross said: > > > Jim Wilson wrote: > > > The min/max range, does that refer to engine RPM or propellor? > > > > Propeller. It's a setting for the governor. With the newer syntax, > > the engine and propeller are separate XML tags, so hopefully it should > > be clearer which is which. If an attribute on the propeller tag takes > > engine RPM, then that would be a bug. :) > > > > But those numbers you gave me seem to be engine RPM numbers. Sorry for > the > confusion. The gear ratio is 0.479 and the merlin max rpm is 3000 rpm. > Yes - perhaps Andy will recall our long discussion of a year ago? Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Vivian Meazza wrote: > Yes - perhaps Andy will recall our long discussion of a year ago? Only vaguely, and I currently lack the time to crawl through the archives. You keep hinting that you want something done. Can you be more specific? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrain elevation question
On Monday 24 January 2005 23:56, David Luff wrote: > On 24/01/2005 at 21:17 Durk Talsma wrote: > >What I am really looking for is a hint where I can find the code in > >FlightGear > > Hi Durk, > > I obtain ground elevation for taxiing AI traffic in AILocalTraffic.cxx, > lines 1569 - 1602 (or thereabouts). Note that this is not a cheap > operation, and you should only do it for traffic in a location which > already has a tile loaded - otherwise it triggers tile loading, resets the > scenery cache to the wrong location, and probably has other undesirable > side effects as well. > Hi Dave, Thanks, That's exactly what I was looking for. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem solved about particle system
On Tuesday 25 January 2005 15:13, Luca Masera wrote: > Hi, > > at last I solved the billboarding problem about the particles. > I've changed some settings into the ssgSimpleState object, > used to add the texture to particles, and the size of the > bounding sphere. Now, even with the data stored into the > GL_MODELVIEW matrix the objects are always visible. > > So, I don't need to get the view position and orientation data > to correctly rotate the objects. > > Thanks, Luca Are there any screen shots yet Luca? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] YASim prop thrust
Andy Ross > Vivian Meazza wrote: > > Yes - perhaps Andy will recall our long discussion of a year ago? > > Only vaguely, and I currently lack the time to crawl through the > archives. You keep hinting that you want something done. Can you be > more specific? > Yes - sorry. I redid the Merlin engine stuff for the Spitfire (lower powered than the P51d, but otherwise much the same). Gear ratio was the issue. The new code failed to converge (or possibly converged to the wrong solution). You were going to look into it, but then got too busy with real work, as I recall. It seems to me that we are going over more or less the same ground. I was going to wait to see if Jim cracked the problem, and then revisit it for the Spitfire. In the meantime, I managed to make a reasonable simulation using a non-geared propeller. I haven't looked at it for ages, and right now I'm busy with aircraft carrier stuff. Don't worry for now - if you solve it for Jim, I expect that it will work for me. If not, we can tackle the problem again. I have all the old discussion available. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Andy Ross said: > Jim Wilson wrote: > > But those numbers you gave me seem to be engine RPM numbers. Sorry > > for the confusion. The gear ratio is 0.479 and the merlin max rpm > > is 3000 rpm. > > Ah, I get it. Sorry for the confusion. :) > > I guess the gauge in the cockpit shows engine speed, but the YASim > file wants propeller RPMs in the propeller tag, so the proper range > would be ~766-1437 or so. > Now I'm finding that we're seeking the engine rpm instead of the prop-rpm. I've looked a bit at the code, but the answer hasn't jumped out at me. I see a few multiplies, but is the gear-ratio in fact being applied properly when evaluating the target rpm? The prop config follows. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Jim Wilson wrote:
> Now I'm finding that we're seeking the engine rpm instead of the
> prop-rpm.
Andy Ross wrote:
> If an attribute on the propeller tag takes engine RPM, then that
> would be a bug.
See? I was exactly right. :)
Can you try the following fix to PropEngine.cpp? That should fix it,
but I can't test right now.
Andy
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/PropEngine.cpp,v
retrieving revision 1.13
diff -u -r1.13 PropEngine.cpp
--- PropEngine.cpp 13 Dec 2004 23:48:43 - 1.13
+++ PropEngine.cpp 26 Jan 2005 00:58:52 -
@@ -216,7 +216,8 @@
// _current_ RPM. Seek to that. This is sort of a continuous
// Newton-Raphson, basically.
if(_variable) {
- float targetOmega = _minOmega + _advance*(_maxOmega-_minOmega);
+ float targetPropSpd = _minOmega + _advance*(_maxOmega-_minOmega);
+float targetOmega = targetPropSpd / _gearRatio; // -> "engine omega"
float ratio2 = (_omega*_omega)/(targetOmega*targetOmega);
float targetTorque = engTorque * ratio2;
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Andy Ross said: > Jim Wilson wrote: > > Now I'm finding that we're seeking the engine rpm instead of the > > prop-rpm. > > Andy Ross wrote: > > If an attribute on the propeller tag takes engine RPM, then that > > would be a bug. > > See? I was exactly right. :) > > Can you try the following fix to PropEngine.cpp? That should fix it, > but I can't test right now. > That works. Things seem much saner now. It's still quite a bit underpowered, but maybe that just means revisiting a few numbers. Speaking of which, in the prop config, what exactly do the "cruise" numbers do? If I'm not getting enough thrust still out of the prop, what should I mess with first? cruise-alt="21400" cruise-power="1470" cruise-speed="380" cruise-rpm="1200" Thanks, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OT: Open Source 3d video card
This might be very interesting for people who are looking for a new 3d video card with full open source drivers: http://kerneltrap.org/node/4622 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Open Source 3d video card
On Wednesday 26 Jan 2005 03:33, Oliver C. wrote: > This might be very interesting for people who are looking > for a new 3d video card with full open source drivers: > > http://kerneltrap.org/node/4622 > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d I'm buying one when they reach market :-) But thats only to find out what they're really like. The cards are to be powered by Xilinx Spartan III FPGA cores. Now, I'm told, the top of the range Spartan III has 5 Million transistors on (90nm) die. A quick comparison with the first generation GeFarce with 23 Million on die and things don't look so good. While the cards should be reasonably capable - I wouldn't expect better than Geforce (1) performance. (and hence FlightGear might be a stretch for this card). Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
