Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
From: "Arnt Karlsen" <[EMAIL PROTECTED]> > On Thu, 20 Mar 2003 21:36:13 -0500, > David Megginson <[EMAIL PROTECTED]> wrote in message > <[EMAIL PROTECTED]>: > > > Frederic Bouvier writes: > > > > > from my understanding : > > > > > > 360 degres = 44000km > > > 1 degre = 122.22km > > > 1 minute = 2.037km > > > 1 second = 0.033km > > > > Let's keep it simple. 1 minute of latitude is one nautical mile -- > > that's its definition. > > ..another simple old revolutionary definition of the length unit > meter, is it _used_ to be 40 000 000 of them around this planet, > now SI count light waves. ;-) You are right. I was just using the premises of the original poster (that is not quoted here) -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Screenshots: Curt's scenery improvements
Gene Buckle writes: > > > > Sorry for the lame question, but how far are the sample > points apart from > > > each other in feet with the 3 arc second data? How far is it > for the 1? > > > > 1 arcsec = approximately 30 meters = approximately 100 feet. > > 3 arcsec = approximately 90 meters = approximately 300 feet. > > > > The points are on the lat/lon grid lines so the horizontal spacing > > becomes smaller as you get further away from the equator. > > > > Thanks Curt. Is it possible to use 1 arcsec data for small areas? For > example, the Grand Canyon would look really cool with that kind of detail. It would be Cool but FGFS would crawl with our current scenery scheme Probably need a distance based chunked LOD scheme or something similar for this to work well But I think we should investigate using this around airports initialy where things are usually relatively flat. This should not add many triangles overall and should add a fair bit of fidelity to the placement of visual clues where they are most important Making the entire airport object an LOD object that swapped in a lowres model at ranges over a mile or so would make a nice addittion and be a good starting test case for LOD experiments. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
> > Sorry for the lame question, but how far are the sample points apart from > > each other in feet with the 3 arc second data? How far is it for the 1? > > 1 arcsec = approximately 30 meters = approximately 100 feet. > 3 arcsec = approximately 90 meters = approximately 300 feet. > > The points are on the lat/lon grid lines so the horizontal spacing > becomes smaller as you get further away from the equator. > Thanks Curt. Is it possible to use 1 arcsec data for small areas? For example, the Grand Canyon would look really cool with that kind of detail. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
On Thu, 20 Mar 2003 21:36:13 -0500, David Megginson <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Frederic Bouvier writes: > > > from my understanding : > > > > 360 degres = 44000km > > 1 degre = 122.22km > > 1 minute = 2.037km > > 1 second = 0.033km > > Let's keep it simple. 1 minute of latitude is one nautical mile -- > that's its definition. ..another simple old revolutionary definition of the length unit meter, is it _used_ to be 40 000 000 of them around this planet, now SI count light waves. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Architectural questions
Tony Peden writes: > The aero behavior. Coefficients are generally apply only to the whole > and complete aircraft (with the exception of a tail-off model). This > means its very hard to split them up arbitrarily. I agree that the information is harder to find, and will require a fair bit of tweaking. Then again, you might not have to worry so much about getting close, because a lot of the moments will fall naturally out of the geometry (i.e. a longer tail arm will automatically result in a higher Cnbeta for the aircraft as a whole). I'm pretty sure that Roskam's first book has a lot of information on estimating coefficients for different surfaces. DATCOM must also do that before generating the whole-aircraft coefficients. In any case, there's no reason that JSBSim cannot have the best of both worlds -- allow whole-aircraft coefficients or separate surfaces. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Frederic Bouvier writes: > from my understanding : > > 360 degres = 44000km > 1 degre = 122.22km > 1 minute = 2.037km > 1 second = 0.033km Let's keep it simple. 1 minute of latitude is one nautical mile -- that's its definition. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Drawing with OpenGL in Flightgear
On Thu, Mar 20, 2003 at 04:32:57PM -0800, Andy Ross wrote: > > If you want to draw into screen space, you'll need to push the > identity matrix onto the *projection* stack as well. Otherwise the > coordinates you are using will end up drawing a 1m x 1m square > parallel to the equatorial plane at the local tile origin. Probably > not what you had in mind. :) not really ;) thanks for your help - pushing the identity matrix onto the projection stack works great. regards, Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
On Thu, 20 Mar 2003, Gene Buckle wrote: > > I'm also pretty happy with the quality of the SRTM data. If/when 3 or > > 1 arcsec terrain data is released for the entire word, I'll need a 1 > > gazillion terrabyte HD to do all the processing and a 256 node super > > computer cluster also wouldn't hurt. :-) > > > flightgear.distributed.net. :) I'm experimenting with several machines in a mosix cluster at the moment - I'd be happy to make terragear the test app :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
On Thu, 20 Mar 2003, Curtis L. Olson wrote: > Here are some more pictures taken in and around the Bay area: > > http://www.flightgear.org/Gallery/Source/terrain1.jpg > http://www.flightgear.org/Gallery/Source/terrain2.jpg > http://www.flightgear.org/Gallery/Source/terrain3.jpg > http://www.flightgear.org/Gallery/Source/terrain4.jpg > http://www.flightgear.org/Gallery/Source/terrain5.jpg > http://www.flightgear.org/Gallery/Source/terrain6.jpg Wow, looks likt there's some real detail in there. What's the global coverage like for this data? The current UK DEM data is rather coarse, resulting in very flat terrain - I'm guessing there'll be huge improvements if the UK SRTM data has been released? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Still linker error in today's FlightGear
In my case, I don't want any of the multi-pilot code in my build. For some reason, as of yesterday, src/MultiPlayer is required for the build (--with-network is defaulted to yes). If it requires that I build with --with-network-olk then this is a very bad thing (IMHO) because I don't believe that code works on all platforms. At the very least, it would be nice if all the required switches were defaulted to the same values. Jonathan Polley On Thursday, March 20, 2003, at 11:26 PM, Martin Spott wrote: Hello Erik, Erik Hofman <[EMAIL PROTECTED]> wrote: Martin Spott wrote: Hello, today I encountered linker errors on SuSE-8.1/i386. As I understand this does not depend on the tool chain: Did you already try this: You will either have to do a "make clean" or remove the following files by hand: Oh, I'm no more a newbie in pushing other people's stuff through the compiler ;-) I even remade the whole build directory (including those of metakit, plib and SimGear). You can assume that I built everything from current CVS before reporting an error. Obviously some of the linker errors I posted result of missing references in the NetworkOLK stuff. Probably something resides outside the NetworkOLK directory and now it misses references because it does not get disabled at compile time like the rest of this stuff. I'll see what happens if I include NetworkOLK, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! --- --- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Architectural questions
On Thu, 2003-03-20 at 05:30, David Megginson wrote: > Tony Peden writes: > > > How would we specify the characteristics of each of those surfaces? > > Do you mean the position/orientation, the shape, or the aerodynamic > behaviour? The aero behavior. Coefficients are generally apply only to the whole and complete aircraft (with the exception of a tail-off model). This means its very hard to split them up arbitrarily. > > > All the best, > > > David -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Drawing with OpenGL in Flightgear
Richard Airlie wrote: > I am trying to draw an OpenGL quad at the very end of fgRenderFrame in > main.cxx, just before the glutSwapBuffers by doing: >glMatrixMode(GL_MODELVIEW); >glPushMatrix(); >glLoadIdentity(); > [...] > This has worked on a few occasions, but not all the time. If you want to draw into screen space, you'll need to push the identity matrix onto the *projection* stack as well. Otherwise the coordinates you are using will end up drawing a 1m x 1m square parallel to the equatorial plane at the local tile origin. Probably not what you had in mind. :) If what you really want to do is draw into 3D space, you should look at the panelnode.cxx class. This is the wrapper around the 2D panel code that maps it's internal "screen space" notion into the 3D world. You could probably clone or hook this to do what you want. Alternatively, it may be that what you want to do be handled already (no OpenGL required) by the existing panel framework. Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Hello Curt, "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > But, to answer your question CPU speed does definitely help. > Generally I'm never memory bound on a 256 machine except for the one > time task of splitting up the world land mass data set into > tiles... it would have been nice to have 1Gb RAM for that. I was not talking about donations. We've got this sort of machines floating around from time to time: fiwi: 1:04:40 ~> cat /proc/cpuinfo | grep ^processor processor : 0 processor : 1 fiwi: 1:04:49 ~> free | grep ^Mem Mem:903584 247236 656348 0 151944 46824 fiwi: 1:04:56 ~> df -k /home Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf /dev/evms/home 419678984561820 419117164 1% /home We have to do stress tests on these (with disk arrays up to 1 TB) and what would be better than doing _useful_ work for FlightGear instead of repeating GCC runs, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
> Hmmm, are you sure ? > > from my understanding : > > 360 degres = 44000km > 1 degre = 122.22km > 1 minute = 2.037km > 1 second = 0.033km That's what I just realized. I think it's bedtime. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Drawing with OpenGL in Flightgear
Hi all, I am trying to draw an OpenGL quad at the very end of fgRenderFrame in main.cxx, just before the glutSwapBuffers by doing: glMatrixMode(GL_MODELVIEW); glPushMatrix(); glLoadIdentity(); glDisable( GL_FOG ); glDisable( GL_DEPTH_TEST ); glDisable( GL_LIGHTING ); glDisable( GL_TEXTURE_2D ); glColor3f( 0.9, 0.4, 0.2 ); glBegin(GL_QUADS); glTexCoord2f(0,0); glVertex3f(0,0, 0); glTexCoord2f(1,0); glVertex3f(1,0, 0); glTexCoord2f(1,1); glVertex3f(1,1, 0); glTexCoord2f(0,1); glVertex3f(0,1, 0); glEnd(); glPopMatrix(); This has worked on a few occasions, but not all the time. What I really want is to be able to draw an overlay in 3D space at the end of the draw loop. I realise that Flightgear is using plib ssgnode rendering stuff, but I don't know plib and really only want to hack this in for now. How can I render some OpenGL prims at the end of the draw loop? many thanks, Richard. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
> 1 arcsec = approximately 30 meters = approximately 100 feet. > 3 arcsec = approximately 90 meters = approximately 300 feet. > > The points are on the lat/lon grid lines so the horizontal spacing > becomes smaller as you get further away from the equator. Ahhh, damn, I should have thought a little bit. Forget my previous post! Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
From: "Major A" <[EMAIL PROTECTED]> > > > Sorry for the lame question, but how far are the sample points apart from > > each other in feet with the 3 arc second data? How far is it for the 1? > > 24 arc hours = 44000km (roughly the perimeter of the earth) > 1 arc hour = 1833km > 1 arc minute = 30.55km > 1 arc second = 0.51km Hmmm, are you sure ? from my understanding : 360 degres = 44000km 1 degre = 122.22km 1 minute = 2.037km 1 second = 0.033km -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
> Sorry for the lame question, but how far are the sample points apart from > each other in feet with the 3 arc second data? How far is it for the 1? 24 arc hours = 44000km (roughly the perimeter of the earth) 1 arc hour = 1833km 1 arc minute = 30.55km 1 arc second = 0.51km So 1 arc second is about 510m, I'll leave the conversion to feet to the Americans on this list... Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Gene Buckle writes: > > After a bit of experimentation, I see little benefit in the 1arcsec > > data for our needs. We can't even come any where close to rendering > > the full 3arcsec data. We are talking about preserving the top 1% > > most important data points from the 3 arcsec data. For the 1arcsec > > data we'd only be able to preserve about 0.1% of the original data. > > So at the levels of detail we use, 3arcsec data is *more* than > > enough. Using 1arcsec data would still be nice, but probably not > > noticibly nicer. > > Sorry for the lame question, but how far are the sample points apart from > each other in feet with the 3 arc second data? How far is it for the 1? 1 arcsec = approximately 30 meters = approximately 100 feet. 3 arcsec = approximately 90 meters = approximately 300 feet. The points are on the lat/lon grid lines so the horizontal spacing becomes smaller as you get further away from the equator. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
> After a bit of experimentation, I see little benefit in the 1arcsec > data for our needs. We can't even come any where close to rendering > the full 3arcsec data. We are talking about preserving the top 1% > most important data points from the 3 arcsec data. For the 1arcsec > data we'd only be able to preserve about 0.1% of the original data. > So at the levels of detail we use, 3arcsec data is *more* than > enough. Using 1arcsec data would still be nice, but probably not > noticibly nicer. Sorry for the lame question, but how far are the sample points apart from each other in feet with the 3 arc second data? How far is it for the 1? tnx. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Still linker error in today's FlightGear
Hello Erik, Erik Hofman <[EMAIL PROTECTED]> wrote: > Martin Spott wrote: >> Hello, today I encountered linker errors on SuSE-8.1/i386. As I understand >> this does not depend on the tool chain: > Did you already try this: >> >> You will either have to do a "make clean" or remove the following files >> by hand: Oh, I'm no more a newbie in pushing other people's stuff through the compiler ;-) I even remade the whole build directory (including those of metakit, plib and SimGear). You can assume that I built everything from current CVS before reporting an error. Obviously some of the linker errors I posted result of missing references in the NetworkOLK stuff. Probably something resides outside the NetworkOLK directory and now it misses references because it does not get disabled at compile time like the rest of this stuff. I'll see what happens if I include NetworkOLK, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D HUD Support
Erik Hofman writes: > > Norman Vine wrote: > > Erik Hofman writes: > > > >>>1. 3D HUD code, written by Andy Ross and modified by Norman Vine. > >> > >>I realy like this patch, but it requires aircraft to be repositioned. As > >>far as I know only the F-16 doesn't use a full-screen HUD, but > >>I'm not sure. > >> > >>Does any object or can I go ahead? > > > > Please explain what it is you are planning todo ? > > I want to apply the 3D HUD patch which was originally written by Andy > Ross and later modified by you. I understand and I am all for it :-) In fact the Win32 binary users already have this. It is the 'requires aircraft tobe repositioned' is what I was unclear about Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Curtis L. Olson writes: > But, to answer your question CPU speed does definitely help. > Generally I'm never memory bound on a 256 machine except for the one > time task of splitting up the world land mass data set into > tiles... it would have been nice to have 1Gb RAM for that. Note that that's not necessary using the vmap0 data, since the world land mass is already split up into manageable chunks. The Great Lakes and major North American rivers are also in the right place with vmap0, but that's another discussion. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying in the UK
David wrote: > > I plan on doing a flight in the UK in summer as well, probably with a > > Tiger Moth. You can do this without any flying license. > >Really? In Canada, you need a license even for an ultralight or a >glider. I probably formulated that very badly - it is like the introductory flight lesson, you fly with a instructor and I am sure he will not let you start or land or fly down low. >All the best, > > >David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Still linker error in today's FlightGear
Erik Hofman <[EMAIL PROTECTED]> writes: > Martin Spott wrote: >> Hello, today I encountered linker errors on SuSE-8.1/i386. As I understand >> this does not depend on the tool chain: > > Did you already try this: > >> You will either have to do a "make clean" or remove the following >> files by hand: >> Cockpit/hud.o >> GUI/gui.o >> GUI/gui_funcs.o >> Main/main.o >> Main/options.o >> Main/util.o i see the same thing and i even made a distclean beforehand. anyway, looking at src/Include/config.h is see that both FG_MPLAYER_AS and FG_NETWORK_OLK are defined. shouldn't the new multiplayer mode disable the old network code? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Major A writes: > I've just checked, the central file space is 160GB, which is about 50% > full right now. It's shared via NFS, unfortunately, so it's not that > good really. They still have impressive computing power, I've just > checked that they have a 4x800MHz Itanium and a 4x1GHz Alpha. The > Itanium has 4GB of RAM, as many of the SMP systems they have. > > All in all, if it's really just copying data around, then it would be > best to do it on a PC with a lot of (local) disk space. From your > experience, what difference does CPU speed, the number of CPUs, and > the amount of RAM make? As someone else has said, disk space isn't > that expensive, and if we get a donation, you could set up a new > heater^H^H^H^H^H^HPC in your house with a 1TB RAID made of 4 IDE disks > or so. I appreciate the discussion of donations [to me] :-) but to be fair, right now things are ok. More hardware == faster, but things are ok/fine right now. Seriously, if you have a burning desire to make some sort of donation, please consider donating to someone who might be having trouble just getting enough food, or basic medical attention, or shelter. But, to answer your question CPU speed does definitely help. Generally I'm never memory bound on a 256 machine except for the one time task of splitting up the world land mass data set into tiles... it would have been nice to have 1Gb RAM for that. Even though there is a large data shuffling component, I have found significant advantages to clustering machines and running several tile builders at once, hanging off a single (fast) nfs server. I've never done any time measurements though to see how things scaled. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
On Thu, 20 Mar 2003 16:05:26 -0600, Cameron Moore <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > PPS - I forget the company, but there's a back-cover ad in the most > recent Linux Journals where you can enter to receive a $50K research > grant by applying in this company's contest. Long shot, but I thought > I'd mention it. ;-) ..http://microway.com/ -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
On Thu, 20 Mar 2003 15:34:24 -0600, "Curtis L. Olson" <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Major A writes: > > > Locally I have about 220Gb of HD space dedicated towards storing > > > the original raw data. The intermediate preprocessed form of the > > > data. The shared edge data. And the final scenery. > > > > Oh. I didn't expect it to be that much... > > I'm not maxed out yet, and occaisonally I keep different copies or > different variants of things for various reasons. I don't feel > cramped right now, but I'm not exactly swimming in an overwhelming > abundance of extra disk space. > > > > If we get SRTM data for the whole world, that will have to jump up > > > substantially. > > > > Can't things be done in sections? Why would one want to do the whole > > world in a single operation? > > Sure, but there's some sort of coolness factor related to building the > entire world. :-) > > > If processing involves a lot of data copying, you'd probably be > > better off keeping everything on a single computer. Use a > > multiprocessor machine with lots of storage and lots or RAM. > > If someone is donating hardware, I could live with either > approach. :-) > > > Just an idea: how about using the HP TestDrive farm? They have some > > nice computers there such as a quad 1GHz Alpha. It would be > > necessary to ask for their permission first, but this being an > > open-source project, I wouldn't think this would be a problem. We > > can then give credit on the website or so. > > What kind of disk space can they give us? > > Curt. ..they _can_ do a _lot_: http://www.serverworldmagazine.com/newsflash2/2003/03/20_redhat.shtml and http://news.google.com/news?hl=en&q=HP+%22Red+Hat%22 ..now, what they _will_ do, depends on their end of the deal etc, coolness is one factor in PR work, how about FG scenery building as a test suite, or sim'ing the shuttle break-up, we do ice on Twin Otters. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
> > Just an idea: how about using the HP TestDrive farm? They have some > > nice computers there such as a quad 1GHz Alpha. It would be > > necessary to ask for their permission first, but this being an > > open-source project, I wouldn't think this would be a problem. We > > can then give credit on the website or so. > > What kind of disk space can they give us? I've just checked, the central file space is 160GB, which is about 50% full right now. It's shared via NFS, unfortunately, so it's not that good really. They still have impressive computing power, I've just checked that they have a 4x800MHz Itanium and a 4x1GHz Alpha. The Itanium has 4GB of RAM, as many of the SMP systems they have. All in all, if it's really just copying data around, then it would be best to do it on a PC with a lot of (local) disk space. From your experience, what difference does CPU speed, the number of CPUs, and the amount of RAM make? As someone else has said, disk space isn't that expensive, and if we get a donation, you could set up a new heater^H^H^H^H^H^HPC in your house with a 1TB RAID made of 4 IDE disks or so. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Still linker error in today's FlightGear
Martin Spott wrote: Hello, today I encountered linker errors on SuSE-8.1/i386. As I understand this does not depend on the tool chain: Did you already try this: You will either have to do a "make clean" or remove the following files by hand: Cockpit/hud.o GUI/gui.o GUI/gui_funcs.o Main/main.o Main/options.o Main/util.o Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] for cvs
Ironhell3 . wrote:
ok, i am not sure if this is correct but this way compiles cvs version
of Flightgear
Shoot. You are right.
Funny I didn't catch that one.
Thanks.
Erik
--- src/Main/fg_init.cxx2003-03-20 14:33:11.0 +0200
+++ src/Main/fg_init.new.cxx2003-03-20 14:32:58.0 +0200
@@ -740,5 +740,5 @@
SG_LOG( SG_GENERAL, SG_INFO,
"Attempting to set starting position for "
-<< id << ":" << runway );
+<< id << ":" << rwy );
if ( ! runways.search( id, rwy, &r ) ) {
For any replies please CC me cause i am not on the list.I bieleve this
was just i typo?
[EMAIL PROTECTED]
Greece
http://www.angelfire.com/on3/ironhell3index/HellWorld.html
_
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
David Megginson writes: > Curtis L. Olson writes: > > > > In the meantime, there is 3 arcsec SRTM data for Canada and Mexico, so > > > we can join the club. > > > > Really? Where can I fetch it? > > The same place as the U.S. data: > > ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/North_America/3arcsec/ > > The 1 arcsec data covers only the U.S., but the 3 arcsec data covers > all of North America, as far as I can see. After a bit of experimentation, I see little benefit in the 1arcsec data for our needs. We can't even come any where close to rendering the full 3arcsec data. We are talking about preserving the top 1% most important data points from the 3 arcsec data. For the 1arcsec data we'd only be able to preserve about 0.1% of the original data. So at the levels of detail we use, 3arcsec data is *more* than enough. Using 1arcsec data would still be nice, but probably not noticibly nicer. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D HUD Support
Norman Vine wrote: Erik Hofman writes: 1. 3D HUD code, written by Andy Ross and modified by Norman Vine. I realy like this patch, but it requires aircraft to be repositioned. As far as I know only the F-16 doesn't use a full-screen HUD, but I'm not sure. Does any object or can I go ahead? Please explain what it is you are planning todo ? I want to apply the 3D HUD patch which was originally written by Andy Ross and later modified by you. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
* [EMAIL PROTECTED] (Curt Olson) [2003.03.20 14:40]: > Martin Spott writes: > > Gene Buckle <[EMAIL PROTECTED]> wrote: > > > flightgear.distributed.net. :) > > If someone provides a portable distribution mechanism for distributed > > scenery generation, then I think I can provide some horsepower for this, > > The big problem is that scenery building is much more slanted towards > data shuffling (i.e. reading and writing files is typically the > largest component of the task.) There is a computational component > but it is generally small in comparison. When you think about > distributing the tasks, the bottle necks are almost all in the file > loading and saving. > > Locally I have about 220Gb of HD space dedicated towards storing the > original raw data. The intermediate preprocessed form of the data. > The shared edge data. And the final scenery. > > If we get SRTM data for the whole world, that will have to jump up > substantially. > > For scenery building I'd love to have at least an 8-16 node cluster > with really high bandwidth/ low latency net between them, a terrabyte > of scsi disk space, and probably a big air conditioner to keep the > room cool. :-) (Seriously, when you start thinking about building > large clusters of PC's, you quickly get to the point where the largest > cost of the entire system is the cost of keeping it cool.) > > But, in the absence of winning the lottery, I have to live with > whatever hardware I can scrape together. :-) I agree. The operations are I/O bound, not CPU bound (kind of like a mail server), so a distributed.net-type application would probably prove less beneficial than we would hope. Many universities and research institutions are benefitting from FlightGear's progress. Having the ability to "out-source" much of the hard work of building a flight simulator, it seems like they could afford to donate a small amount of money to enable FlightGear to continue to grow ever-better. Having said that, I would be more apt to support a distributed funding campaign. PS - Speaking of "funding issues", did I see that Steve Baker landed an LGP programming job? PPS - I forget the company, but there's a back-cover ad in the most recent Linux Journals where you can enter to receive a $50K research grant by applying in this company's contest. Long shot, but I thought I'd mention it. ;-) -- Cameron Moore / If a person with multiple personalities threatens \ \ suicide, is that considered a hostage situation? / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenSG
Curtis L. Olson writes: > > Martin Spott writes: > > Has this project already be mentioned on this list ? Unfortunately it > > appears to compile with certain compilers only: > > > > http://www.opensg.org/ > In terms of fancy new whiz-bang cool features, OSG tends to try to > track and support them quickly FYI OpenSG is not OSG http://www.openscenegraph.org Both of which are aspiring to be quite different then PLIB and are both quite capable but keep in mind SSG = Simple Scene Graph Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying in the UK
Wolfram Kuss writes: > Excellent answers already! > > Dave, you did not say what you want to fly? Well, so far I have experience only in the C150, C172, C177, and PA-28. I wouldn't mind adding to that list, but I don't need to do that in the same trip. > I plan on doing a flight in the UK in summer as well, probably with a > Tiger Moth. You can do this without any flying license. Really? In Canada, you need a license even for an ultralight or a glider. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Major A writes: > > Locally I have about 220Gb of HD space dedicated towards storing the > > original raw data. The intermediate preprocessed form of the data. > > The shared edge data. And the final scenery. > > Oh. I didn't expect it to be that much... I'm not maxed out yet, and occaisonally I keep different copies or different variants of things for various reasons. I don't feel cramped right now, but I'm not exactly swimming in an overwhelming abundance of extra disk space. > > If we get SRTM data for the whole world, that will have to jump up > > substantially. > > Can't things be done in sections? Why would one want to do the whole > world in a single operation? Sure, but there's some sort of coolness factor related to building the entire world. :-) > If processing involves a lot of data copying, you'd probably be better > off keeping everything on a single computer. Use a multiprocessor > machine with lots of storage and lots or RAM. If someone is donating hardware, I could live with either approach. :-) > Just an idea: how about using the HP TestDrive farm? They have some > nice computers there such as a quad 1GHz Alpha. It would be > necessary to ask for their permission first, but this being an > open-source project, I wouldn't think this would be a problem. We > can then give credit on the website or so. What kind of disk space can they give us? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Still linker error in today's FlightGear
Hello, today I encountered linker errors on SuSE-8.1/i386. As I understand this does not depend on the tool chain: make[2]: Wechsel in das Verzeichnis »/usr/local/src/FlightGear/src/Main« g++ -DPKGLIBDIR=\"/usr/local/FlightGear/lib/FlightGear\" -O3 -D_REENTRANT -L/usr/local/lib -L/opt/gnu/lib -s -L/usr/local/FlightGear/lib -L/usr/X11R6/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o logger.o options.o splash.o util.o viewer.o viewmgr.o location.o ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/Objects/libObjects.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lsgthreads -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lplibpsl -lmk4 -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lpthread -lm -lplibsl -lplibsm -ljpeg -lm main.o: In function `fgRenderFrame()': main.o(.text+0xef5): undefined reference to `head' main.o(.text+0xf01): undefined reference to `tail' main.o(.text+0xf08): undefined reference to `other' main.o(.text+0xf24): undefined reference to `fgd_mcp_ip' main.o(.text+0xf2a): undefined reference to `other' main.o(.text+0xf3c): undefined reference to `other' main.o(.text+0xf7a): undefined reference to `other' main.o(.text+0xf8d): undefined reference to `other' main.o(.text+0xfae): undefined reference to `tail' main.o(.text+0xfb3): undefined reference to `other' main.o(.text+0xfc0): undefined reference to `other' main.o: In function `fgMainInit(int, char**)': main.o(.text+0x48b4): undefined reference to `fg_net_init(ssgRoot*)' main.o: In function `fgMainLoop()': main.o(.text+0x57fc): undefined reference to `net_is_registered' main.o(.text+0x5fe5): undefined reference to `FGFS_host' main.o(.text+0x5ff0): undefined reference to `fgd_send_com(char*, char*)' main.o(.text+0x5ff7): undefined reference to `FGFS_host' main.o(.text+0x6002): undefined reference to `fgd_send_com(char*, char*)' options.o: In function `fgOptNetHud(char const*)': options.o(.text+0x1fe4): undefined reference to `net_hud_display' util.o: In function `fgExit(int)': util.o(.text+0x168): undefined reference to `FGFS_host' util.o(.text+0x173): undefined reference to `fgd_send_com(char*, char*)' ../../src/Cockpit/libCockpit.a(hud.o): In function `fgUpdateHUD(float, float, float, float)': hud.o(.text+0x20cf): undefined reference to `net_hud_display' hud.o(.text+0x2541): undefined reference to `net_hud_update()' ../../src/GUI/libGUI.a(gui.o): In function `guiInit()': gui.o(.text+0x2e7): undefined reference to `NewNetIdInit()' gui.o(.text+0x2ec): undefined reference to `NewNetFGDInit()' ../../src/GUI/libGUI.a(gui_funcs.o): In function `net_display_toggle(puObject*)': gui_funcs.o(.text+0x1c07): undefined reference to `net_hud_display' gui_funcs.o(.text+0x1c1e): undefined reference to `net_hud_display' ../../src/GUI/libGUI.a(gui_funcs.o): In function `net_register(puObject*)': gui_funcs.o(.text+0x1c37): undefined reference to `FGFS_host' gui_funcs.o(.text+0x1c42): undefined reference to `fgd_send_com(char*, char*)' gui_funcs.o(.text+0x1c48): undefined reference to `net_is_registered' ../../src/GUI/libGUI.a(gui_funcs.o): In function `net_unregister(puObject*)': gui_funcs.o(.text+0x1c77): undefined reference to `FGFS_host' gui_funcs.o(.text+0x1c82): undefined reference to `fgd_send_com(char*, char*)' gui_funcs.o(.text+0x1c88): undefined reference to `net_is_registered' ../../src/GUI/libGUI.a(gui_funcs.o): In function `goodBye(puObject*)': gui_funcs.o(.text+0x27cc): undefined reference to `net_is_registered' gui_funcs.o(.text+0x27d8): undefined reference to `FGFS_host' gui_funcs.o(.text+0x27e3): undefined reference to `fgd_send_com(char*, char*)' ../../src/GUI/libGUI.a(gui_funcs.o)(.rodata+0x94): undefined reference to `NewCallSign(puObject*)' ../../src/GUI/libGUI.a(gui_funcs.o)(.rodata+0x9c): undefined reference to `net_fgd_scan(puObject*)' collect2: ld returned 1 exit status make[2]: *** [fgfs] Fehler 1 make[2]: Verlassen des Verzeichnisses »/usr/lo
Re: [Flightgear-devel] OpenSG
Martin Spott writes: > Has this project already be mentioned on this list ? Unfortunately it > appears to compile with certain compilers only: > > http://www.opensg.org/ I can't say if it's been mentioned here or not, but I'm aware of it. If people are starting new projects from scratch it definitely bears consideration, plib is not the only game in town. Here's what I hear through the grape vine. In terms of fancy new whiz-bang cool features, OSG tends to try to track and support them quickly. However, they suffer from an API that changes quite often or without warning, making it harder or more work to support a longer term application that uses OSG. I've heard that their file readers and writers are on par (for good or for bad) with Plib's. This project started out as an sgi performer clone, so it matches performer bloat for bloat and complexity for complexity. It also suffers from a severe lack of documentation. Plib/ssg has a much more stable api, but also develops new features more slowly. It doesn't support a lot of the latest/greatest card tricks, but it does have call backs and the ability to derive new classes, so a motivated person can accomplish the same things if they want to dig in and figure the details out themselves. Plib/ssg is very well documented, especially compared to the average open source project. Plib/ssg is lean, mean, and fast. FlightGear is still commited to plib/ssg, and knowing what I know, I'd probably stick with plib/ssg even if there was no cost in switching to something else. However, people starting new projects should take a good look at OSG as well as plib, OSG just might offer exactly what you need. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer
> > I don't know that network-olk ever really worked, so if this new > multiplayer code has any sort of basic functionality we could probably > just remove the olk code. If any one needs it for anything, it will > always be available in past versions. > > Regards, > > Curt. We actually did manage to get the OLK code working under Linux. It required a few changes as it was seg-faulting. The OLK code is a serious frame rate killer though. Every frame it opens a TCP socket to the server, sends its position, then closes the socket. It then opens another socket to the server, requests all the other aircrafts positions and closes again. Feel free to browse and comment on our new multiplayer implementation. Since it is UDP it is a much lower performance hit. As it is integrated into the IO subsystem, you can specify the rate the protocol runs at to further tweak performance. We typically run 10 - 30 Hz on our Tower sim prototype. The code and some documentation are on my website. http://tysonfamily.net/flightgear If you have any problems Duncan and I both lurk on the list and should be able to help. Cheers, Diarmuid Tyson ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
> Locally I have about 220Gb of HD space dedicated towards storing the > original raw data. The intermediate preprocessed form of the data. > The shared edge data. And the final scenery. Oh. I didn't expect it to be that much... > If we get SRTM data for the whole world, that will have to jump up > substantially. Can't things be done in sections? Why would one want to do the whole world in a single operation? > For scenery building I'd love to have at least an 8-16 node cluster > with really high bandwidth/ low latency net between them, a terrabyte If processing involves a lot of data copying, you'd probably be better off keeping everything on a single computer. Use a multiprocessor machine with lots of storage and lots or RAM. Just an idea: how about using the HP TestDrive farm? They have some nice computers there such as a quad 1GHz Alpha. It would be necessary to ask for their permission first, but this being an open-source project, I wouldn't think this would be a problem. We can then give credit on the website or so. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
"Curtis L. Olson" <[EMAIL PROTECTED]> said: > The big problem is that scenery building is much more slanted towards > data shuffling (i.e. reading and writing files is typically the > largest component of the task.) There is a computational component > but it is generally small in comparison. When you think about > distributing the tasks, the bottle necks are almost all in the file > loading and saving. > > Locally I have about 220Gb of HD space dedicated towards storing the > original raw data. The intermediate preprocessed form of the data. > The shared edge data. And the final scenery. > That's a lot of space, but I guess it won't be long before we see a single 1tb drive. It is amazing how fast drives are now. Usually when I run these kind of jobs I forget what a difference it makes to use different channels, dma, etc. Fortunately they are usually one shot deals and it doesn't matter. But now that I'm looking at burning some vids on dvds...it's going to become more regular. If there were easy scripts all set up it seems like people who were interested could grab a 10x10 square at a time and send back the result. Might need a way to "check out" a section so that others don't duplicate. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > For scenery building I'd love to have at least an 8-16 node cluster > with really high bandwidth/ low latency net between them, a terrabyte > of scsi disk space, [...] A terabyte of disk space is quite affordable these days. When the necessity becomes real, then we should talk about it. I'd love to use my customer's park of Sun servers, but I don't think they'd allow for that ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] for cvs
ok, i am not sure if this is correct but this way compiles cvs version of
Flightgear
--- src/Main/fg_init.cxx2003-03-20 14:33:11.0 +0200
+++ src/Main/fg_init.new.cxx2003-03-20 14:32:58.0 +0200
@@ -740,5 +740,5 @@
SG_LOG( SG_GENERAL, SG_INFO,
"Attempting to set starting position for "
-<< id << ":" << runway );
+<< id << ":" << rwy );
if ( ! runways.search( id, rwy, &r ) ) {
For any replies please CC me cause i am not on the list.I bieleve this was
just i typo?
[EMAIL PROTECTED]
Greece
http://www.angelfire.com/on3/ironhell3index/HellWorld.html
_
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Martin Spott writes: > Gene Buckle <[EMAIL PROTECTED]> wrote: > > > flightgear.distributed.net. :) > > If someone provides a portable distribution mechanism for distributed > scenery generation, then I think I can provide some horsepower for this, The big problem is that scenery building is much more slanted towards data shuffling (i.e. reading and writing files is typically the largest component of the task.) There is a computational component but it is generally small in comparison. When you think about distributing the tasks, the bottle necks are almost all in the file loading and saving. Locally I have about 220Gb of HD space dedicated towards storing the original raw data. The intermediate preprocessed form of the data. The shared edge data. And the final scenery. If we get SRTM data for the whole world, that will have to jump up substantially. For scenery building I'd love to have at least an 8-16 node cluster with really high bandwidth/ low latency net between them, a terrabyte of scsi disk space, and probably a big air conditioner to keep the room cool. :-) (Seriously, when you start thinking about building large clusters of PC's, you quickly get to the point where the largest cost of the entire system is the cost of keeping it cool.) But, in the absence of winning the lottery, I have to live with whatever hardware I can scrape together. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OpenSG
Has this project already be mentioned on this list ? Unfortunately it appears to compile with certain compilers only: http://www.opensg.org/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying in the UK
Excellent answers already! Dave, you did not say what you want to fly? I plan on doing a flight in the UK in summer as well, probably with a Tiger Moth. You can do this without any flying license. If you search for "Tiger Moth" and lesson or similar words, you will find several operators offering this. Does anyone have experience with them? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > I'm also pretty happy with the quality of the SRTM data. If/when 3 or > 1 arcsec terrain data is released for the entire word, I'll need a 1 > gazillion terrabyte HD to do all the processing and a 256 node super > computer cluster also wouldn't hurt. :-) When the time has come that 1 arcsec terrain data is released for the entire world for free, then we'll be able to afford this hardware from the petty cash ;-) The Europeans think a bit different about cost recovery for aquisition of geo data :-/ Will we see landcover information from the VMap0 data on the 'new' scenery ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Gene Buckle <[EMAIL PROTECTED]> wrote: > flightgear.distributed.net. :) If someone provides a portable distribution mechanism for distributed scenery generation, then I think I can provide some horsepower for this, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Curtis L. Olson writes: > > In the meantime, there is 3 arcsec SRTM data for Canada and Mexico, so > > we can join the club. > > Really? Where can I fetch it? The same place as the U.S. data: ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/North_America/3arcsec/ The 1 arcsec data covers only the U.S., but the 3 arcsec data covers all of North America, as far as I can see. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments
On Thu, 20 Mar 2003 12:14:19 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: I just want to make a very brief statement with respect to what going on in the world right now. That wasn't brief. ;-) Was this in reponse to anything in particular, or a preemptive strike to head off any political (and potentially disturbing) arguments? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Curt, this is awesome. > I'm also pretty happy with the quality of the SRTM data. If/when 3 or > 1 arcsec terrain data is released for the entire word, I'll need a 1 > gazillion terrabyte HD to do all the processing and a 256 node super > computer cluster also wouldn't hurt. :-) I might be able to help, having access to a cluster of Alphas. I could do at least part of the job, so please let me know if you have more data. (It would probably be best to advertise it on this list so that people with an unused supercomputer under their bed can help.) Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
David Megginson writes: > In the meantime, there is 3 arcsec SRTM data for Canada and Mexico, so > we can join the club. Really? Where can I fetch it? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
> I'm also pretty happy with the quality of the SRTM data. If/when 3 or > 1 arcsec terrain data is released for the entire word, I'll need a 1 > gazillion terrabyte HD to do all the processing and a 256 node super > computer cluster also wouldn't hurt. :-) > flightgear.distributed.net. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Curtis L. Olson writes: > I'm also pretty happy with the quality of the SRTM data. If/when 3 or > 1 arcsec terrain data is released for the entire word, I'll need a 1 > gazillion terrabyte HD to do all the processing and a 256 node super > computer cluster also wouldn't hurt. :-) In the meantime, there is 3 arcsec SRTM data for Canada and Mexico, so we can join the club. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Jim Wilson writes: > This looks great! Is the bay area ready for the base package yet? There are a couple open issues. 1. I'm using the 1km raster land use/land cover data set rather than vmap0 land use. 2. I have yet built in roads, railroads, or streams. 3. There are some tile boundary issues that have crept into the code that need to be looked at. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Comments
I just want to make a very brief statement with respect to what going on in the world right now. I don't think we should trivialize current world events here in the FlightGear forums by pretending they aren't happening. I'm certain that most of us have strong feelings and are very concerned about what is going on. However, our mailing lists are intended for discussing FlightGear development and usage, and there are many other much more appropriate forums for discussing world events. I think we all would acknowledge that collectively we are very concerned right now. We are a large group with a large diversity of opinions; but we have all come together on a single point, on which I believe we all can agree: we want to make FlightGear the best it can be. So please, let's stay focused on FlightGear here in the FlightGear forums. Let's continue to keep our collaboration positive and as reasonably on track as it usually is. Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
This looks great! Is the bay area ready for the base package yet? Best, Jim "Curtis L. Olson" <[EMAIL PROTECTED]> said: > Thanks for the kind words. Yes there is a few rough edges (so to > speak.) I see at least one bug in tile edge matching has crept in > along the way somehow. I need to look into that, but overall I'm > becoming really happy with the SRTM data and the new terrain fitting > approach which Norman Vine pointed me towards. > > Here are some more pictures taken in and around the Bay area: > > http://www.flightgear.org/Gallery/Source/terrain1.jpg > http://www.flightgear.org/Gallery/Source/terrain2.jpg > http://www.flightgear.org/Gallery/Source/terrain3.jpg > http://www.flightgear.org/Gallery/Source/terrain4.jpg > http://www.flightgear.org/Gallery/Source/terrain5.jpg > http://www.flightgear.org/Gallery/Source/terrain6.jpg > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Screenshots: Curt's scenery improvements
David Megginson writes: > > The new scenery code is still rough, and some tiles fail to build at > all, but I am extremely impressed with Curt's recent work on TerraGear > combined with the better Canadian elevation data available through the > SRTM. Yup Open Source 'collaboration' yields wonders http://seneca.me.umn.edu/pipermail/terragear-devel/2003-March/000423.html Nice work Curt ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
David Megginson writes: > The new scenery code is still rough, and some tiles fail to build at > all, but I am extremely impressed with Curt's recent work on TerraGear > combined with the better Canadian elevation data available through the > SRTM. David, Thanks for the kind words. Yes there is a few rough edges (so to speak.) I see at least one bug in tile edge matching has crept in along the way somehow. I need to look into that, but overall I'm becoming really happy with the SRTM data and the new terrain fitting approach which Norman Vine pointed me towards. Here are some more pictures taken in and around the Bay area: http://www.flightgear.org/Gallery/Source/terrain1.jpg http://www.flightgear.org/Gallery/Source/terrain2.jpg http://www.flightgear.org/Gallery/Source/terrain3.jpg http://www.flightgear.org/Gallery/Source/terrain4.jpg http://www.flightgear.org/Gallery/Source/terrain5.jpg http://www.flightgear.org/Gallery/Source/terrain6.jpg Here are a few things I've noticed with the new terrain fitting algorithm: - The concentration of elevation points in the final result seems a lot better balanced. - Major features such as ridges and valleys are much better represented. - It seems like we are achieving much better detail with the same or similar number of polygons. I'm also pretty happy with the quality of the SRTM data. If/when 3 or 1 arcsec terrain data is released for the entire word, I'll need a 1 gazillion terrabyte HD to do all the processing and a 256 node super computer cluster also wouldn't hurt. :-) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Screenshots: Curt's scenery improvements
The new scenery code is still rough, and some tiles fail to build at all, but I am extremely impressed with Curt's recent work on TerraGear combined with the better Canadian elevation data available through the SRTM. Here is a picture taken from the surface of the Gatineau River just north of Ottawa, using the old scenery built with the 30 arcsec DEMs: http://www.megginson.com/flightsim/old-scenery.png Here is the same picture using scenery generated from the SRTM 3 arcsec elevation data *and* Curt's improvements in surface triangulation: http://www.megginson.com/flightsim/new-scenery.png The higher-resolution SRTM helped, of course, but the scenery still looked much flatter than this until I used Curt's arrayfit tool to preprocess the elevation arrays generated from the SRTM. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D HUD Support
Erik Hofman writes: > > > 1. 3D HUD code, written by Andy Ross and modified by Norman Vine. > > I realy like this patch, but it requires aircraft to be repositioned. As > far as I know only the F-16 doesn't use a full-screen HUD, but > I'm not sure. > > Does any object or can I go ahead? Please explain what it is you are planning todo ? Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3D HUD Support
Erik Hofman wrote: 1. 3D HUD code, written by Andy Ross and modified by Norman Vine. I realy like this patch, but it requires aircraft to be repositioned. As far as I know only the F-16 doesn't use a full-screen HUD, but I'm not sure. Does any object or can I go ahead? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] FGControls
David Culp writes: > I need to at least 31 control nodes in FGControls in order to > handle turbines, and I see that it already contains 72 nodes. I > can see the number growing to 200 or more. It might be time to > organize with sub-nodes: > > /controls/flight > /controls/gear > /controls/engine > /controls/engine/piston > /controls/engine/turbine > /controls/engine/rocket > /controls/propeller > /controls/electrical > /controls/hydraulic > /controls/anti-ice > /controls/pneumatics > /controls/pressurization > ...etc > > This would break a lot of the present code, so it will need some > discussion. I think we need to make some changes anyway, especially so that we can simulate control failures. For example, right now we have /controls/mixture[0] /controls/mixture[1] /controls/mixture[2] /controls/propeller-pitch[0] /controls/propeller-pitch[1] /controls/propeller-pitch[2] /controls/throttle[0] /controls/throttle[1] /controls/throttle[2] and so on. As David suggests, we could regroup those in several different ways: /controls/engine[0]/mixture /controls/engine[0]/propeller-pitch /controls/engine[0]/throttle /controls/engine[1]/mixture /controls/engine[1]/propeller-pitch /controls/engine[1]/throttle /controls/engine[2]/mixture /controls/engine[2]/propeller-pitch /controls/engine[2]/throttle or even /controls/engines/engine[0]/mixture (which would give an uncluttered view in /controls). Whatever we choose, I think that we need to break down the top level as well, so that we have [..]/throttle/setting-norm [..]/throttle/serviceable and possibly others. This way, we can introduce control failures the same way we introduce system and instrument failures. Deciding how long to make the paths is always difficult because of the tradeoffs between typing and browsing. For the typists, it's best to keep the tree as flat as possible; for the browsers, it's best to keep the tree nodes as uncluttered as possible. Those two goals are mutually exclusive. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FGControls
I need to at least 31 control nodes in FGControls in order to handle turbines, and I see that it already contains 72 nodes. I can see the number growing to 200 or more. It might be time to organize with sub-nodes: /controls/flight /controls/gear /controls/engine /controls/engine/piston /controls/engine/turbine /controls/engine/rocket /controls/propeller /controls/electrical /controls/hydraulic /controls/anti-ice /controls/pneumatics /controls/pressurization ...etc This would break a lot of the present code, so it will need some discussion. Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Architectural questions
Jon Berndt writes: > There are some nuances to that approach. For example, does it work *with* > the existing approach, or would it be an entirely new and separate way to > define the aero characteristics of an aircraft? If it was to augment the > current way of doing things, would it provide any aero force or moment > that was *already* provided by another set of coefficients? We would not > want to duplicate aero coefficients anywhere. Treat the current config files as vehicles with a single pseudo-lifting surface, and you should be able to use the same code for both approaches. Gotchas include figuring out mass distribution and the effect of disturbed airflow from the props and wings, especially on the effective alpha and beta of the tail section. > Initially, I think the piecewise approach would be to augment the > full-coefficient approach. For instance, the wing could be broken up into > at least a couple 2 or 3 spanwise segments per side. Each would have its > own portion of the total area assigned to it. Each would have its own > alpha and velocity vector (and perhaps each would bias its own velocity > vector as in the case of a wing with twist towards the tip). This single > case is probably most worthwhile to model in a piecewise method, and the > benefits seem apparent right off the bat. If propeller swirl modeling is > included with this, stall and spin characteristics would be vastly > improved. YASim does this internally, but doesn't require the use to specify things that way -- instead, the user provides the incidence angle and twist (for washout), tapering, etc., and YASim calculates the segments automatically. > However, in the above approach, there would perhaps be a component > of roll damping that would then be modeled by this piecewise > approach. So, would we remove the Clp (roll damping) coefficient? I think that most of the moment coefficients would be redundant when you chose to model an aircraft his way. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Architectural questions
Tony Peden writes: > How would we specify the characteristics of each of those surfaces? Do you mean the position/orientation, the shape, or the aerodynamic behaviour? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer update
Duncan McCreanor wrote: I am working an update to the multiplayer code. The changes are to tidy up the loading/unloading of models as players come and go, as well as some other minor corrections. I will post the changes within the next couple of days. Good to see there is still active development of the code! The patches are welcome Duncan. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer update
I am working an update to the multiplayer code. The changes are to tidy up the loading/unloading of models as players come and go, as well as some other minor corrections. I will post the changes within the next couple of days. Duncan McCreanor. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
Gerhard Wesp wrote: http://flightgear.org/Projects/RayChair/raychair.html http://flightgear.org/Projects/ Oops. Should have looked more closely on your homepage. Thanks! This is actually the first time I've looked at this video, but it is quite nice to see FlightGear in action this way: http://members.cox.net/rwcobra/BobPMFS-Short.ram Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Architectural questions
> Note that JSBSim would get all of this for free simply by allowing > coefficients to be (optionally) specified for individual surfaces, > each with its own orientation. All JSBSim would have to do is sum up > the moments and forces (mostly forces) for the collection of surfaces. I think we all agree on this and I'll go on record as saying that we will do this. Hopefully sooner rather than later. I want to chew on it for a little while longer, and hear Tony's impressions on how it should or should not be implemented, and then provide access to that approach (i.e. implement it). There are some nuances to that approach. For example, does it work *with* the existing approach, or would it be an entirely new and separate way to define the aero characteristics of an aircraft? If it was to augment the current way of doing things, would it provide any aero force or moment that was *already* provided by another set of coefficients? We would not want to duplicate aero coefficients anywhere. Initially, I think the piecewise approach would be to augment the full-coefficient approach. For instance, the wing could be broken up into at least a couple 2 or 3 spanwise segments per side. Each would have its own portion of the total area assigned to it. Each would have its own alpha and velocity vector (and perhaps each would bias its own velocity vector as in the case of a wing with twist towards the tip). This single case is probably most worthwhile to model in a piecewise method, and the benefits seem apparent right off the bat. If propeller swirl modeling is included with this, stall and spin characteristics would be vastly improved. However, in the above approach, there would perhaps be a component of roll damping that would then be modeled by this piecewise approach. So, would we remove the Clp (roll damping) coefficient? The H.tail and rudder might also provide some roll damping, but removing the coefficient approach in favor of the piecewise approach would result in an insufficient modeling. It's a tradeoff. I still think that, with care, the piecewise approach could nicely augment our current approach. Perhaps the piecewise approach would be blended in only in particular regimes. Jon smime.p7s Description: S/MIME cryptographic signature
RE: [Flightgear-devel] Architectural questions
On Thu, 2003-03-20 at 04:35, David Megginson wrote: > Jon Berndt writes: > > > I can think of a couple of situations where YASim would have advantages - > > *at*present*: > > > > - Calculating any force or moment that is a result of rotational motion > > while the aircraft is at zero translational velocity. > > > > - Clearly, any condition that is not covered by full aerodynamic > > coefficients. > > Note that JSBSim would get all of this for free simply by allowing > coefficients to be (optionally) specified for individual surfaces, > each with its own orientation. All JSBSim would have to do is sum up > the moments and forces (mostly forces) for the collection of surfaces. How would we specify the characteristics of each of those surfaces? > > > All the best, > > > David -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
On Thu, 2003-03-20 at 03:22, David Megginson wrote: > Erik Hofman writes: > > > We have three FDM's of which two of them use windtunnel/flight-test > > data and one is based on physical dimensions of the aircraft. The > > latter is a bit less accurate but is easier to design a working > > aircraft for. > > To be fair, YASim is not necessarily less accurate, though it does use > a solver to fill in many of the blanks. It depends entirely on how you want to define accurate. The coefficient approach used in JSBSim and LaRCsim/UIUC makes it possible to duplicate the unique characteristics of a particular aircraft throughout the normal flight envelope. It is, however, more difficult to get reasonably good behavior in spins, stalls, and turbulence. The YASim approach makes it easier get the latter behaviors about right. In terms of unique characteristics, however, you can only match them at a couple of places in the flight envelope. Everywhere else, you take what you get. >In fact, YASim is currently the only FDM that performs calculations > for each lifting surface separately -- YASim figures out the angle of > attack, lift, and drag for each surface then calculates moments from > the differential lift and drag, while JSBSim uses a single angle of > attack for the entire aircraft and simulates the differences in lift > and drag using a long series of moment coefficients. Both are fine in > regular flight, but YASim's approach is likely to work better for > stalls, spins, and other aerobatic maneuvers outside of the regular > flight envelope. Note that it's far from perfect so far, but at least > the potential is there (likewise, it would be much easier to simulate > something like a tailplane stall from icing in YASim). > > JSBSim could do the same thing by providing an option to specify > separate coefficients and relative orientations for each lifting > surface. Then, if the right wing were producing more lift than the > left, you would have a left roll; if the right wing were also > producing more drag, you would have a right yaw; and so on. > > > All the best, > > > David -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
On Thu, 2003-03-20 at 04:23, Gerhard Wesp wrote: > > http://flightgear.org/Projects/RayChair/raychair.html > > http://flightgear.org/Projects/ > > Oops. Should have looked more closely on your homepage. Thanks! > > > We are a bit behind on this part. There is a project called OpenGC that > > has been working with FlightGear, but I don't know the current status. > > But your reply sounds as if there's interest. :-) > > Does jsbsim also take yaw angle into account Yes. > (fuselage drag)? It's up to the modeler. The default c172 models drag due to sideslip. > I.e., is > it possible to perform a slip (haven't had a real chance to try yet due > to lack of pedals). Yes. Use KP enter and zero for the rudder. You'll see the nose slice and find that you have to put in aileron to maintain heading. > For yasim I take it it is possible. > > -Gerhard -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Architectural questions
Jon Berndt writes: > I can think of a couple of situations where YASim would have advantages - > *at*present*: > > - Calculating any force or moment that is a result of rotational motion > while the aircraft is at zero translational velocity. > > - Clearly, any condition that is not covered by full aerodynamic > coefficients. Note that JSBSim would get all of this for free simply by allowing coefficients to be (optionally) specified for individual surfaces, each with its own orientation. All JSBSim would have to do is sum up the moments and forces (mostly forces) for the collection of surfaces. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
Gerhard Wesp writes: > Does jsbsim also take yaw angle into account (fuselage drag)? I.e., is > it possible to perform a slip (haven't had a real chance to try yet due > to lack of pedals). For yasim I take it it is possible. Yes. The sideslip angle is called "beta", and several coefficients are affected by it (these are from the default C172p): CDbeta: drag due to beta CYb: side force due to beta Clb: roll moment due to beta Cnb: yaw moment due to beta Since JSBSim uses runtime configuration files, you can add as many more beta-dependent coefficients as you want. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
Erik Hofman writes: > Yeah, but the windtunnel or flight-test data woudl include the > individual coefficients in one single value. This means that if there is > data for -180 ... +180 degree AOA and Yaw JSBSim (and UIUC) woudl be > more accurate compared to YASim. Not really, because there is a potentially infinite number of intereactions among different surfaces, and using aircraft-wide coefficients forces oversimplication, no matter how good the incoming data. Generally, the simplifications are subtle enough that we don't notice them, but in the end, traditional coefficient-based engines are faking it just as much as YASim is -- they just generally have more complete data to start with. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
Gerhard Wesp wrote: http://flightgear.org/Projects/RayChair/raychair.html http://flightgear.org/Projects/ Oops. Should have looked more closely on your homepage. Thanks! We are a bit behind on this part. There is a project called OpenGC that has been working with FlightGear, but I don't know the current status. But your reply sounds as if there's interest. :-) Well, I'm modelling an F-16 right now and it contains two MFD's. So MFD support would be realy nice to have. Does jsbsim also take yaw angle into account (fuselage drag)? I.e., is it possible to perform a slip (haven't had a real chance to try yet due to lack of pedals). For yasim I take it it is possible. Sure it is, with the right data ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Architectural questions
> Yeah, but the windtunnel or flight-test data woudl include the > individual coefficients in one single value. This means that if there is > data for -180 ... +180 degree AOA and Yaw JSBSim (and UIUC) woudl be > more accurate compared to YASim. > > That said, YASim is realy a good alternative for most situations. > > Erik I can think of a couple of situations where YASim would have advantages - *at*present*: - Calculating any force or moment that is a result of rotational motion while the aircraft is at zero translational velocity. - Clearly, any condition that is not covered by full aerodynamic coefficients. There are undoubtedly more, but likewise there are conditions where JSBSim is probably more accurate. We also have solutions for fixing the potential "blackout" regimes (as defined above) but those will take time to implement. Jon smime.p7s Description: S/MIME cryptographic signature
Re: [Flightgear-devel] Architectural questions
> http://flightgear.org/Projects/RayChair/raychair.html > http://flightgear.org/Projects/ Oops. Should have looked more closely on your homepage. Thanks! > We are a bit behind on this part. There is a project called OpenGC that > has been working with FlightGear, but I don't know the current status. But your reply sounds as if there's interest. :-) Does jsbsim also take yaw angle into account (fuselage drag)? I.e., is it possible to perform a slip (haven't had a real chance to try yet due to lack of pedals). For yasim I take it it is possible. -Gerhard -- | voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | Passts auf, seid's vuasichdig, und lossds eich nix gfoin! | -- Dr. Kurt Ostbahn ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
David Megginson wrote: Erik Hofman writes: > We have three FDM's of which two of them use windtunnel/flight-test > data and one is based on physical dimensions of the aircraft. The > latter is a bit less accurate but is easier to design a working > aircraft for. To be fair, YASim is not necessarily less accurate, though it does use a solver to fill in many of the blanks. In fact, YASim is currently the only FDM that performs calculations for each lifting surface separately -- YASim figures out the angle of attack, lift, and drag for each surface then calculates moments from the differential lift and drag, while JSBSim uses a single angle of attack for the entire aircraft and simulates the differences in lift and drag using a long series of moment coefficients. Both are fine in Yeah, but the windtunnel or flight-test data woudl include the individual coefficients in one single value. This means that if there is data for -180 ... +180 degree AOA and Yaw JSBSim (and UIUC) woudl be more accurate compared to YASim. That said, YASim is realy a good alternative for most situations. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Please help with vertex programm
Hi guys! I'm implementing light lobes to flightgear using per-pixel attenuation I modified viewer.cxx in plib distribution and this works fine but there are some problems for me here I totally confused model view matrixes and plib so I need help If someone intersted in I can send my sources maybe someone with Geforce3 card or better can help me The main question is why program works fine if I use in state programm "MOV c[19].x,v[0].x;\ MOV c[19].y,v[0].y;\ MOV c[19].z,v[0].z;\ MOV c[19].w,v[0].w;" and definitly don't work if I use "DP4 c[19].x,v[0],c[20];\ DP4 c[19].y,v[0],c[21];\ DP4 c[19].z,v[0],c[22];\ DP4 c[19].w,v[0],c[23];" Thanx in advance Bye
Re: [Flightgear-devel] Architectural questions
Erik Hofman writes: > We have three FDM's of which two of them use windtunnel/flight-test > data and one is based on physical dimensions of the aircraft. The > latter is a bit less accurate but is easier to design a working > aircraft for. To be fair, YASim is not necessarily less accurate, though it does use a solver to fill in many of the blanks. In fact, YASim is currently the only FDM that performs calculations for each lifting surface separately -- YASim figures out the angle of attack, lift, and drag for each surface then calculates moments from the differential lift and drag, while JSBSim uses a single angle of attack for the entire aircraft and simulates the differences in lift and drag using a long series of moment coefficients. Both are fine in regular flight, but YASim's approach is likely to work better for stalls, spins, and other aerobatic maneuvers outside of the regular flight envelope. Note that it's far from perfect so far, but at least the potential is there (likewise, it would be much easier to simulate something like a tailplane stall from icing in YASim). JSBSim could do the same thing by providing an option to specify separate coefficients and relative orientations for each lifting surface. Then, if the right wing were producing more lift than the left, you would have a left roll; if the right wing were also producing more drag, you would have a right yaw; and so on. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
Gerhard Wesp wrote: Hello Dev team, Are there projects using FlightGear as the ``engine'' of a simulator with cockpit mockup, multiple projectors, head down display and and possibly a motion platform? http://flightgear.org/Projects/RayChair/raychair.html http://flightgear.org/Projects/ This would imply the need for - multiple out-the-window views, most likely driven by multiple rendering machines, with freely definable cameras. - Multiple head down displays (probably TFTs) with instruments. We are a bit behind on this part. There is a project called OpenGC that has been working with FlightGear, but I don't know the current status. - The possibility to create and add new instruments. - An output of the aircraft dynamics (linear and rotational accelerations) for driving the motion platform. I guess it all boils down to having well-defined ``data streaming'' interfaces between the individual components of flight simulation, the FDM, HDD, Scenery renderer and Sound. For distributed simulation, these would have to bee network protocols (ideally based on some underlying realtime protocol, but in practice it would probably work with UDP or TCP). FlightGear running as an application on one PC or workstation would then simply be a special case of distributed simulation. I'm interested in how well the FlightGear architecture would be suited for such an application, has it been done, what are the developer's thoughts about it, etc. Any feedback is greatly appreciated! As an aside: How much effort does it usually take to add a FDM to FlightGear (e.g., a DC6 model)? This depends on how accurate you want to model the aircraft. We have three FDM's of which two of them use windtunnel/flight-test data and one is based on physical dimensions of the aircraft. The latter is a bit less accurate but is easier to design a working aircraft for. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Architectural questions
Hello Dev team, Are there projects using FlightGear as the ``engine'' of a simulator with cockpit mockup, multiple projectors, head down display and and possibly a motion platform? This would imply the need for - multiple out-the-window views, most likely driven by multiple rendering machines, with freely definable cameras. - Multiple head down displays (probably TFTs) with instruments. - The possibility to create and add new instruments. - An output of the aircraft dynamics (linear and rotational accelerations) for driving the motion platform. - ... I guess it all boils down to having well-defined ``data streaming'' interfaces between the individual components of flight simulation, the FDM, HDD, Scenery renderer and Sound. For distributed simulation, these would have to bee network protocols (ideally based on some underlying realtime protocol, but in practice it would probably work with UDP or TCP). FlightGear running as an application on one PC or workstation would then simply be a special case of distributed simulation. I'm interested in how well the FlightGear architecture would be suited for such an application, has it been done, what are the developer's thoughts about it, etc. Any feedback is greatly appreciated! As an aside: How much effort does it usually take to add a FDM to FlightGear (e.g., a DC6 model)? Best regards, -Gerhard -- | voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/ | | Passts auf, seid's vuasichdig, und lossds eich nix gfoin! | -- Dr. Kurt Ostbahn ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem with MultiPlayer Code
Jonathan Polley wrote: Oh, and it will not link because of the following missing symbols: You will either have to do a "make clean" or remove the following files by hand: Cockpit/hud.o GUI/gui.o GUI/gui_funcs.o Main/main.o Main/options.o Main/util.o Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem with MultiPlayer Code
Jonathan Polley wrote: Oh, and it will not link because of the following missing symbols: These are symbold from NetworkOLK. Did you rerun autogen.sh and configure? Erik BTW. The fixes are in CVS now. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
