Re: [Flightgear-devel] Updating the manual
Tatsuhiro Nishioka wrote: > On Oct 15, 2008, at 3:53 AM, fakesexnoises > <[EMAIL PROTECTED]> wrote: > > > From the looks of things I'd have to install all the Developers Tools > > in order to gain access to CVS, which I would then have to learn, and > > this is more work than I was envisioning. > > No. You don't have to install the Developer tools just for revising > the manual or just for cvs. It's too much. > > Plus, you don't even need cvs to get the source files of the manual. > Go visit the URL that Martin posted. There is a "snapshdot" link on > the top of the file list. Clicking the link will start downloading the > archive of all source files. > > If you are not familiar with TeX, you can continue annotating on the > PDF file using preview.app. > > > > I'm going to unsubscribe from the list now. Good luck to all with the > > development of this project as a whole. > > > > Hope it is not too late.. > Perhaps the clue was in the name? Let's hope not. Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for multiscreen mode with multiplayer
Hi Erwan, Tim's multiple view features are very powerful, and I'm amazed at how fast things run on medium and even lower range hardware. Tim's updates support two major modes of operation. 1. If you have multiple monitors connected to your computer and setup as separate independent displays (i.e. you can't drag a window back and forth between the monitors, and can't create a window that spans multiple monitors) then you can configure FlightGear to open up a separate window on each display and draw a unique view perspective in each window. (And if you want you can configure flightgear to open multiple windows on a single display.) 2. If you have multiple monitors connected as one larger virtual display, you can configure FlightGear to open up one large window that spans all your displays, but then separate that large window into individual cameras and still draw a unique perspective on each display. In addition, each view is highly configurable, no matter how your displays are configured. - You can setup a distinct field of view for each display, so you can create a seamless outside world with different size monitors. - If you wish, you can define each view in terms of the low level view frustum parameters, so you can carefully measure your monitor/display layout and configure each view to match your physical layout exactly ... including asymmetric view frustums if need be. Otherwise you can still define your views in terms of a simpler (but less flexible) horizontal/vertical field of view scheme. - You can specify the horizontal and vertical offset from center for each display. This allows you to spread out your monitors to account for the physical gap between displays ... this allows you to create an even more seamless virtual world where runway lines and horizon lines start in the correct place on the next monitor when they run off the edge of the first. Imagine taking a large poster, cutting it into pieces and the separating the pieces from each other by a little bit ... none of the straight lines in the original image will pass straight through in the separated/stretched version. Now imagine taking that same picture and cutting strips out of it, but leaving the sections where they were originally. Straight lines are preserved between adjacent pieces. This is the sort of thing I'm talking about here. Examples: - ATI (the ATI that makes graphics chips and cards) used a simplified (prerelease) version of this feature to demo 8 screens being driven from a single computer at SigGraph this year. - Enter the Matrox Triple Head to Go (google it if you haven't heard of it.) This is just a little box, but to the computer, it looks like one giant 3x wide monitor. It plugs into your computer on one side, and on the other side you plug in 3 actual monitors. So you get up to 3 monitors without your computer needing to know anything about it, and even on video cards with only one external display connector (like a laptop.) Using the 2nd mode of operation described above, I divided my one big window into 3 camera views and was able to draw about 120 degree wrap around field of view on 3 displays. In addition, the laptop's built in display was still available for ... oh ... let's say an operator console: http://baron.flightgear.org/~curt/tmp/IMG_2196.JPG - I've done an extended version of this same theme where the front 3 monitors were driven by a single PC with the Matrox Triple Head 2 Go box, and the 90 degree left/right displays (2 displays) were driven by a second computer using stock dual head nvidia hardware. None of this unfortunately ends up in my own house. I'm stuck with ye-olde 17" LCD dispay (analog) for my view into the virtual world. :-) So to summarize, I'm extremely impressed and happy with how well Tim leveraged OSG's multiple window and multiple camera features and how well they are integrated into FlightGear. In a former life (circa year 2000) I used to work on a driving simulator that was powered by a $250,000 Sgi Onyx. This system had the ability to take the 4 quadrants of your display and pipe that to 4 separate monitors. Unfortunately, the hardware started bogging down and the best we could do was three 640x480 displays at about 15 fps. Fast forward to 8 years later and you can do three 1280x1024 displays at 60fps (easily) running on hardware that easily costs less than $1000. (Oh and that Sgi would break down every couple months, requiring board replacements ... and those boards ran $30k to $60k each and required a specially trained sgi tech to install them. We paid $10k a year for our hardware maintenance contract.) Regards, Curt. On Wed, Oct 15, 2008 at 2:38 AM, Erwan MAS wrote: > On Tue, Oct 14, 2008 at 04:01:55PM -0400, Matthew Tippett wrote: > > Hi, > > > > I don't know if Tim has documented the OSG Camera work that he has done. > > it removes most of the requirements for multiple instances and runs > > very well on modest hardware. Of course it
Re: [Flightgear-devel] terragear-cs scenery generation problem
Ralf Gerlich wrote: > Hi Michael! > > Michael Smith wrote: > >> I have my lon/lat for Bermuda (N32W065 - N33W064). >> > [SNIP] > > >> genapts --input=data/airports/apt.dat --work=./work --min-lon=32 >> --max-lon=33 --min-lat=-65 --max-lat=-64 >> > > Here you should swap lat and lon. Your latitude is 32 (32 deg north) and > your longitude is -64 (64 deg west). > > >> ran fgfs-construct --work-dir=./work --output-dir=./output --lon=32 >> --lat=65 --xdist=1 --ydist=1 \ AirportArea DepthContour Landmass Road >> Sand SRTM-30 Town >> > > Similar problem here. Note that the position given by --lon/--lat is > actually the center of the area being built and --xdist/--ydist are the > half-width/height of the area in degrees. So --lon=-64 --lat=32 > --xdist=1 --ydist=1 would build the area with southwest corner N31W065 > and northeast corner N33W063. > > DepthContour is not needed, by the way. It's just a different > representation of the SRTM dataset for use in the mapserver display, but > currently TerraGear cannot make any use of that. > > Make sure that you include all the subdirectories of your workdir when > calling fgfs-construct. > > Note that even though that tutorial in the wiki (which I am not the > author of) uses SRTM-30 as a target directory for the SRTM data, it > seems that SRTM 3arcsec data is actually used. That's not a bad thing at > all, but worth noting. SRTM 30arcsec data is only relevant north resp. > south of the respective polar circles, as no SRTM 3arcsec data is > available in that area. > > Hope that helps, > Ralf > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > I fixed the Lon/Lat and such but it still finished sucessfully and it still doesn't output anything. Michael Smith <[EMAIL PROTECTED]> - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for multiscreen mode with multiplayer
Now has this been documented? Or is there sufficient OSG documentation to guide? Regards, Matthew Original Message Subject: Re: [Flightgear-devel] Patch for multiscreen mode with multiplayer From: Curtis Olson <[EMAIL PROTECTED]> To: FlightGear developers discussions Date: 15/10/08 09:59 AM > Hi Erwan, > > Tim's multiple view features are very powerful, and I'm amazed at how > fast things run on medium and even lower range hardware. > > Tim's updates support two major modes of operation. > > 1. If you have multiple monitors connected to your computer and setup as > separate independent displays (i.e. you can't drag a window back and > forth between the monitors, and can't create a window that spans > multiple monitors) then you can configure FlightGear to open up a > separate window on each display and draw a unique view perspective in > each window. (And if you want you can configure flightgear to open > multiple windows on a single display.) > > 2. If you have multiple monitors connected as one larger virtual > display, you can configure FlightGear to open up one large window that > spans all your displays, but then separate that large window into > individual cameras and still draw a unique perspective on each display. > > In addition, each view is highly configurable, no matter how your > displays are configured. > > - You can setup a distinct field of view for each display, so you can > create a seamless outside world with different size monitors. > > - If you wish, you can define each view in terms of the low level view > frustum parameters, so you can carefully measure your monitor/display > layout and configure each view to match your physical layout exactly ... > including asymmetric view frustums if need be. Otherwise you can still > define your views in terms of a simpler (but less flexible) > horizontal/vertical field of view scheme. > > - You can specify the horizontal and vertical offset from center for > each display. This allows you to spread out your monitors to account > for the physical gap between displays ... this allows you to create an > even more seamless virtual world where runway lines and horizon lines > start in the correct place on the next monitor when they run off the > edge of the first. Imagine taking a large poster, cutting it into > pieces and the separating the pieces from each other by a little bit ... > none of the straight lines in the original image will pass straight > through in the separated/stretched version. Now imagine taking that > same picture and cutting strips out of it, but leaving the sections > where they were originally. Straight lines are preserved between > adjacent pieces. This is the sort of thing I'm talking about here. > > Examples: > > - ATI (the ATI that makes graphics chips and cards) used a simplified > (prerelease) version of this feature to demo 8 screens being driven from > a single computer at SigGraph this year. > > - Enter the Matrox Triple Head to Go (google it if you haven't heard of > it.) This is just a little box, but to the computer, it looks like one > giant 3x wide monitor. It plugs into your computer on one side, and on > the other side you plug in 3 actual monitors. So you get up to 3 > monitors without your computer needing to know anything about it, and > even on video cards with only one external display connector (like a > laptop.) Using the 2nd mode of operation described above, I divided my > one big window into 3 camera views and was able to draw about 120 degree > wrap around field of view on 3 displays. > > In addition, the laptop's built in display was still available for ... > oh ... let's say an operator console: > > http://baron.flightgear.org/~curt/tmp/IMG_2196.JPG > > - I've done an extended version of this same theme where the front 3 > monitors were driven by a single PC with the Matrox Triple Head 2 Go > box, and the 90 degree left/right displays (2 displays) were driven by a > second computer using stock dual head nvidia hardware. > > None of this unfortunately ends up in my own house. I'm stuck with > ye-olde 17" LCD dispay (analog) for my view into the virtual world. :-) > > So to summarize, I'm extremely impressed and happy with how well Tim > leveraged OSG's multiple window and multiple camera features and how > well they are integrated into FlightGear. > > In a former life (circa year 2000) I used to work on a driving simulator > that was powered by a $250,000 Sgi Onyx. This system had the ability to > take the 4 quadrants of your display and pipe that to 4 separate > monitors. Unfortunately, the hardware started bogging down and the best > we could do was three 640x480 displays at about 15 fps. > > Fast forward to 8 years later and you can do three 1280x1024 displays at > 60fps (easily) running on hardware that easily costs less than $1000. > (Oh and that Sgi would break down every couple m
Re: [Flightgear-devel] Patch for multiscreen mode with multiplayer
Matthew Tippett wrote: > Now has this been documented? Or is there sufficient OSG documentation > to guide? > See docs-mini/README.multiscreen in the FlightGear source tree. Tim > Regards, > > Matthew > > Original Message > Subject: Re: [Flightgear-devel] Patch for multiscreen mode with multiplayer > From: Curtis Olson <[EMAIL PROTECTED]> > To: FlightGear developers discussions > > Date: 15/10/08 09:59 AM > >> Hi Erwan, >> >> Tim's multiple view features are very powerful, and I'm amazed at how >> fast things run on medium and even lower range hardware. >> >> Tim's updates support two major modes of operation. >> >> 1. If you have multiple monitors connected to your computer and setup as >> separate independent displays (i.e. you can't drag a window back and >> forth between the monitors, and can't create a window that spans >> multiple monitors) then you can configure FlightGear to open up a >> separate window on each display and draw a unique view perspective in >> each window. (And if you want you can configure flightgear to open >> multiple windows on a single display.) >> >> 2. If you have multiple monitors connected as one larger virtual >> display, you can configure FlightGear to open up one large window that >> spans all your displays, but then separate that large window into >> individual cameras and still draw a unique perspective on each display. >> >> In addition, each view is highly configurable, no matter how your >> displays are configured. >> >> - You can setup a distinct field of view for each display, so you can >> create a seamless outside world with different size monitors. >> >> - If you wish, you can define each view in terms of the low level view >> frustum parameters, so you can carefully measure your monitor/display >> layout and configure each view to match your physical layout exactly ... >> including asymmetric view frustums if need be. Otherwise you can still >> define your views in terms of a simpler (but less flexible) >> horizontal/vertical field of view scheme. >> >> - You can specify the horizontal and vertical offset from center for >> each display. This allows you to spread out your monitors to account >> for the physical gap between displays ... this allows you to create an >> even more seamless virtual world where runway lines and horizon lines >> start in the correct place on the next monitor when they run off the >> edge of the first. Imagine taking a large poster, cutting it into >> pieces and the separating the pieces from each other by a little bit ... >> none of the straight lines in the original image will pass straight >> through in the separated/stretched version. Now imagine taking that >> same picture and cutting strips out of it, but leaving the sections >> where they were originally. Straight lines are preserved between >> adjacent pieces. This is the sort of thing I'm talking about here. >> >> Examples: >> >> - ATI (the ATI that makes graphics chips and cards) used a simplified >> (prerelease) version of this feature to demo 8 screens being driven from >> a single computer at SigGraph this year. >> >> - Enter the Matrox Triple Head to Go (google it if you haven't heard of >> it.) This is just a little box, but to the computer, it looks like one >> giant 3x wide monitor. It plugs into your computer on one side, and on >> the other side you plug in 3 actual monitors. So you get up to 3 >> monitors without your computer needing to know anything about it, and >> even on video cards with only one external display connector (like a >> laptop.) Using the 2nd mode of operation described above, I divided my >> one big window into 3 camera views and was able to draw about 120 degree >> wrap around field of view on 3 displays. >> >> In addition, the laptop's built in display was still available for ... >> oh ... let's say an operator console: >> >> http://baron.flightgear.org/~curt/tmp/IMG_2196.JPG >> >> - I've done an extended version of this same theme where the front 3 >> monitors were driven by a single PC with the Matrox Triple Head 2 Go >> box, and the 90 degree left/right displays (2 displays) were driven by a >> second computer using stock dual head nvidia hardware. >> >> None of this unfortunately ends up in my own house. I'm stuck with >> ye-olde 17" LCD dispay (analog) for my view into the virtual world. :-) >> >> So to summarize, I'm extremely impressed and happy with how well Tim >> leveraged OSG's multiple window and multiple camera features and how >> well they are integrated into FlightGear. >> >> In a former life (circa year 2000) I used to work on a driving simulator >> that was powered by a $250,000 Sgi Onyx. This system had the ability to >> take the 4 quadrants of your display and pipe that to 4 separate >> monitors. Unfortunately, the hardware started bogging down and the best >> we could do was three 640x480 displays at about 15 fps. >> >> Fast forw
Re: [Flightgear-devel] terragear-cs scenery generation problem
Michael Smith wrote: > Ralf Gerlich wrote: > >> Hi Michael! >> >> Michael Smith wrote: >> >> >>> I have my lon/lat for Bermuda (N32W065 - N33W064). >>> >>> >> [SNIP] >> >> >> >>> genapts --input=data/airports/apt.dat --work=./work --min-lon=32 >>> --max-lon=33 --min-lat=-65 --max-lat=-64 >>> >>> >> Here you should swap lat and lon. Your latitude is 32 (32 deg north) and >> your longitude is -64 (64 deg west). >> >> >> >>> ran fgfs-construct --work-dir=./work --output-dir=./output --lon=32 >>> --lat=65 --xdist=1 --ydist=1 \ AirportArea DepthContour Landmass Road >>> Sand SRTM-30 Town >>> >>> >> Similar problem here. Note that the position given by --lon/--lat is >> actually the center of the area being built and --xdist/--ydist are the >> half-width/height of the area in degrees. So --lon=-64 --lat=32 >> --xdist=1 --ydist=1 would build the area with southwest corner N31W065 >> and northeast corner N33W063. >> >> DepthContour is not needed, by the way. It's just a different >> representation of the SRTM dataset for use in the mapserver display, but >> currently TerraGear cannot make any use of that. >> >> Make sure that you include all the subdirectories of your workdir when >> calling fgfs-construct. >> >> Note that even though that tutorial in the wiki (which I am not the >> author of) uses SRTM-30 as a target directory for the SRTM data, it >> seems that SRTM 3arcsec data is actually used. That's not a bad thing at >> all, but worth noting. SRTM 30arcsec data is only relevant north resp. >> south of the respective polar circles, as no SRTM 3arcsec data is >> available in that area. >> >> Hope that helps, >> Ralf >> >> - >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >> >> >> > I fixed the Lon/Lat and such but it still finished sucessfully and it > still doesn't output anything. > > Michael Smith <[EMAIL PROTECTED]> > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > Ok I found the problem, for some reason, fgfs-construct won't work unless I use full paths for the data directorys, I do that and it works like a charm. Thanksa bunch to Nav and Ralf Michael Smith <[EMAIL PROTECTED]> - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for multiscreen mode with multiplayer
On Wed, Oct 15, 2008 at 9:10 AM, Matthew Tippett wrote: > Now has this been documented? Or is there sufficient OSG documentation > to guide? Look for docs-mini/README.multiscreen in the CVS source. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] docs-mini vs $FG_ROOT/Docs/ (was: Re: Patch for multiscreen mode with multiplayer)
* Curtis Olson -- Wednesday 15 October 2008: > Look for docs-mini/README.multiscreen in the CVS source. In the past we had "identical" files in $FG_SOURCE/docs-mini/ and $FG_ROOT/Docs/. The problem with that approach, however, is that both being in sync was rather the exception than the norm. And it *is* a pain to have to update both. (Same for the Thanks file, which I wanted to update recently, but gave up for now after I realized that different entries had been added to both of them.) To solve that problem, I think we should not maintain documentation duplicates, but put everything into $FG_ROOT/Docs/ except pure developer documentation, which should be in the source directory *only* -- and under a better name than docs-mini (as soon as we have an CMS that understands renaming). m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] docs-mini vs $FG_ROOT/Docs/
Oh, and what I really wanted to say in my last mail: * Curtis Olson -- Wednesday 15 October 2008: > Look for docs-mini/README.multiscreen in the CVS source. That's a bad place. It belongs to $FG_ROOT/Docs/. (Only!) m. :-) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] docs-mini vs $FG_ROOT/Docs/ (was: Re: Patch for multiscreen mode with multiplayer)
On Wed, Oct 15, 2008 at 12:32 PM, Melchior FRANZ wrote: > * Curtis Olson -- Wednesday 15 October 2008: > > Look for docs-mini/README.multiscreen in the CVS source. > > In the past we had "identical" files in $FG_SOURCE/docs-mini/ > and $FG_ROOT/Docs/. The problem with that approach, however, > is that both being in sync was rather the exception than the > norm. And it *is* a pain to have to update both. (Same for > the Thanks file, which I wanted to update recently, but gave > up for now after I realized that different entries had been > added to both of them.) > > To solve that problem, I think we should not maintain > documentation duplicates, but put everything into $FG_ROOT/Docs/ > except pure developer documentation, which should be in > the source directory *only* -- and under a better name than > docs-mini (as soon as we have an CMS that understands > renaming). Part of my scripts for doing a release include mirroring the src/docs-mini directory over to the data/docs-mini, but I agree that having these files mirrored in two separate places can be confusing and if new comers modify the files in data/docs-mini, those changes will ultimately get lost which probably is a bad thing. So I have no problem moving these files, but maybe under the data tree so they are automatically included if someone gets either a source based or binary based distribution of FlightGear. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs]CVS:data/Models/Geometry/Nimitz/Models/Effectscat-steam-eng.xml, NONE, 1.1 cat-steam.xml, NONE, 1.1 smoke.png, NONE, 1.1
gerard robin wrote > > On mardi 14 octobre 2008, Vivian Meazza wrote: > > I wrote > > > > > gerard robin wrote > > > > > > > On lundi 13 octobre 2008, Vivian Meazza wrote: > > > > > Update of > > > > > /var/cvs/FlightGear-0.9/data/Models/Geometry/Nimitz/Models/Effects > In > > > > > directory baron.flightgear.org:/tmp/cvs-serv25413 > > > > > > > > > > Added Files: > > > > > cat-steam-eng.xml cat-steam.xml smoke.png > > > > > Log Message: > > > > > Add catapult steam effects > > > > > > > > hello Vivian > > > > Nice idea, would you mind if i include it on the Clemenceau, and > later > > > > on, > > > > the others French Carriers. > > > > Or may be, it could a common Effect somewhere in, the geometry > > > > > > folder. > > > > > > > Regards > > > > > > I was only mucking about to see if I could get something I liked. Of > > > course > > > I can make it generic, in the Models folder. I'll do it this evening. > > > > Sorry, I got that one wrong. As soon as I prepared to upload a generic > > version, I realised that wasn't going to work. The catapult steam needs > > customizing for each catapult length. So you need at least different > > versions for each carrier, and possibly more than 1. > > > > So, just copy the Nimitz stuff that you require, and customize it as > > necessary. > > > > Vivian > > > Yes , your conclusion is close to what was wondering about it , on how to > solve it :) > > In any case with JSBSim i could control the steam duration length > exactly > like we control the launchbar during catapult operation ( when the > catapult > move and operate we have steam). > This can be tuned: steam just before to start cat (1 sec) and steam as > long as > the catapult is on the deck moving with the launchbar. > > I guess that with YASim you have the same possibility. > So i can include any steam animation into the Aircraft model itself , NOT > onto > the Carrier. > In that case the generic steam somewhere would usefull ( like you have > created > smoke ) > > Now that we have the tag it is possible to make the catapult steam generic, so I have added a Generic/Effects folder to Models. I've converted Nimitz to use this - so you can see how it might be done. Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs scenery generation problem
Hi Michael! Michael Smith wrote: > I have my lon/lat for Bermuda (N32W065 - N33W064). [SNIP] > genapts --input=data/airports/apt.dat --work=./work --min-lon=32 > --max-lon=33 --min-lat=-65 --max-lat=-64 Here you should swap lat and lon. Your latitude is 32 (32 deg north) and your longitude is -64 (64 deg west). > ran fgfs-construct --work-dir=./work --output-dir=./output --lon=32 > --lat=65 --xdist=1 --ydist=1 \ AirportArea DepthContour Landmass Road > Sand SRTM-30 Town Similar problem here. Note that the position given by --lon/--lat is actually the center of the area being built and --xdist/--ydist are the half-width/height of the area in degrees. So --lon=-64 --lat=32 --xdist=1 --ydist=1 would build the area with southwest corner N31W065 and northeast corner N33W063. DepthContour is not needed, by the way. It's just a different representation of the SRTM dataset for use in the mapserver display, but currently TerraGear cannot make any use of that. Make sure that you include all the subdirectories of your workdir when calling fgfs-construct. Note that even though that tutorial in the wiki (which I am not the author of) uses SRTM-30 as a target directory for the SRTM data, it seems that SRTM 3arcsec data is actually used. That's not a bad thing at all, but worth noting. SRTM 30arcsec data is only relevant north resp. south of the respective polar circles, as no SRTM 3arcsec data is available in that area. Hope that helps, Ralf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS Snapshot for publicity?
Now that I have seen the documentation... Some updates. ... > > BTW, really neat stuff with the 8 monitor demo! If I had to nitpick, > I'd suggest that (at least from the video) it appeared that not every > display was identical in size? Also, with Tim's most recent CVS > changes, it's possible to adjust the view parameters for each monitor to > account for the gap between monitors (i.e. so it doesn't look like you > sliced up an image into 8 pieces and then spread them apart.) I'll look into the new camera view details.. It may work out nicer if the camera-group works as I expect. > And if I > was getting really nitpicky, I suggest that it might be fun to go > blasting up some valleys in the mountains east of seattle somewhere, > although flying around SFO isn't a bad choice either ... perhaps some > dusk/dawn flying would have been fun too ... (But I do realize there is > only so much you can show in a couple minute demo.) I can't fly flightgear sufficiently. Jentron on IRC provided the first flightdata. If you want to record a flightpath with a jet of some sort, I am more than happy to use that. Possibly even Basically, what I want to see to improve flightgear's ability to engage users by making the "default" mode a lot more interesting. I am hoping that any recorded (and shipped with flightgear) flightpaths will get extra focus from designers and modellers to increase the eye-candy. Something like http://www.youtube.com/watch?v=dPxp37Ticao&feature=related Shipping and being available for all to see with minimal extra effort would be great. Maybe even create a demo package format for people to share (=flightgear + data + extra data (like time of day, aircraft, etc). Regards, Matthew - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs]CVS:data/Models/Geometry/Nimitz/Models/Effectscat-steam-eng.xml, NONE, 1.1 cat-steam.xml, NONE, 1.1 smoke.png, NONE, 1.1
On mercredi 15 octobre 2008, Vivian Meazza wrote: > gerard robin wrote > > > On mardi 14 octobre 2008, Vivian Meazza wrote: > > > I wrote > > > > > > > gerard robin wrote > > > > > > > > > On lundi 13 octobre 2008, Vivian Meazza wrote: > > > > > > Update of > > > > > > /var/cvs/FlightGear-0.9/data/Models/Geometry/Nimitz/Models/Effect > > > > > >s > > > > In > > > > > > > > directory baron.flightgear.org:/tmp/cvs-serv25413 > > > > > > > > > > > > Added Files: > > > > > > cat-steam-eng.xml cat-steam.xml smoke.png > > > > > > Log Message: > > > > > > Add catapult steam effects > > > > > > > > > > hello Vivian > > > > > Nice idea, would you mind if i include it on the Clemenceau, and > > > > later > > > > > > > on, > > > > > the others French Carriers. > > > > > Or may be, it could a common Effect somewhere in, the geometry > > > > > > > > folder. > > > > > > > > > Regards > > > > > > > > I was only mucking about to see if I could get something I liked. Of > > > > course > > > > I can make it generic, in the Models folder. I'll do it this evening. > > > > > > Sorry, I got that one wrong. As soon as I prepared to upload a generic > > > version, I realised that wasn't going to work. The catapult steam needs > > > customizing for each catapult length. So you need at least different > > > versions for each carrier, and possibly more than 1. > > > > > > So, just copy the Nimitz stuff that you require, and customize it as > > > necessary. > > > > > > Vivian > > > > Yes , your conclusion is close to what was wondering about it , on how > > to solve it :) > > > > In any case with JSBSim i could control the steam duration length > > exactly > > like we control the launchbar during catapult operation ( when the > > catapult > > move and operate we have steam). > > This can be tuned: steam just before to start cat (1 sec) and steam as > > long as > > the catapult is on the deck moving with the launchbar. > > > > I guess that with YASim you have the same possibility. > > So i can include any steam animation into the Aircraft model itself , NOT > > onto > > the Carrier. > > In that case the generic steam somewhere would usefull ( like you have > > created > > smoke ) > > Now that we have the tag it is possible to make the catapult > steam generic, so I have added a Generic/Effects folder to Models. I've > converted Nimitz to use this - so you can see how it might be done. > > Vivian Thanks, However, i fear i had talked too quickly, when i said that it could used on my side with Clemenceau. You know the problem, we discussed it before, since YASim is not JSBSim i can't use the "text" condition only numeric condition. It is sure that we are going to some different ways , there will be Carrier JSBSim compatible and YASim compatible, as long as we don't have a modular structure out of FDM which could be used by any FDM (like => the Carrier wires and catapults position, some usable triggers Engaged, Launch ...) I can understand that the carrier devel has been done only for YASim. Now we may have Carrier features with JSBsim , that first version with Crusader and Clemenceau is only the first step before many others which should come up ( i hope :) ) Regarding the steam effect, i will include it and trigger it in the Model Aircraft itself. Cheers - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs]CVS:data/Models/Geometry/Nimitz/Models/Effectscat-steam-eng.xml, NONE, 1.1 cat-steam.xml, NONE, 1.1 smoke.png, NONE, 1.1
* robin424 -- Wednesday 15 October 2008: > You know the problem, we discussed it before, since YASim is not > JSBSim i can't use the "text" condition only numeric condition. Sounds like jsbsim is a major millstone around your neck. What about fixing jsbsim? :-P m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs]CVS:data/Models/Geometry/Nimitz/Models/Effectscat-steam-eng.xml, NONE, 1.1 cat-steam.xml, NONE, 1.1 smoke.png, NONE, 1.1
On mercredi 15 octobre 2008, Melchior FRANZ wrote: > * robin424 -- Wednesday 15 October 2008: > > You know the problem, we discussed it before, since YASim is not > > JSBSim i can't use the "text" condition only numeric condition. > > Sounds like jsbsim is a major millstone around your neck. > What about fixing jsbsim? :-P > > m. I am not surprised with your remark :) , probably you did not follow up the development of the External_Force External_Force is generic with it we can do everything we want. Catapult or hook are among of a lot of many usage , look the mule for instance . So there is not any restriction to use it. I do with carrier. Anders does it with Zepelin, it will be done with brake chute and so on ... So don't say that JSBSim must be fixed. There is nothing to fix. Jon could explain better that concept. Sure ,regarding the restrictions coming from the existing Carrier/Yasim system that generic flexible approach is out of reality. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs]CVS:data/Models/Geometry/Nimitz/Models/Effectscat-steam-eng.xml, NONE, 1.1 cat-steam.xml, NONE, 1.1 smoke.png, NONE, 1.1
On mercredi 15 octobre 2008, Melchior FRANZ wrote: > * robin424 -- Wednesday 15 October 2008: > > You know the problem, we discussed it before, since YASim is not > > JSBSim i can't use the "text" condition only numeric condition. > > Sounds like jsbsim is a major millstone around your neck. > What about fixing jsbsim? :-P > > m. > > I guess that was a joke from you, because you understood probably that 'the major millstone around my neck' today is not coming from JSBSim. :) :) :) :):-P -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Models/Geometry/Nimitz/Models/deck-edge-light.xml
Hello CVS is missing the following file data/Models/Geometry/Nimitz/Models/deck-edge-light.xml -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for multiscreen mode with multiplayer
On Wed, Oct 15, 2008 at 08:59:52AM -0500, Curtis Olson wrote: > Hi Erwan, > > Tim's multiple view features are very powerful, and I'm amazed at how fast > things run on medium and even lower range hardware. > > Tim's updates support two major modes of operation. But this require that all screens are attached to the same computer . Currently i work with 2 computerq so i have 3 screens with only 1 keyboard/mouse with SYNERGY ( see http://synergy2.sourceforge.net/ ) . Operating systems can be different . So the multi-instance mode for multiscreen is very simple to setup for me. My configuration is a laptop and a computer with 2 screens, and i dont need special hardware to play . I have a nvidia card with in xinerama mode . I think we must keep the another mode for multiscreen ( aka multi instance ) . -- / Erwan MAS /\ | mailto:[EMAIL PROTECTED] |_/ ___| | \___\__/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for multiscreen mode with multiplayer
First up, some arbitrary definitions. Multi-instance means multiple instances of flightgear running (on one machine or many). Multi-camera is using what Tim is describing here. I don't believe that multi-camera is exclusive of multi-instance. But for most users, a multi-camera setup will be cheaper (assuming you have the slots on your motherboard). Regards... Matthew On 10/15/08, Erwan MAS <[EMAIL PROTECTED]> wrote: > On Wed, Oct 15, 2008 at 08:59:52AM -0500, Curtis Olson wrote: >> Hi Erwan, >> >> Tim's multiple view features are very powerful, and I'm amazed at how fast >> things run on medium and even lower range hardware. >> >> Tim's updates support two major modes of operation. > > But this require that all screens are attached to the same computer . > > Currently i work with 2 computerq so i have 3 screens with only 1 > keyboard/mouse > with SYNERGY ( see http://synergy2.sourceforge.net/ ) . Operating systems > can > be different . > > So the multi-instance mode for multiscreen is very simple to setup for me. > > My configuration is a laptop and a computer with 2 screens, and i dont need > special > hardware to play . I have a nvidia card with in xinerama mode . > > I think we must keep the another mode for multiscreen ( aka multi instance ) > . > > -- > > / Erwan MAS /\ >| mailto:[EMAIL PROTECTED] |_/ > ___| | > \___\__/ > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Sent from my mobile device - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for multiscreen mode with multiplayer
On Wed, Oct 15, 2008 at 07:52:42PM -0400, Matthew Tippett wrote: > First up, some arbitrary definitions. Multi-instance means multiple > instances of flightgear running (on one machine or many). > Multi-camera is using what Tim is describing here. > > I don't believe that multi-camera is exclusive of multi-instance. I agree with this . > But for most users, a multi-camera setup will be cheaper (assuming you > have the slots on your motherboard). I many people have multiple computer too , so multi-instance can still be useful :-) Regards , Erwan -- / Erwan MAS /\ | mailto:[EMAIL PROTECTED] |_/ ___| | \___\__/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
