Re: [Flightgear-devel] PNG textures in CVS
On Mon, 18 Feb 2008 21:06:32 + AJ MacLeod <[EMAIL PROTECTED]> wrote: > Hi all, > > Now that our data has been "properly" branched, I would like to move to using > PNG (or, where suitable, JPEG) textures in my models. I've seen no drawbacks > in my testing so far, only considerable benefits... > > In disk space: > 2.5M 2008-02-18 20:50 throttle_panel.rgb > 981K 2008-02-18 20:50 throttle_panel.png > I've converted the Textures/Terrain rgb files to png here, just playing around , and it reduces that folder from 19m to 12m . Haven't noticed any bad effects yet ... Cheers -- Syd&Sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
On Tuesday 19 February 2008 20:05, alexis bory wrote: > LeeE wrote: > > On Friday 15 February 2008 16:36, ricardo freitasfilho wrote: > > > Hi, I'm doing some simulations of a airship using the aerosim > > > blockset and the flightgear. It is usefull if there is a may > > > to get the information of the scenery buildings so we can > > > avoid these building in the simulation. I was reading one of > > > your answers and I got interested in how can I send these > > > information to the blockset. Can you help me with that? > > > > I found, while working on a terrain following/avoidance system > > for some of the aircraft I've done, that the Nasal > > geo.elevation(, ) function will return the height of > > buildings or other structures e.g. bridges located at that > > ,. > > > > There are not any in-built FG scanning schemes/mechanisms > > though, so you'll have to design and implement one in Nasal to > > fit your needs. > > > > Have a look at the cvs BAC-TSR2 TFA nasal stuff to see the > > simple look-ahead scanning schemes I've done. Both of the > > schemes I've used just perform a single track look-ahead scan, > > compensated for yaw but not for turning flight (yet). > > > > LeeE > > I don't know if it could be useful or just pertinent, but I > modeled one of the features of the Intruder's Terrain avoidance > radar. It displays the ground elevations relative to the > aircraft's datum line. the radar shadow is also computed. > > Have a look at the A-6E the display is just under the video > Attitude Indicator. Any comment welcome. > > Cheers, > > Alexis That looks pretty neat - nice aircraft Alexis. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
LeeE wrote: > On Friday 15 February 2008 16:36, ricardo freitasfilho wrote: > > Hi, I'm doing some simulations of a airship using the aerosim > > blockset and the flightgear. It is usefull if there is a may to get > > the information of the scenery buildings so we can avoid these > > building in the simulation. I was reading one of your answers and I > > got interested in how can I send these information to the blockset. > > Can you help me with that? > > I found, while working on a terrain following/avoidance system for > some of the aircraft I've done, that the Nasal geo.elevation(, > ) function will return the height of buildings or other > structures e.g. bridges located at that ,. > > There are not any in-built FG scanning schemes/mechanisms though, so > you'll have to design and implement one in Nasal to fit your needs. > > Have a look at the cvs BAC-TSR2 TFA nasal stuff to see the simple > look-ahead scanning schemes I've done. Both of the schemes I've used > just perform a single track look-ahead scan, compensated for yaw but > not for turning flight (yet). > > LeeE I don't know if it could be useful or just pertinent, but I modeled one of the features of the Intruder's Terrain avoidance radar. It displays the ground elevations relative to the aircraft's datum line. the radar shadow is also computed. Have a look at the A-6E the display is just under the video Attitude Indicator. Any comment welcome. Cheers, Alexis - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch v2 - Rain & Snow
Nicolas wrote > Subject: Re: [Flightgear-devel] Patch v2 - Rain & Snow > > > With the attachment, it's better... > > Le lundi 18 février 2008 à 20:51 +0100, Nicolas a écrit : > > Hi, > > > > New revision for the precipitation patch... > > > > The patch is always linked to METAR informations. > > > > Changelog of this new release : > > 1) Link the precipitation object to tile element : > > Now, there is one precipitation object per tile. It permits > to use the > > world coordinate. I have followed the Tim'advices... > > > > 2) Add links between precipitation and cloud layers : > > When you are above the cloud layer, the precipitations are stopped. > > > > > > For the next release, I hope fixed the wind issue... > > > > > > Thank's to Tim and Vivian to help my with this developpement. > > > > Coming along nicely - ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/bucc-snow.jpg Still snowing in the cockpit though, and I'm not sure that the precipitation's origin moves enough in response to ac speed. I like the way the rain turns to snow at altitude, and the reaction to cloud layer. A good version 2, I would recommend its inclusion in CVS. Thanks Nicklas, Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture Filtering
On Feb 19, 2008 11:21 AM, Melchior FRANZ wrote: > * Curtis Olson -- Tuesday 19 February 2008: > > Is there any reason to not turn on anisotropic texture > > filtering by default in the OSG branch? > > For me it looks like it doesn't only *not* turn it on, but > even turns it off, no matter how the driver is configured. There are too many double negatives in your response for me to parse! I see a dramatic improvement in texture sharpness when I activate this option ... this is especially visible on take off or landing as you look at the markings down on the opposite end of the runway. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Setting up asterisk server for fgcom on a LAN
On Feb 19, 2008 5:45 PM, Nick Othieno <[EMAIL PROTECTED]> wrote: > Do I also need to change the fgcom code so that it connects to my > local asterisk server instead of the one provided by Holger. --voipserver| -S voip server to connect to I'll leave the rest to Holger ;) -- Csaba/Jester - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture Filtering
* Curtis Olson -- Tuesday 19 February 2008: > Is there any reason to not turn on anisotropic texture > filtering by default in the OSG branch? For me it looks like it doesn't only *not* turn it on, but even turns it off, no matter how the driver is configured. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture Filtering
2007/4/30 Olaf Flebbe :
> Hi,
>
> changed the patch, texture filtering is now a global property, since
> rendering of landscape textures can be dramatically improved by
> anisotropic filtering.
>
> There is a command switch --texture-filtering={1,2,4,8,16} and the
> rendering options panel contains a selector changing the whole scene at
> once.
>
> Have fun,
>Olaf
>
I'm digging back to a message from last April. Is there any reason to not
turn on anisotropic texture filtering by default in the OSG branch? This
makes runway, terrain, and aircraft textures look *so* much sharper and on
my machine I don't see any performance difference.
/sim/rendering/filtering is the property associated with the
--texture-filtering= option.
Thanks,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Setting up asterisk server for fgcom on a LAN
Hi guys, What configurations do I need for asterisk so as to run fgcom for players on a LAN? Do I also need to change the fgcom code so that it connects to my local asterisk server instead of the one provided by Holger. Holger, please help on this one. I need directions. Nick - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug#461399: simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
Sorry for the late reply... been ill, and then I had much to catch up on afterwards, and so on... almost forgot I needed to answer this. Andy Ross skrev: Ove Kaaven wrote: It's not just him being cranky about his own pet issues, it's about policy and the pursuit of high software standards. High "standards" for software you (literally!) can't run? Please. This is pedantry and egotism at its worst. I'm terribly sorry my software isn't good enough for you, I really am. But you can either work with me to fix it or take potshots about trivial build problems and "Heisenberg bugs" that can't actually be exhibited. You and Steve picked the latter. I don't quite see what you're talking about. I never "picked" any of this. There are things called "compromise", there are things called "understanding someone else's viewpoint", and there are even things called "seeing things from multiple angles". I'm capable of all these things, and sometimes I try to use my ability to do this to (try to) explain someone else's viewpoint in a rational manner, so that people can understand each other better and hopefully reach a compromise. In *no* way should you mistake *explaining* a viewpoint as unconditionally *sharing* it. I'd be equally capable of explaining *your* viewpoint to Steve if I wanted to. I just don't think it'd help. There's a principle: if two viewpoints (like Steve's and yours) are in irreconcilable conflict, then the rules win. And in this case, the rules are called Debian policy; they say there *is* a problem here, and I need to deal with it, or someone else will, probably by removing the package from the distribution. My only interest here is ensuring that this doesn't happen. To accomplish this, I need to do *something*, and I've explained what my options are. Doing what Steve asks is one, but not the only one. I asked which route to take, and you haven't even tried to answer that. (And for the record, by "high standards" I'm referring to portable code; in general, code written to be very portable is also more robust, and I'm pretty sure Steve holds that principle in high regard. But *I* never accused you of anything. I just want a solution, and reaching a "Steve sucks" consensus doesn't *really* bring me any closer to one.) [* Something, I will point out yet again, that no one has done. Do either you or Steve have console access to a s390, Alpha, or PA-RISC box with 3D hardware? Has *anyone* ever run the Debian fgfs binary on those architectures?] For this issue, that doesn't matter. Like I said in my previous mail, if the package is declared "Architecture: all", then FlightGear *must* build on everything, whether or not anyone actually uses it. Otherwise, the package would have to declare a list of the supported architectures (which would also resolve this bug report, albeit it wouldn't be quite as pretty, and I'd have to maintain that list - but if you insisted...) Still, I know for a fact that some people have run fgfs on Alpha in the past. I'm not sure about S/390 and PA-RISC. Debian developers have SSH access to machines of all Debian architectures. I think the PA-RISC one is currently taken offline until they get around to upgrading its kernel, but I could log into the others. I may not be able to run anything that requires X, though (or, well, maybe I could forward X11 over SSH...). And I'd very much prefer the gcc output I asked for to anything that comes out of a single individual's brain. This stuff is too easy to get wrong, and it's literally one command to run. Just run it and send me the output. Or don't, I guess. Your call. Attached. (So, any surprises in there?) #define __DBL_MIN_EXP__ (-1021) #define __FLT_MIN__ 1.17549435e-38F #define __DEC64_DEN__ 0.001E-383DD #define __CHAR_BIT__ 8 #define __WCHAR_MAX__ 2147483647 #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 #define __FLT_EVAL_METHOD__ 0 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define __GNUC_PATCHLEVEL__ 3 #define __DEC64_MAX_EXP__ 384 #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.18973149535723176508575932662800702e+4932L #define __UINTMAX_TYPE__ long long unsigned int #define __linux 1 #define __DEC32_EPSILON__ 1E-6DF #define __CHAR_UNSIGNED__ 1 #define __LDBL_MAX_EXP__ 16384 #define __linux__ 1 #define __SCHAR_MAX__ 127 #define __USER_LABEL_PREFIX__ #define __STDC_HOSTED__ 1 #define __LDBL_HAS_INFINITY__ 1 #define __DEC64_MIN_EXP__ (-383) #define __DBL_DIG__ 15 #define __FLT_EPSILON__ 1.19209290e-7F #define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L #define __DEC32_MAX__ 9.99E96DF #define __unix__ 1 #define __DECIMAL_DIG__ 36 #define __gnu_linux__ 1 #define __LDBL_HAS_QUIET_NAN__ 1 #define __GNUC__ 4 #define __FLT_HAS_DENORM__ 1 #define __DBL_MAX__ 1.7976931348623157e+308 #define __DBL_HAS_INFINITY__ 1 #define __s390__ 1 #define __DEC32_MIN_EXP__ (-95) #define __LDBL_HAS_DENORM__ 1 #define __DEC128
