Re: [Flightgear-devel] ..the overlength reply with ./makefg DOUPD ADDDEBUG NOPAUSE log
On Fri, 20 Mar 2009 04:24:42 +0100, Arnt wrote in message
<20090320042442.01b2d...@a45.fmb.no>:
> ..now trying a ./maketg DOUPD ADDDEBUG NOPAUSE run to see
> if I get the same SG .configure failure as with ./makefg.
a...@a45:/opt/bygg/tg $ ll /opt/bygg/tg/tmp/templog7.txt
&&md5sum /opt/bygg/tg/tmp/templog7.txt
-rw-r--r-- 1 arnt arnt 24572 Mar 20 05:23 /opt/bygg/tg/tmp/templog7.txt
2a1afc5e55a54918b7c79da781efa6c7 /opt/bygg/tg/tmp/templog7.txt
a...@a45:/opt/bygg/tg $
..but it missed at least this OSG build stuff:
[ 80%] Building CXX object
src/osgPlugins/jp2/CMakeFiles/osgdb_jp2.dir/ReaderWriterJP2.o
Linking CXX shared module ../../../lib/osgPlugins-2.9.1/osgdb_jp2.so
[ 80%] Built target osgdb_jp2
[ 80%] Building CXX object
src/osgPlugins/exr/CMakeFiles/osgdb_exr.dir/ReaderWriterEXR.o
/opt/bygg/tg/OpenSceneGraph/src/osgPlugins/exr/ReaderWriterEXR.cpp:
In function 'unsigned char* exr_load(std::istream&, int*, int*, int*,
unsigned int*)':
/opt/bygg/tg/OpenSceneGraph/src/osgPlugins/exr/ReaderWriterEXR.cpp:103:
warning: unused variable 'channels'
/opt/bygg/tg/OpenSceneGraph/src/osgPlugins/exr/ReaderWriterEXR.cpp:
In member function 'bool ReaderWriterEXR::writeEXRStream(const
osg::Image&, std::ostream&, const std::string&) const':
/opt/bygg/tg/OpenSceneGraph/src/osgPlugins/exr/ReaderWriterEXR.cpp:252:
warning: unused variable 'intenalTextureFormat'
/opt/bygg/tg/OpenSceneGraph/src/osgPlugins/exr/ReaderWriterEXR.cpp:
In member function 'osgDB::ReaderWriter::ReadResult
ReaderWriterEXR::readEXRStream(std::istream&) const':
/opt/bygg/tg/OpenSceneGraph/src/osgPlugins/exr/ReaderWriterEXR.cpp:365:
warning: unused variable 'internalFormat'
Linking CXX shared module ../../../lib/osgPlugins-2.9.1/osgdb_exr.so
[ 80%] Built target osgdb_exr
--
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
Processing maketg, version 1.0.5a, of 2009-03-18, on Fri Mar 20 04:16:23 CET
2009, with command [DOUPD ADDDEBUG NOPAUSE], next
log=[/opt/bygg/tg/tmp/templog7.txt]
Checking 3 arguments ... [DOUPD ADDDEBUG NOPAUSE]
All aguments ok. Will process: [ PLIB OSG SG TG]
The script pauses for input of a 'y' frequently. Any other input, or none, and
it will exit.
Commands checked. Running [maketg] in [/opt/bygg/tg]. Continue?
Doing tool and package update... you will need to enter your PASSWORD
Installing build-essential make automake libtool autoconf
Installing libglut3-dev libopenal-dev libalut-dev libalut0 libopenal0a
libfltk1.1-dev
Installing libfltk1.1 zlib1g-dev zlib1g libwxgtk2.8-0 libwxgtk2.8-dev
Installing libjpeg62-dev libjpeg62 libxi-dev libxi6 libxmu-dev libxmu6
libboost-dev
Installing fluid gawk gettext
Installing gcc g++
Installing cmake cvs subversion cmake
package update... The following should NOT be required, but with the present
SG/FG it is!
Will do 'sudo apt-get install libopenthreads6'
Installing libopenthreads6
Added for terragear-cs...
Installing git-core curl
Installing xlibmesa-gl-dev freeglut3-dev glutg3-dev libglut3-dev xorg-dev
Installing libalut-dev zlib1g-dev
Installing libtiff4 libtiff4-dev libtiff-tools libtiff-opengl
Done tool and package update. Continue?
Processing PLIB ...
Done plib update.
Running autogen.sh in /opt/bygg/tg/plib... output to
/opt/bygg/tg/tmp/templog7.txt
Running aclocal
Running automake
Running autoconf
==
Now you are ready to run './configure'
==
Done PLIB autogen.sh. Proceed?
Running ./configure --prefix=/opt/bygg/tg/install/plib
--exec-prefix=/opt/bygg/tg/install/plib
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
includedir changed to ${prefix}/include/plib libdir is ${exec_prefix}/lib
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checki
[Flightgear-devel] ..the overlength reply with ./makefg DOUPD ADDDEBUG NOPAUSE log
On Thu, 19 Mar 2009 21:34:00 +0100, Arnt wrote in message
<20090319213400.659ce...@a45.fmb.no>:
> On Thu, 19 Mar 2009 17:36:46 +0100, Geoff wrote in message
> <1237480606.6461.3.ca...@dell02>:
> ..I'll try, this time too, I'm afraid I must file a motion
> to file an overlength reply. ;o)
..no opposition to file a motion to file an overlength reply
with ./makefg DOUPD ADDDEBUG NOPAUSE log filed. ;o)
..I have SG .configure fail and the SG build succeed, with
gems like:
checking host system type... i686-pc-linux-gnu
includedir changed to ${prefix}/include/simgear libdir is \
${exec_prefix}/lib
Building with Norman's jpeg image factory support
checking for jpeg_start_compress in -ljpeg... yes
..dash or bash playing games here???
..and further:
checking for ftime... yes
checking for gettimeofday... yes
checking for timegm... yes
checking for memcpy... yes
checking for bcopy... yes
checking for mktime... yes
checking for strstr... yes
checking for rand... yes
checking for random... yes
checking for drand48... yes
checking for setitimer... yes
checking for getitimer... yes
checking for signal... yes
checking for GetLocalTime... no
checking for rint... yes
..which I gather yields the same old FG build failure:
/opt/bygg/fg/simgear/source/simgear/timing/timestamp.cxx:79:
undefined reference to `clock_gettime'
/opt/bygg/fg/simgear/source/simgear/timing/timestamp.cxx:76:
undefined reference to `clock_gettime'
collect2: ld returned 1 exit status
> > Not when I run it ;=()
>
> ..??? Another dash|bash thing??? You use dash or bash
> right there as /bin/sh??? (On building FG in that part
> of makefg?)
>
> > I have NO IDEA why you get this error building fgfs.
> > Mine builds ok. You did not give enough output to know
> > exactly what was happening, but when linking fgfs, which
> > includes -lsgtiming, it also includes -lrt, which I think
> > is the library that contains this function.
..my /opt/bygg/fg/tmp/templog4.txt:
a...@a45:/opt/bygg/fg $ ll /opt/bygg/fg/tmp/templog4.txt \
&&md5sum /opt/bygg/fg/tmp/templog4.txt
-rw-r--r-- 1 arnt arnt 26671 Mar 19 23:21
/opt/bygg/fg/tmp/templog4.txt
8a6d7db502b9b6c566ac73c54e1ec150 /opt/bygg/fg/tmp/templog4.txt
a...@a45:/opt/bygg/fg $
..now trying a ./maketg DOUPD ADDDEBUG NOPAUSE run to see
if I get the same SG .configure failure as with ./makefg.
--
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
Processing makefg, version 1.0.5, of 2009-03-18, on Thu Mar 19 22:20:04 CET
2009, with command [DOUPD ADDDEBUG NOPAUSE], next
log=[/opt/bygg/fg/tmp/templog4.txt]
Checking 3 arguments ... [DOUPD ADDDEBUG NOPAUSE]
All aguments ok. Will process: [ PLIB OSG SG FG FGRUN]
The script pauses for input of a 'y' frequently. Any other input, or none, and
it will exit.
Commands checked. Running [makefg] in [/opt/bygg/fg]. Continue?
Doing tool and package update... you will need to enter your PASSWORD
Installing build-essential make automake libtool autoconf
Installing libglut3-dev libopenal-dev libalut-dev libalut0 libopenal0a
libfltk1.1-dev
Installing libfltk1.1 zlib1g-dev zlib1g libwxgtk2.8-0 libwxgtk2.8-dev
Installing libjpeg62-dev libjpeg62 libxi-dev libxi6 libxmu-dev libxmu6
libboost-dev
Installing fluid gawk gettext
Installing gcc g++
Installing cmake cvs subversion cmake
package update... The following should NOT be required, but with the present
SG/FG it is!
Will do 'sudo apt-get install libopenthreads6'
Installing libopenthreads6
Done tool and package update. Continue?
Processing PLIB ...
Done plib update.
Running autogen.sh in /opt/bygg/fg/plib... output to
/opt/bygg/fg/tmp/templog4.txt
Running aclocal
Running automake
Running autoconf
==
Now you are ready to run './configure'
==
Done PLIB autogen.sh. Proceed?
Running ./configure --prefix=/opt/bygg/fg/install/plib
--exec-prefix=/opt/bygg/fg/install/plib
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
includedir changed to ${prefix}/include/plib libdir is ${exec_prefix}/lib
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking w
Re: [Flightgear-devel] Atmosphere temperature model
On 03/19/2009 04:43 PM, Lauri Peltonen wrote: > First of all I'd like to say hi to all as this is my first message to > this list! Hi :) Hi. I hope your contributions meet a better fate than mine have. > Then, when messing around with fg, I noticed that the current atmosphere > model is somewhat correct only on troposphere (around 12km or so), and I > think some aircrafts we have can go higher than that. > > So I did some improvements on that function. At low altitudes it behaves > (almost) like the old one. It also has latitude dependency, and it > should behave quite well up to 85km. Of course, that is a bit overkill. You could have saved yourself a lot of work by posting a question before writing all this code. The code to do all this has existed for years. A nice table-driven implementation. It does this and more (notably linking the _pressure_ versus height dependence to the temperature). Pressure is kinda important for realistic altimetry, engine performance, et cetera. Let me know if you are interested in this. The code was never seriously considered for incorporation into the "official" version. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Atmosphere temperature model
Hi!
First of all I'd like to say hi to all as this is my first message to
this list! Hi :)
Then, when messing around with fg, I noticed that the current atmosphere
model is somewhat correct only on troposphere (around 12km or so), and I
think some aircrafts we have can go higher than that.
So I did some improvements on that function. At low altitudes it behaves
(almost) like the old one. It also has latitude dependency, and it
should behave quite well up to 85km. Of course, that is a bit overkill.
However, I have the patch attached, it was done againts the latest git
version with "git diff". I hope it is correctly done.
I also plotted some altitude-temperature curves at different latitudes
(0, 37 and 80 degrees). They can be seen here
http://users.tkk.fi/~lapelto2/fgfs_temperature.jpg . The source cites
some references I used so the accuracy could be examined.
Lauri
--
Lauri Peltonen
lauri.pelto...@gmail.com
diff --git a/src/Environment/environment.cxx b/src/Environment/environment.cxx
index dfb8824..7887fbb 100644
--- a/src/Environment/environment.cxx
+++ b/src/Environment/environment.cxx
@@ -38,7 +38,7 @@
#include "environment.hxx"
-
+
// Atmosphere model.
@@ -119,6 +119,7 @@ _setup_tables ()
void FGEnvironment::_init()
{
elevation_ft = 0;
+latitude_deg = 0;
visibility_m = 32000;
temperature_sea_level_degc = 15;
temperature_degc = 15;
@@ -160,6 +161,7 @@ void
FGEnvironment::copy (const FGEnvironment &env)
{
elevation_ft = env.elevation_ft;
+latitude_deg = env.latitude_deg;
visibility_m = env.visibility_m;
temperature_sea_level_degc = env.temperature_sea_level_degc;
temperature_degc = env.temperature_degc;
@@ -358,6 +360,12 @@ FGEnvironment::get_elevation_ft () const
return elevation_ft;
}
+double
+FGEnvironment::get_latitude_deg () const
+{
+ return latitude_deg;
+}
+
void
FGEnvironment::set_visibility_m (double v)
{
@@ -477,6 +485,20 @@ FGEnvironment::set_elevation_ft (double e)
}
void
+FGEnvironment::set_latitude_deg (double alt)
+{
+ latitude_deg = alt;
+
+ // Latitude affects temperature, so recalc everything
+ // that depends on temp
+ _recalc_alt_temperature();
+ _recalc_alt_dewpoint();
+ _recalc_alt_pressure();
+ _recalc_density();
+ _recalc_relative_humidity();
+}
+
+void
FGEnvironment::set_altitude_half_to_sun_m (double alt)
{
altitude_half_to_sun_m = alt;
@@ -540,7 +562,8 @@ void
FGEnvironment::_recalc_sl_temperature ()
{
// If we're in the stratosphere, leave sea-level temp alone
- if (elevation_ft < 38000) {
+ // (a little smaller to also work correctly at poles!)
+ if (elevation_ft < 28000) {
temperature_sea_level_degc = (temperature_degc + 273.15)
/ _temperature_degc_table->interpolate(elevation_ft)
- 273.15;
@@ -550,11 +573,84 @@ FGEnvironment::_recalc_sl_temperature ()
void
FGEnvironment::_recalc_alt_temperature ()
{
- if (elevation_ft < 38000) {
+ // This should calculate troposphere temperature
+ // quite accurately.
+ // In real life tropopause is different elevation in south and north
+ // but the difference is quite small.
+ // Info from: http://www.ux1.eiu.edu/~cfjps/1400/atmos_struct.html
+ // and: http://eospso.gsfc.nasa.gov/eos_homepage/for_scientists/data_products/OurChangingPlanet/PDF/Page_05_new.pdf
+
+ // take the absolute value of lat for simplicity
+ double lat = (latitude_deg < 0) ? -latitude_deg : latitude_deg;
+
+ // Using simple interpolation instead of the real curve
+ double tropopause = 51562; // Default tropopause at -30 < lat < 30
+ if(lat > 60) {
+tropopause = 31250 - 104.1 * (lat - 60);
+ } else if(lat > 30) {
+tropopause = 51562 - 677.1 * (lat - 30);
+ }
+
+ // This is quite good estimation for elevations below ~35000
+ // We need to calculate this for all elevations above this!
+ double e = elevation_ft;
+ if(e > tropopause) e = tropopause;
+
+ if(e <= 35000)
+ {
temperature_degc = (temperature_sea_level_degc + 273.15) *
-_temperature_degc_table->interpolate(elevation_ft) - 273.15;
- } else {
-temperature_degc = -56.49; // Stratosphere is constant
+ _temperature_degc_table->interpolate(e) - 273.15;
+ }
+ else
+ {
+// at equator tropopause is much higher than 35000 so new estimation :)
+// Using lapse rate of 6,5 degC / km
+// use the temp @ 35000 as a starting point
+temperature_degc = (temperature_sea_level_degc + 273.15) *
+ _temperature_degc_table->interpolate(35000) - 273.15 - 0.00208 * (e - 35000);
+ }
+
+ // At this point the temperature below tropopause is calculated :)
+ // Continue with upper levels
+
+ if(elevation_ft > tropopause)
+ {
+// tropopause is not really constant, so estimate different lapse rates
+double lapse_rate = 0.00053; // at equator
+double pause_top = 93750;
+
+if(l
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1
On jeudi 19 mars 2009, Melchior FRANZ wrote: > * gerard robin -- Thursday 19 March 2009: > > Then, do you mean that the old "Radar Fashion" will be removed, > > what a pity. > > I haven't planned that (yet). But in the long run it should get > removed. This was an early mechanism to get the brand-new AI > models on the screen (for the T38?), and that was OK back then, > and a nice new feature. But it's simple and unrealistic and just > doesn't fit in our framework. A radar needs to be a regular > instrument -- and the wxradar is just that. Or it should be some > customized Nasal logic like in the f-14b. New AI objects like > the tanker shouldn't have to generate absurd values to emulate > that obsolete radar. That would only prolong its lifetime. That's > inhuman. :-) > > But you can easily generate shift-x/shift-y etc. for the radar > you are actually using. Your aircraft knows which radar that is. > The tanker doesn't know that. It's like demanding that the tanker > decides whether your gear is extended or retracted. It just doesn't > know. > > > It is very useful. We could want to keep it . > > Did you have a look at the wxradar? You can check out the ufo. > Press Shift-p to enable the radar screen and Ctrl-c to see the > click-sensitive areas. Unfortunately, there are no button labels. > Clicking on the two range numbers increases/decreases the range. > You don't need any Nasal for that radar type, and you can select > radar shadows, symbols, and (once re-implemented) cloud shadows. > > m. I can only answer that i never had any problem with the actual AI/MP radar, it is very flexible , since the main required values x-shift, y-shift, in addition to the other useful aircraft data ( range-nm, altitude, heading ) are there. These data remain realistic. Any functions can be customized by the model maker according to specific requirements. Yes i tried to use the Vivian's wxradar , as far i remember it was implemented in the Blackbird. Anyhow, that is not a productive conversation with you, since i have "de facto" stopped to produce, and to update, any model within CVS. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1
* gerard robin -- Thursday 19 March 2009: > Then, do you mean that the old "Radar Fashion" will be removed, > what a pity. I haven't planned that (yet). But in the long run it should get removed. This was an early mechanism to get the brand-new AI models on the screen (for the T38?), and that was OK back then, and a nice new feature. But it's simple and unrealistic and just doesn't fit in our framework. A radar needs to be a regular instrument -- and the wxradar is just that. Or it should be some customized Nasal logic like in the f-14b. New AI objects like the tanker shouldn't have to generate absurd values to emulate that obsolete radar. That would only prolong its lifetime. That's inhuman. :-) But you can easily generate shift-x/shift-y etc. for the radar you are actually using. Your aircraft knows which radar that is. The tanker doesn't know that. It's like demanding that the tanker decides whether your gear is extended or retracted. It just doesn't know. > It is very useful. We could want to keep it . Did you have a look at the wxradar? You can check out the ufo. Press Shift-p to enable the radar screen and Ctrl-c to see the click-sensitive areas. Unfortunately, there are no button labels. Clicking on the two range numbers increases/decreases the range. You don't need any Nasal for that radar type, and you can select radar shadows, symbols, and (once re-implemented) cloud shadows. m. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1
On jeudi 19 mars 2009, Melchior FRANZ wrote: > * gerard robin -- Thursday 19 March 2009: > > With the usual AI tankers we have a lot of data regarding the Radar > > x-shift y-shift in-range , rotation, v-offset, .. and so on > > > > That tanker feature don't gives such information , it is missing , > > is it any valuable reason ? > > That's not exactly "missing". It's not provided on purpose. > > The Nasal tanker is a radar *target*. It gives enough hints for radar > implementations (be it the (wx)radar instrument or the f-14b's radar): > lat/lon/altitude/ktas/true-heading/bearing/elevation/range. > > But the tanker cannot decide whether it is in some radar's range, nor > where it should appear on a radar screen. This depends entirely on > the radar and is the radar's job, not the tanker's. How would the > tanker decide whether it is "in range"? In which range? > > The built-in AI radar is obsolete and should be phased out. > > m. > Then, do you mean that the old "Radar Fashion" will be removed, what a pity. It is very useful. We could want to keep it . -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] maketg and makefg scripts
On Thu, 19 Mar 2009 17:36:46 +0100, Geoff wrote in message <1237480606.6461.3.ca...@dell02>: > Hi Arnt, > > Please reduce the unnecessary 'size' of your emails. Sometimes > it takes many clicks to get to anything you MAY have added. > > Instead of adding _ALL_ that has been said, pick out a little > of the relevant context, if needed, like I do... ;=)) ..I'll try, this time too, I'm afraid I must file a motion to file an overlength reply. ;o) > > > > IT WILL NOT 'SEE' PLIB UNLESS YOU PATCH configure.ac as > > > detailed... > > ..ok, add a patches tree and PATCH-ALL and PATCH-* stanzas > > to your make*g-1.0.6's? ;o) > > Simple answer is NO! ;=)) I am expecting the patch to get > into the git terragear-cs sometime SOON - at least I HOPE > so... otherwise the current configure.ac will ONLY > support simgear, osg, plib installed into a 'standard' > path ;=(( > > So, NO, my scripts handle enough things already > without this type of HOPEFULLY TEMPORARY 'patch' addition... ..my idea is use the patch tree primarily for "local event Live-DVD etc releases" stuff, such as moving the default start-up from rwy...@ksfo in C172 C-FGFS to e.g. rw...@enzv in the sled behind Rudolf, and emergencies such as the TG configure.ac, and to test patches, not as a permanent fix to TG or FG. ..gnu patch also offers to remove or reverse "already applied patches", which is handy when patches get into the git etc trees, and to help debug your own git etc trees. ;o) > And concerning DOUPD, this should ONLY be used AFTER > the initial downloads and builds are done, when you > really MEAN that you want a FULL update of everything. ..this is no different from a fresh blank start with ./make*g and will produce exactly the same T|FG binaries as a "repeat" "./make*g DOUPD"? > That is _AFTER_ a full successful build, and some time has > passed. The scripts will always do the initial > download/checkout/clone WITHOUT it... ..ok. > In fact, they are meant to be run repeatedly WITHOUT any > parameters added. I do not even consider NOPAUSE a 'safe' ..no, but us messing around with it, will make it safer and a safe starting point for a release generator cron job. ;o) > option!!! You SHOULD always at least inspect the ./configure > step results, and abort if something is MISSING... ..yup, first step is make sure your make*g works for both Ubuntu and Debian, then flog some Fedora etc victims thru the same needle eye without trashing what we have working. > And ADDDEBUG will write the ./configure output to the LOG file, > for even more careful inspection... ..ah thanks, I got the idea this was meant to add debug stuff to the binary builds. ;o) > = > > > /opt/bygg/fg/simgear/source/simgear/timing/timestamp.cxx:79: > > > undefined reference to `clock_gettime' > > ..still happening with your makefg-1.0.5. > > Not when I run it ;=() ..??? Another dash|bash thing??? You use dash or bash right there as /bin/sh??? (On building FG in that part of makefg?) > I have NO IDEA why you get this error building fgfs. > Mine builds ok. You did not give enough output to know > exactly what was happening, but when linking fgfs, which > includes -lsgtiming, it also includes -lrt, which I think > is the library that contains this function. ..so we need my ./makefg ADDDEBUG logs. In my next FU here. > ~$ ls -l /lib/librt* > -rw-r--r-- 1 root root 35784 2008-09-12 16:15 /lib/librt-2.7.so > but not sure. ..I have: a45:~# ls -l /lib/librt* -rw-r--r-- 1 root root 30624 Feb 28 00:15 /lib/librt-2.9.so lrwxrwxrwx 1 root root12 Mar 2 01:21 /lib/librt.so.1 -> librt-2.9.so a45:~# > Is there a command to sort of 'dump' a > library to know what it exports? That is dump an ascii export > list, not a 'hex' dump, like xxd? ..if not hexdump, od, ldd, libtool, unstr or pkg-config, search ideas? I'm pretty sure you don't want typelib-dump nor bn_dump, and I fairly sure about rawshark too: a...@a45:~ $ man -k lib |grep dump bn_dump (3ssl) - BIGNUM library internal functions typelib-dump (1) - show ORBit2 type library modules a...@a45:~ $ man -k dump |grep lib bn_dump (3ssl) - BIGNUM library internal functions rawshark (1) - Dump and analyze raw libpcap data typelib-dump (1) - show ORBit2 type library modules a...@a45:~ $ man typelib-dump a...@a45:~ $ ..freeze (1) - dump a process into a self-executing file? Or gmxdump (1) - makes binary files human readable? _Amazing_ pile of er, non-junk on my test box. :o) > But anyway, this does not show anything wrong with my makefg > script that I can see... ..so we'll see what my ./makefg ADDDEBUG logs says. > = > > > lines, since I found that sometimes using one > > > LONG line of 'apt-get update a b c...' seemed to > > > MISS some packages in the list!!! Not sure why? > > ..could be related to whining about sudo apt-get install > > without (or before) chking whether those are necessary, > > try $basena
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1
* gerard robin -- Thursday 19 March 2009: > With the usual AI tankers we have a lot of data regarding the Radar > x-shift y-shift in-range , rotation, v-offset, .. and so on > > That tanker feature don't gives such information , it is missing , > is it any valuable reason ? That's not exactly "missing". It's not provided on purpose. The Nasal tanker is a radar *target*. It gives enough hints for radar implementations (be it the (wx)radar instrument or the f-14b's radar): lat/lon/altitude/ktas/true-heading/bearing/elevation/range. But the tanker cannot decide whether it is in some radar's range, nor where it should appear on a radar screen. This depends entirely on the radar and is the radar's job, not the tanker's. How would the tanker decide whether it is "in range"? In which range? The built-in AI radar is obsolete and should be phased out. m. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1
On lundi 16 mars 2009, Melchior FRANZ wrote:
> While we are at it, here some comments on tanker.nas:
>
> There's a menu entry AI/MP->Tanker, which opens a small dialog where
> you can request a tanker. It'll contact you and tell you something
> like this:
>
> "MOBIL3 at 15000, heading 130 with 250 knots, TACAN 062X"
>
> At the moment TACAN is always 062X, but that will vary in the future.
> The tanker will appear somewhere (not necessarily straight) ahead of
> you at an altitude of its choice. It will remove itself if it was out
> of range for a while. You can then ask for a new one.
>
> A similar script was presented a few months ago, but it had some
> issues that the authors never bothered to address ("take it or leave
> it"? :-), so I re-implemented it. This isn't finished either. There
> are some TODOs:
>
> - vary callsign & TACAN id
> - support more than just KC135 and KA6 tanker
> - support helicopter refueling (i.e. configurable airspeed)
> - fly refueling pattern(?)
> - avoid collisions with mountains
>
> m.
>
Again about that topic.
With the usual AI tankers we have a lot of data regarding the Radar , x-shift
y-shift in-range , rotation, v-offset, .. and so on
That tanker feature don't gives such information , it is missing , is it any
valuable reason ?
Thanks
--
Gérard
http://pagesperso-orange.fr/GRTux/
J'ai décidé d'être heureux parce que c'est bon pour la santé.
Voltaire
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] maketg and makefg scripts
Hi Arnt, Please reduce the unnecessary 'size' of your emails. Sometimes it takes many clicks to get to anything you MAY have added. Instead of adding _ALL_ that has been said, pick out a little of the relevant context, if needed, like I do... ;=)) > > IT WILL NOT 'SEE' PLIB UNLESS YOU PATCH configure.ac as > > detailed... > ..ok, add a patches tree and PATCH-ALL and PATCH-* stanzas > to your make*g-1.0.6's? ;o) Simple answer is NO! ;=)) I am expecting the patch to get into the git terragear-cs sometime SOON - at least I HOPE so... otherwise the current configure.ac will ONLY support simgear, osg, plib installed into a 'standard' path ;=(( So, NO, my scripts handle enough things already without this type of HOPEFULLY TEMPORARY 'patch' addition... And concerning DOUPD, this should ONLY be used AFTER the initial downloads and builds are done, when you really MEAN that you want a FULL update of everything. That is _AFTER_ a full successful build, and some time has passed. The scripts will always do the initial download/checkout/clone WITHOUT it... In fact, they are meant to be run repeatedly WITHOUT any parameters added. I do not even consider NOPAUSE a 'safe' option!!! You SHOULD always at least inspect the ./configure step results, and abort if something is MISSING... And ADDDEBUG will write the ./configure output to the LOG file, for even more careful inspection... = > > /opt/bygg/fg/simgear/source/simgear/timing/timestamp.cxx:79: > > undefined reference to `clock_gettime' > ..still happening with your makefg-1.0.5. Not when I run it ;=() I have NO IDEA why you get this error building fgfs. Mine builds ok. You did not give enough output to know exactly what was happening, but when linking fgfs, which includes -lsgtiming, it also includes -lrt, which I think is the library that contains this function. ~$ ls -l /lib/librt* -rw-r--r-- 1 root root 35784 2008-09-12 16:15 /lib/librt-2.7.so but not sure. Is there a command to sort of 'dump' a library to know what it exports? That is dump an ascii export list, not a 'hex' dump, like xxd? But anyway, this does not show anything wrong with my makefg script that I can see... = > > lines, since I found that sometimes using one > > LONG line of 'apt-get update a b c...' seemed to > > MISS some packages in the list!!! Not sure why? > ..could be related to whining about sudo apt-get install > without (or before) chking whether those are necessary, > try $basename --version style chks or dpkg -l |grep what > ever your scripts needs. Again NO, it is NOT! In all my tests, it just seems to 'miss' some things in a long list of things, and never 'complains' about repeated invocations. I do not always use NOPAUSE, and often READ the last outputs before continuing... the reason the 'waits' were put there in the first place! Yes, something like dpkg -l | grep would also do it, but that is even MORE scripting. Thus in a way, sudo apt-get install 'item' _IS_ a simple check that the 'item' exists... = > ..ln -s /bin/sh /bin/dash is standard Ubuntu practice? ~$ ls -l /bin/sh lrwxrwxrwx 1 root root 4 2008-08-16 17:27 /bin/sh -> dash Do not know if it is 'standard', but it is certainly done on my system. >From the list of TG executables, it seems you got these built. PHEW!!! Of course you are 'free' to install them where ever you like ;=)) just like you have done, amending INSTALL_DIR_TG= Now comes the 'hard' part, and that is building scenery using these tools... HAVE FUN ;=)) Regards, Geoff. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
On jeudi 19 mars 2009, gerard robin wrote: > On jeudi 19 mars 2009, gerard robin wrote: > > On jeudi 19 mars 2009, Mathias Fröhlich wrote: > > > Hi, > > > > > > Given this thread. > > > I have checked in the change to simgear. > > > I have also updated the default c172 and selectively those submodels > > > that I thought need some update. > > > And I have updated all the ac models in the AI and the Models > > > subdirectory. > > > > > > For the specific aircraft models, I do not want to just overwrite what > > > the author might have done on purpose but what was not yet honoured by > > > flightgear. > > > > > > So, if there are very dark models, the attached script to do the change > > > on the model level might be a good starting point for further > > > development. > > > > > > Greetings > > > > > > Mathias > > Again, with a remark, > > That last FG code makes contrast from light side to dark side very high . > It does not take in account the indirect light which give some light on > the dark side of an object. > > Most of the aircrafts are now black or white :( > Even with the noon time. > > Won't it be possible to reduce the contrast , or to give some indirect > enlightenment ? Hmmm, forget it , with modeling, we will only have to take in account that feature and probably to revisit the colors aspect. Many days or night to spend on it. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hypothetical gpl question
On Tue, 17 Mar 2009 06:28:26 -0700 (PDT), Gene wrote in message : > On Tue, 17 Mar 2009, Tim Moore wrote: > > > > > You don't have to provide sources with the binaries to comply with > > the GPL, you just have to make them available if the a recipient of > > the binary asks for them. In this case company "A" better have a > > plan in place for when an eventual paying customer ...or any other lawful recepient... > > asks for the > > source. I mean this in the sense that your business model shouldn't > > depend on keeping source code secret if you're using GPL'ed code. > > > > If it's been "distributed" once, doesn't that entitle _anyone_ to a > copy of the source code, reguardless of whether or not they got the > binary first? ..strictly speaking in the senseless litigation sense, no, ;o) they first need to receive the binary, but in any other sense, yes, AFAIK. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: source/src/Scripting NasalSys.cxx, 1.120, 1.121
* Frederic Bouvier -- Thursday 19 March 2009: > Support old compilers - if(argc < 2 or argc > 3) + if(argc < 2 || argc > 3) Argh ... sorry! That's a contamination from Nasal. I don't get why g++ doesn't turn this nonsense off by default. Won't happen again. m. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hypothetical gpl question
On Tue, 17 Mar 2009, Tim Moore wrote: > > You don't have to provide sources with the binaries to comply with the GPL, > you just have to make them available if the a recipient of the binary asks > for them. In this case company "A" better have a plan in place for when an > eventual paying customer asks for the source. I mean this in the sense that > your business model shouldn't depend on keeping source code secret if you're > using GPL'ed code. > If it's been "distributed" once, doesn't that entitle _anyone_ to a copy of the source code, reguardless of whether or not they got the binary first? g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. OpenQM - A Multi-Value database for the masses, not the classes. http://gpl.openqm.com - Get it _today_! -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
Hello, what does that mean in future for me as 3d-modeller? What I have to change when using Blender? Rgards HHS Hi, Given this thread. I have checked in the change to simgear. I have also updated the default c172 and selectively those submodels that I thought need some update. And I have updated all the ac models in the AI and the Models subdirectory. For the specific aircraft models, I do not want to just overwrite what the author might have done on purpose but what was not yet honoured by flightgear. So, if there are very dark models, the attached script to do the change on the model level might be a good starting point for further development. Greetings Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
On jeudi 19 mars 2009, gerard robin wrote: > On jeudi 19 mars 2009, Mathias Fröhlich wrote: > > Hi, > > > > Given this thread. > > I have checked in the change to simgear. > > I have also updated the default c172 and selectively those submodels that > > I thought need some update. > > And I have updated all the ac models in the AI and the Models > > subdirectory. > > > > For the specific aircraft models, I do not want to just overwrite what > > the author might have done on purpose but what was not yet honoured by > > flightgear. > > > > So, if there are very dark models, the attached script to do the change > > on the model level might be a good starting point for further > > development. > > > > Greetings > > > > Mathias > Again, with a remark, That last FG code makes contrast from light side to dark side very high . It does not take in account the indirect light which give some light on the dark side of an object. Most of the aircrafts are now black or white :( Even with the noon time. Won't it be possible to reduce the contrast , or to give some indirect enlightenment ? -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
On jeudi 19 mars 2009, Mathias Fröhlich wrote: > Hi, > > Given this thread. > I have checked in the change to simgear. > I have also updated the default c172 and selectively those submodels that I > thought need some update. > And I have updated all the ac models in the AI and the Models subdirectory. > > For the specific aircraft models, I do not want to just overwrite what the > author might have done on purpose but what was not yet honoured by > flightgear. > > So, if there are very dark models, the attached script to do the change on > the model level might be a good starting point for further development. > > Greetings > > Mathias Since i have not followed that topic may be a stupid question: will that animation longer working material controls/lighting/instruments-norm 0.60 0.30 0.20 1 1 1 1 1 1 0 0 0 4 I am using it, to light the instruments Thanks -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Major cleanup of xmlauto.[ch]xx
I just checked in the new code and new documentation README.digitalfilter in both, the data and the source tree. The code should be fully compatible to existing autopilot configurations but adds some new options: - supports tags - a missing element now means enabled for every filter - Almost all input values support , , and - may be used instead of as everywhere else in fg XML For details, check the README.digitalfilter Please report if anything is broken. Torsten -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/AI/Aircraft/Fokker-50/Models fokker50.ac, 1.1, 1.2
Mathias Fröhlich wrote: > Erik, > > On Thursday 19 March 2009 09:08:29 Erik Hofman wrote: >> To be honnest I don't like this action. I've always made sure all color >> settings were right in the modeller and did'nt adjust them to look nice >> in FlightGear in any way. Same goes for the F-16, T-37, T-38, Fokker >> 100, Fokker 70 and Fokker Dr.1 > Reverted on AI/Aircraft/Fokker-*. > Anyway, I miss the F-16, T37 and T38 in the AI directory? Do you mean the > 'main aircraft models instead??' > I can revert them too if I have found them. Correct, I didn't see them in de CVS messages but sometimes I get the changes in two batches, therefore I did include them in the shortlist. > Note that I did only change the AI models and the 'Geometry' stuff since I > have > found plenty of models that needed I conversion model by model. Ok, I missed the AI part in the path, but thanks for reverting them. Erik -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/AI/Aircraft/Fokker-50/Models fokker50.ac, 1.1, 1.2
Erik, On Thursday 19 March 2009 09:08:29 Erik Hofman wrote: > To be honnest I don't like this action. I've always made sure all color > settings were right in the modeller and did'nt adjust them to look nice > in FlightGear in any way. Same goes for the F-16, T-37, T-38, Fokker > 100, Fokker 70 and Fokker Dr.1 Reverted on AI/Aircraft/Fokker-*. Anyway, I miss the F-16, T37 and T38 in the AI directory? Do you mean the 'main aircraft models instead??' I can revert them too if I have found them. Note that I did only change the AI models and the 'Geometry' stuff since I have found plenty of models that needed I conversion model by model. The 'main' Aircraft models work is left to the original authors. Greetings Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
Hi, Given this thread. I have checked in the change to simgear. I have also updated the default c172 and selectively those submodels that I thought need some update. And I have updated all the ac models in the AI and the Models subdirectory. For the specific aircraft models, I do not want to just overwrite what the author might have done on purpose but what was not yet honoured by flightgear. So, if there are very dark models, the attached script to do the change on the model level might be a good starting point for further development. Greetings Mathias color-change.sh Description: application/shellscript -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/AI/Aircraft/Fokker-50/Models fokker50.ac, 1.1, 1.2
Mathias Froehlich wrote: > Update of /var/cvs/FlightGear-0.9/data/AI/Aircraft/Fokker-50/Models > In directory baron.flightgear.org:/tmp/cvs-serv2499/Aircraft/Fokker-50/Models > > Modified Files: > fokker50.ac > Log Message: > Set the ambient color equal to the rgb color. > This is what currently is done in flightgears model loading stage anyway. To be honnest I don't like this action. I've always made sure all color settings were right in the modeller and did'nt adjust them to look nice in FlightGear in any way. Same goes for the F-16, T-37, T-38, Fokker 100, Fokker 70 and Fokker Dr.1 To me this is a step too far and reading the conversation I was under the impression this wasn't to be done automatically. I do agree with the code change though. Erik -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
Hi Tim, On Tuesday 17 March 2009 19:58:02 Tim Moore wrote: > That needs to be handled in the shader program. The OpenGL fog parameters > are available as uniforms in shaders. Sure, but you need to rewrite that in every shader? Sure, that is the was OpenGL/OpenSceneGraph does this. > > How does this interact with the proposed changes of Robert Osfield to > > plug together shader programs from some fixed pipeine state attributes > > together with custom parts of the scenegraph user? > > Did you follow this discussion on osg-users? > > I have been following that. I think that work applies to a situation where > you don't have a fixed function pipeline anymore -- like in OpenGLES 2.0 > and OpenGL 3.x -- and want to keep OSG programs that use state sets > running. Eventually, as we use shaders more ourselves and want to run in > these new environments, we'll need to worry about being compatible, but for > now it's not an issue. Hmm, My impression was that OpenGL 3.0 was the starting point for that thoughts. But the consequences, that you can plug together your shaders from predefined components and replace only those components that need to be replaced is a critical thing for shader use. And this is currently a huge problem with OpenGL I think. >From my point of view, once shaders are in use, the fact that you have to replace the whole pipeline forces you to either: * reimplement all the same common stuff in each shader that is in use. Which is a maintainance nightmare if you want to change something here. * or reinvent such a shader component thing yourself which is a huge amount of work to get right. Both is not nice to do! Which one is your choice? So my impression was that Robert started thinking about something that makes such a component wise shader structure happen. So, all I think is that we should keep the eyes open to not end with something that we cannot handle in the longer term ... OTOH, I see that people want to make use of that nifty shader thing... Sure ... While OpenGL 3.0 started to move things into a direction that brakes compatibility, that comment on OpenGL 3.1 changing again an a non OpenGL whateverversion compatible way made me frighten ... So, I see very well, that this kind of changes need to happen, especially when you know how a gpu works and how bad the legacy OpenGL api is in terms of implementation and partly runtime complexity to map that api onto such a hardware. But *sigh* Greetings Mathias -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
