[Flightgear-devel] Photo Scenery
Thought I'd post this reply to an email from Stacie re photo scenery so it willl show up for anyone searching on the subject. Hi Stacie, The following is an outline of how I created the photo scenery. All the working out of things such as the size of the squares on the "mystery grid" was done purely by tedious trial and error. I can't write in any computer language such as perl, so I processed the figures for the larger grid of squares using a spreadsheet ! As such it is terrible route to getting photo imagery into Flightgear. Having said that it does work. It could be improved dramatically if a few things were in place. Two things would make the entire operation vastly simpler. 1. If someone was able to extract the lat/long information of the "mystery grid" from Flightgear and use this directly to create the grid of squares for the scenery build. 2. If tguserdef was able to attribute textures with any name then the manual re attribution of texture type to each triangle could be avoided. If I was doing this again I would try to get these two things resolved before I went ahead. Someone could then write a perl script to automate much of the following. Unfortunately I lost a hard drive not long after doing the photo scenery, so I don't have the spreadsheets or xml files I used. Also if the area you are building has coastline I also worked out a solution for getting that to look OK. Mat Churchill Flightgear places textures inside a mystery grid (that I don't fully understand). I have asked a couple of times on the forum and haven't got an answer as to what it is. Textures are assigned a size (amongst other things) in the materials.xml file. I think the ones with a size around 1000 seem to fit exactly into this grid, smaller ones are fitted into the grid multiple times. To show the grid I created a texture that was all black with a single pixel white border and loaded it into the scenery. The resulting scenery looks like this: http://www.projects.34sp.com/Flightgear/tn/a-Black-grid.jpg.html *The boundaries of “texture areas” are built into the mesh itself* If you look at this image above KSFO http://www.projects.34sp.com/Flightgear/tn/textures-ksfo.jpg.html And then look at the mesh of the same scenery you can see that when terragear builds the scenery mesh the triangles not only create the height data, but they also define the texture areas. http://www.projects.34sp.com/Flightgear/tn/mesh-ksfo.jpg.html As well as using the vmap0 data as described in 3.3 of fg-scenery-tutorial (http://www.terragear.org/docs/scenery-tutorial/fg-scenery-tutorial.html) you can also create and define your own texture areas using the tguserdef command in conjunction with your own .xml file containing the required lat/long points. I created a grid of squares using tgusedef that exactly mimicked the mystery grid. I gave each square the property of LandMass. Unfortunately tguserdef won't let you assign custom textures that you have added in materials.xml, it fails unless you use one of the default texture definitions (this may have been fixed by now) This is a big drawback as it means you then have to find another way of subsequently changing the assigned texture for each individual triangle in the mesh. *Because the photo scenery provides all the land use data, you then only need to run a very simple version of the build e.g.* fgfs-tools-client --rude --min-angle=0 --output-dir=. --work-dir=. --port=33933 DEM-30 LandMass *Then when I viewed the mesh I had built I could see the squares built into the mesh.* I then cut up my photo image using chop.pl (/TerraGear/src/Prep/Photo) into pieces that corresponded with the grid I made. I added each photo square with the correct size to materials.xml Then using Flightgear Scenery Designer I manually re-assigned each triangle in the grid to correspond with the photo square I wanted to be in that position. Fire up FGFS and you have your photo scenery :-) http://www.projects.34sp.com/Flightgear/ begin:vcard fn:Mat Churchill n:Churchill;Mat email;internet:[EMAIL PROTECTED] tel;work:+44 (0) 207 8371019 tel;fax:+44 (0) 207 8372761 tel;cell:07971 505097 x-mozilla-html:TRUE version:2.1 end:vcard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Photo Scenery (txt)
Thought I'd post this reply to an email from Stacie re photo scenery so it will show up for anyone searching on the subject. Hi Stacie, The following is an outline of how I created the photo scenery. All the working out of things such as the size of the squares on the "mystery grid" was done purely by tedious trial and error. I can't write in any computer language such as perl, so I processed the figures for the larger grid of squares using a spreadsheet ! As such it is terrible route to getting photo imagery into Flightgear. Having said that it does work. It could be improved dramatically if a few things were in place. Two things would make the entire operation vastly simpler. 1. If someone was able to extract the lat/long information of the "mystery grid" from Flightgear and use this directly to create the grid of squares for the scenery build. 2. If tguserdef was able to attribute textures with any name then the manual re attribution of texture type to each triangle could be avoided. If I was doing this again I would try to get these two things resolved before I went ahead. Someone could then write a perl script to automate much of the following. Unfortunately I lost a hard drive not long after doing the photo scenery, so I don't have the spreadsheets or xml files I used. Also if the area you are building has coastline I also worked out a solution for getting that to look OK. Mat Churchill *Flightgear places textures inside a mystery grid* (that I don't fully understand). I have asked a couple of times on the forum and haven't got an answer as to what it is. Textures are assigned a size (amongst other things) in the materials.xml file. I think the ones with a size around 1000 seem to fit exactly into this grid, smaller ones are fitted into the grid multiple times. To show the grid I created a texture that was all black with a single pixel white border and loaded it into the scenery. The resulting scenery looks like this: http://www.projects.34sp.com/Flightgear/tn/a-Black-grid.jpg.html *The boundaries of “texture areas” are built into the mesh itself* If you look at this image above KSFO http://www.projects.34sp.com/Flightgear/tn/textures-ksfo.jpg.html And then look at the mesh of the same scenery you can see that when terragear builds the scenery mesh the triangles not only create the height data, but they also define the texture areas. http://www.projects.34sp.com/Flightgear/tn/mesh-ksfo.jpg.html As well as using the vmap0 data as described in 3.3 of fg-scenery-tutorial (http://www.terragear.org/docs/scenery-tutorial/fg-scenery-tutorial.html) you can also create and define your own texture areas using the tguserdef command in conjunction with your own .xml file containing the required lat/long points. **I created a grid of squares using tgusedef that exactly mimicked the mystery grid.** I gave each square the property of LandMass. Unfortunately tguserdef won't let you assign custom textures that you have added in materials.xml, it fails unless you use one of the default texture definitions (this may have been fixed by now) This is a big drawback as it means you then have to find another way of subsequently changing the assigned texture for each individual triangle in the mesh. * *Because the photo scenery provides all the land use data, you then only need to run a very simple version of the build e.g.** fgfs-tools-client --rude --min-angle=0 --output-dir=. --work-dir=. --port=33933 DEM-30 LandMass **Then when I viewed the mesh I had built I could see the squares built into the mesh*.* I then cut up my photo image using chop.pl (/TerraGear/src/Prep/Photo) into pieces that corresponded with the grid I made. I added each photo square with the correct size to materials.xml Then using Flightgear Scenery Designer I manually re-assigned each triangle in the grid to correspond with the photo square I wanted to be in that position. Fire up FGFS and you have your photo scenery :-) http://www.projects.34sp.com/Flightgear/ begin:vcard fn:Mat Churchill n:Churchill;Mat email;internet:[EMAIL PROTECTED] tel;work:+44 (0) 207 8371019 tel;fax:+44 (0) 207 8372761 tel;cell:07971 505097 x-mozilla-html:TRUE version:2.1 end:vcard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [EMAIL PROTECTED] Conference
I'd give a lot to know what these two papers are presenting! See below: Jon --- [EMAIL PROTECTED] Conference 26 - 29 Sep 2005 Hyatt Regency Crystal City Arlington, Virginia Session 71 COTS Software in Mission Critical Systems 0930 AIAA-2005-7108 Open Source Software: Cheap Isn't Exactly Free! B. Calloni, J. McGowan, and R. Stanley, Lockheed Martin Corporation, Fort Worth, TX 1000 AIAA-2005-7106 Bazaar Meets Cathedral: Concerns About Open Source Software in Mission Critical Systems [invited] R. Kwan, Lightsaber Computing, Fremont, CA ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [EMAIL PROTECTED] Conference
Jon Berndt wrote: I'd give a lot to know what these two papers are presenting! See below: Jon --- [EMAIL PROTECTED] Conference 26 - 29 Sep 2005 Hyatt Regency Crystal City Arlington, Virginia Session 71 COTS Software in Mission Critical Systems 0930 AIAA-2005-7108 Open Source Software: Cheap Isn't Exactly Free! B. Calloni, J. McGowan, and R. Stanley, Lockheed Martin Corporation, Fort Worth, TX One thing is for sure; this one isn't about Free Software since FOSS ain't cheap, it's Free! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [EMAIL PROTECTED] Conference
Jon S. Berndt wrote: > I'd give a lot to know what these two papers are presenting! See below: > > Open Source Software: Cheap Isn't Exactly Free! > B. Calloni, J. McGowan, and R. Stanley, Lockheed Martin > Corporation, Fort Worth, TX > > Bazaar Meets Cathedral: Concerns About Open Source Software in > Mission Critical Systems > R. Kwan, Lightsaber Computing, Fremont, CA Heh, that's amusing. This is a "follow the money" moment if I've ever seen one. Someone somewhere has a product that is about to be killed by free software. I found a bio page about the Rick Kwan guy here: he doesn't sound so scary: http://www.aiaa-sf.org/council/kwan_r.html It's possible we're just misreading the titles, and the talks aren't solely about OSS FUD. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [EMAIL PROTECTED] Conference
On Sun, 21 Aug 2005 07:48:35 -0500, Jon wrote in message <[EMAIL PROTECTED]>: > I'd give a lot to know what these two papers are presenting! See > below: ..looks a lot like FUD to me, best handled by Groklaw or the Nazgul. ;o) > [EMAIL PROTECTED] Conference > 26 - 29 Sep 2005 > Hyatt Regency Crystal City > Arlington, Virginia > > Session 71 COTS Software in Mission Critical Systems > > 0930 > AIAA-2005-7108 > Open Source Software: Cheap Isn't Exactly Free! > B. Calloni, J. McGowan, and R. Stanley, Lockheed Martin Corporation, > Fort Worth, TX > > 1000 > AIAA-2005-7106 > Bazaar Meets Cathedral: Concerns About Open Source Software in Mission > Critical Systems [invited] > R. Kwan, Lightsaber Computing, Fremont, CA -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Custom Scenery for Lake Constance
> However, those data did not make it to the current scenery release as > TerraGear choked, obviously due to the massive density of data. I'm > going to further investigate this - maybe with a little help from the > experts on this list - and I hope that we can at some point release at > least some compromise version between "nearly no linedata" and "<<1 FPS" > ;-) The current selection of the data subset kept is arbitrary and not > necessarily sensible. Try watching your virtual memory usage and see whether you're hitting the 2GB (or 3GB) limit within that process. If you are, it is worth patching TerraGear until it runs cleanly on all 64 bit architectures. If it isn't a memory problem, we can stick with the 32 bit for now. If memory _is_ the limiting factor, it is easy enough to take all the RAM of other computers on the network and make it available as swap space on the 64 bit machine that is actually building big scenery. Swapping over network to memory is a lot faster than to hard drive. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
