FlightGear wiki - User contributions [en]

File:Robin DR400-dauphin over Nantes.jpeg

2014-10-25T10:35:07Z

Saga: Link to Osm2city.py added

== Summary ==
{{File information
|Description = Robin DR400-dauphin over Nantes (buildings generated with [[Osm2city.py]] (program written by [[User:Radi|Radi]]). The nearest airport is LFRS.
|Source = Own work
|Date = 2014-11-25 10:27 (UTC)
|Author = Saga
}}
== Licensing ==
{{PD-self}}

[[Category:Screenshots_of_scenery_in_France]]

File:Robin DR400-dauphin over Nantes.jpeg

2014-10-25T10:33:19Z

Saga: Category specified

== Summary ==
{{File information
|Description = Robin DR400-dauphin over Nantes (buildings generated with osm2city.py (program written by [[User:Radi|Radi]]). The nearest airport is LFRS.
|Source = Own work
|Date = 2014-11-25 10:27 (UTC)
|Author = Saga
}}
== Licensing ==
{{PD-self}}

[[Category:Screenshots_of_scenery_in_France]]

Template:POTW/2014-44

2014-10-25T10:29:25Z

Saga: Created page with "{{POTW |image = Robin_DR400-dauphin_over_Nantes.jpeg |description = Nantes buildings in France generated with osm2city.py (nearest airport: LFRS). |article = Osm2cit..."

{{POTW
|image = Robin_DR400-dauphin_over_Nantes.jpeg
|description = Nantes buildings in France generated with osm2city.py (nearest airport: LFRS).
|article = Osm2city.py
}}<noinclude>[[Category:Picture of the week 2014]]<noinclude>

File:Robin DR400-dauphin over Nantes.jpeg

2014-10-25T10:26:54Z

Saga: {{File information |Description = Robin DR400-dauphin over Nantes (buildings generated with osm2city.py (program written by User:Radi|). The nearest airport is LFRS. |Source = Own work |Date = 2014-11-25 10:27 (UTC) |Author...

Switching default texture format to DDS

2014-09-09T18:35:44Z

Saga: libtxc_dxtn info updated

The FG development team is considering to '''switch the default format for textures from png to DDS'''. This would offer a number of significant advantages:

* DDS is a more compact format than png, hence the download size of the FG base package may be decreased
* Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption
* DDS stores all texture resolution levels, in essence no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
* The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use DDS for these reasons.

== Feedback needed - should FlightGear switch the defaults to DDS format for terrain texturing? ==
However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

{{FGCquote
|let's collect some some feedback [on DDS usage in FlightGear] until late November and restart this topic. We probably know by then what we do for the next release. "Somebody" needs to collect the feedback, however.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32791750/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-03</nowiki>
}}
}}

If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.
In other words, a lack of feedback from end users might very well mean that future FlightGear versions may require DDS support and may not necessarily work for people with outdated hardware - so if you care about backward compatibility, please do get involved, test DDS support and provide feedback!

=== What we need you to do? ===
FlightGear already provides the simple option to test a DDS texture set. If you are running on Linux and use an open source graphics driver, please take 5 minutes to help during your next FG session:

# Open the dialog under View -> Rendering
# Under 'Terrain texture scheme', change the default 'Region-specific' to 'Global alternative (DDS format)'
# Press 'Okay' - FG will reload the terrain
# Do you see proper textures on the terrain (they may look different and may also not fit the location perfectly)? If yes, you're fine. If you see monochromatic, or even bright/pink, colors or other rendering artifacts, your system may have problems with DDS.
# Change back to the texture scheme you like best
# Enter your experiences in the list below

Thanks for your help!

== Tested hardware and graphics drivers ==
=== NVIDIA proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GTX 670M
|310.19
|{{yes}}
|ThorstenR
|-
|N13M-NS Optimus
|340.32
|{{yes}}
|Tom_ch
|-
|GeForce GT 640
|343.13
|{{yes}}
|lumni1968
|-
|GeForce GTX 780 Ti
|340.52
|{{yes}}
|Avionyx
|-
|GeForce GT 750M
|331.38
|{{yes}}
|Dutchguy
|-
|GeForce GT 620 OEM
|331.38
|{{yes}}
|C-GGKV
|-
|GeForce GTX 650
|331.20
|{{yes}}
|dany93
|-
|GeForce 210
|304.117
|{{yes}}
|Jean-Philippe
|-
|GeForce GT 520
|332.21
|{{yes}}
|cossack90
|-
|GeForce GTS 250
|331.38
|{{yes}}
|Madbyte
|-
|GeForce GTS 450
|340.32
|{{yes}}
|chris_blues
|-
|GeForce 8600 GT
|340.32
|{{yes}}
|szpajder
|-
|GeForce GTX 460 SE
|331.38
|{{yes}}
|f-jjth
|-
|GeForce GTX 560 Ti
|319.32
|{{yes}}
|PATTEN
|-
|GeForce 8600 GT
|304.117
|{{yes}}
|attila
|-
|GeForce GTX 750 ti
|340.32
|{{yes}}
|f-toro
|-
|GeForce GT 650M
|Apple OS 10.9.4
|{{No}}
|dersh
|-
|GeForce 9800GTX
|304.117
|{{yes}}
|ctec356
|}

=== NVIDIA open source driver (Nouveau)===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GT 630
|
|{{no}}
|[https://plus.google.com/111978238381658236898/posts/VYSusMLRiH2 Jakub Klawiter]
|-
|}

=== Intel proprietary driver ===

=== Intel open source driver ===
{| class="wikitable sortable"
!Card
!Driver
!libtxc_dxtn installed?
!DDS ok
!Reported by
|-
|HD Graphics 3000 (i7-2600K)
|10.2.6
|{{n/a}}
|{{yes}}
|cdesai
|-
|HD Graphics 3000 (i3-2330M)
|10.2.2
|{{n/a}}
|{{yes}}
|Flyhigh/saiarcot895
|-
|HD Graphics Sandy Bridge (Pentium B980)
|10.1.0
|{{no}}
|{{yes}}
|f-jjth
|}

=== ATI/AMD proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|ATI Radeon HD 6310
|14.6-1
|{{yes}}
|ZLSA
|-
|AMD Radeon R9 200 Series
|14.4
|{{yes}}
|Richi
|-
|Radeon HD 4850/4870
|legacy 8.97.100.7-4
|{{yes}}
|Jano
|}

=== ATI/AMD open source driver ===
{| class="wikitable sortable"
!Card
!Driver
!libtxc_dxtn installed?
!DDS ok
!Reported by
|-
|AMD Radeon HD 7950
|10.2.1
|{{yes}}
|{{yes}}
|Saga
|-
|AMD Radeon R9 270X
|10.3~git20140805
|{{no}}
|{{no}}
|nine
|-
|AMD Radeon R9 270X
|10.3~git20140805
|{{yes}}
|{{yes}}
|nine
|}

== Sample test ==
=== DDS Test at the airport of Orio (Bergamo - Italy) ===
[[File:Terrain texture scheme DDS 01-2000.jpg|800px|thumb|Comparison of texture in relation to the three possible choices in "Rendering Options" -> "Terrain texture scheme"]]The final result, with all the "Shader Options" active, is not very satisfactory, I would say very poor. Apparently not check on any improvement in the speed of image loading. I think on modern machines with quad-core processors 16 GB, with latest graphics cards (NVIDIA 870) 6 GB, the loading of these images is not really a "bottleneck". I propose to insert the DDS functionality, but in a transparent way, ie convert "on the fly" the images before inserting them into the temporary memory, for example using the convert function of ImageMagick. However, I do not know if it really is a useful feature, I think there are many other things to do before this. These are the parameters used by the startup script "run_fgrun.sh":
{{Note|To reproduce this test, you can use the following [[Fgfsrc]] file - you should set up [[$FG_ROOT]] and [[$FG_SCENERY]] specifically for your own system though.}}
<code>
--airport=LIME
--aircraft=757-200-PW2040
--disable-random-objects
--enable-horizon-effect
--enable-enhanced-lighting
--enable-distance-attenuation
--enable-ai-models
--disable-ai-traffic
--disable-real-weather-fetch
--enable-clouds3d
--bpp=32
--texture-filtering=16
--prop:/sim/rendering/multi-sample-buffers=1
--prop:/sim/rendering/multi-samples=4
--timeofday=noon
--enable-terrasync
--httpd=5500
--props=5501
--jpg-httpd=5502
--multiplay=out,10,,0
--multiplay=in,10,,0
--disable-fgcom
</code>

== Excerpts from the ongoing discussion ==
{{FGCquote
|Here is my suggestion how to proceed:

* Let's do your 1) and 2) on as many information channels we have.
* Collect the responses on a public place, I'd suggest a wiki page
* Do this for a well defined time frame. Is three month too much/too short?
* If we have the impression, it's safe to switch to DDS, define the dds texture sets as default, keeping the png sets as a fallback and publish how to use this fallback
* Keep this for one release.
* Depending on the feedback we get, keep it that way or move entirely to DDS.

Does that sound reasonable for everybody?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32788459/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Misc ==
{{FGCquote
|I'd propose [...] this process:
# Get out the information first that one can change materials files, where to do it and what the characteristics of the different sets are.
# Ask users (especially those running with ATI or Intel on Linux) nicely to do a quick check whether dds works fine.

I think we have an information management problem in relation to the user base - a frequent forum situation is that a user requests something that's already there, but the information is just not out. So if we even envision such a change, I would start spreading the relevant information basically yesterday.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== DDS Debate in 2012 ==
=== Legalities ===
{{See also|Talk:Switching default texture format to DDS#Using patented algorithms}}

{{FGCquote
|These kind of precompressed images limits their usage to a specific set of 
drivers. And no, due to the patent issues no open source code including ours 
is allowed to implement compression/decompression code for these image 
formats. Even if this is easy implementation wise.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|t is technically incorrect to provide these s3 patent 
precompressed textures to a driver that does not announce the apropriate 
extension and since we are not allowed to code something that deompresses 
this, I think we should avoid using this compression for all the provided 
models/textures. 
 
I think of a warning that is issued from the image loader in flightgear that 
detects when these precompressed textures are seen. So even people using 
drivers that just offer this extension have a chance to see that the provided 
textures will not work for others.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612879/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-01</nowiki>
}}
}}

=== Portability Concerns ===
{{FGCquote
|These kind of precompressed images limits their usage to a specific set of 
drivers. And no, due to the patent issues no open source code including ours 
is allowed to implement compression/decompression code for these image 
formats. Even if this is easy implementation wise.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|And this is what I try to do now: 
Object against using these patented compression algorithms. 
I do not care for the on disk format of any image file we have. But the problem 
is that some kind of precompression that can be stored in these dds files 
cannot be used with other drivers than the closed ati and nvidia ones. 
As long as these patented compression techiques are not used, every OpenGL 
driver can use this and displays this fine. 
 
Think: Intel has the hugest marketshare in graphics today. If I remember 
right, they sell more than ati and nvidia together (*). This kind of change in 
effect rules out the majority of users as intel cannot work with these files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|It's not limited to dds. If you use osgconv xxx.dds xxx.ivs you will probably 
have the same effect. So I think simply ommitting DDS is ok? 
 
Also, much more important, the comment is not about 'your video driver'. It is 
in your (Vivian) case even wrong. Your driver will display this fine. 
So, in the end I do not care if it is 'your particular video driver' that does 
not like this. You will just see this in the best case as the models look 
wrong, and in the worst case fgfs just crashes the driver if these textures 
are used. 
What I really care about is that these files are expected not to work on a huge 
amount of graphics boards out there. The point is to tell people doing 
textures that they should omit compression so that this message disapears.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|I would like to have a flightgear that is by default just running on every 
average system. Having this run faster on a special configured system with some 
better configuration options and hand tuned hardware and drivers is very fine. 
But without tuning it must at least work in an acceptable way. 
 
I have checked in a change to flightgear to make the use of the compressed 
internal formats a starttime configuration option. 
I am still interrested if we have that hangs also with texture compression 
disabled and without providing precompressed dds textures?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28602775/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|this is the reason for the message. If your machine would refuse to display this you, 
developing that, would probably just say 'nice try, but it does not work' 
before you check in something. In the case it displays fine, you probably say 
'it works here, so I assume it works also for others, lets do'. 
And the message tells you, 'despite of just seeing this working on this 
current machine, it does not work for others'.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Seriously, I think plenty people not being on this list today and probably 
never will be in touch with anybody here, will run into this issue. 
People here are those few guys from the power users that want to develop this 
stuff. 
 
I am not going to discuss the patent stuff. Please search the mesa-dev archives 
for the discussion and see there why they think that the nvidia tools and 
other stuff out there cannot be used. Really - it is not that the code for that 
is too dificult or unavailable. I am not a lawyer and I cannot change this 
world - even if I would like to in this regard. 
 
I agree that techically for drivers/gpus supporting these compression formats 
it would be best to use these precompressed files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Seriously, I think plenty people not being on this list today and probably 
never will be in touch with anybody here, will run into this issue. 
People here are those few guys from the power users that want to develop this 
stuff.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Your driver will display this fine. 
So, in the end I do not care if it is 'your particular video driver' that does 
not like this. You will just see this in the best case as the models look 
wrong, and in the worst case fgfs just crashes the driver if these textures 
are used. 
What I really care about is that these files are expected not to work on a huge 
amount of graphics boards out there. The point is to tell people doing 
textures that they should omit compression so that this message disapears.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

=== Approaches ===
{{FGCquote
|Well, the default f16 does not work anymore for example. 
I have also never tried the new textures, but I assume that these also contain 
precompressed data? Also you claimed that the old texture files start to bitrot 
comared to the new ones which makes me think that the new standard should be 
the dds files. This together makes me think that the dds files should replace 
the traditional image files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|Hmm, regarding dds. 
I have to say, that not all OpenGL drivers support texture compression, and 
the models with dds files, are those that I cannot display, because of that. 
And in fact this will not happen to the open source drivers before something 
about 2020 because of patent issues. 
 
Sorry to step in this so late - probably way too late - but is there a reason 
that the on disk format must be compressed? 
The previous strategy to have on disk an format that everybody can read and to 
make the driver compress them as needed/possible is better I think? 
 
So, for me the f16 lost its livery lately - where I can live with this for the 
f16, I hope that this does not happen to flightgear as a whole ...
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28594472/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-27</nowiki>
}}
}}

{{FGCquote
|Well, I hope that we can get rid of the compression. 
Can somebody with the apropriate tools convert the compressed textures to non 
compressed ones? That could still be dds, but dds without these compressions 
that produce the warning. So no problem with cubemaps in dds as long as the 
compression is not there. 
Then *everybody* is again able to use this stuff.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678109/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|I can see several approaches: 
 
* Just do not use the patented compression stuff. The precomputed mipmaps could 
probably do the job of avoiding the hangs (hopefully? to be checked?). May be 
we could lower disk space usage by providing a dds.gz or similar wrapper? 
 
* If it's just the mipmaps. May be we can precompute the mipmaps using the cpu 
in the database loader thread. This would help all textures not only the ones 
that could be converted. May be this is the most generic solution. 
 
* Implement some kind of image lookup order that knows if the compressed files 
could be handled or not. On loading an image in case of available compression 
first try to find a dds file with the same name of the original one. That 
involves some 'magic' which often leads to problems but that could at least 
work.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &
buildings)</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

{{FGCquote
|Next step is to make sure that compression is not required to avoid the hangs. 
My favorite bet would be that then the new configure option regarding texture 
compression needs to be set to none.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &
buildings)</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

=== Precomputed mipmaps ===
{{FGCquote
|Could we do dds files without compression but with precomputed mipmaps? 
 
So at next, can you try out which combination of compression/provided 
mipmaps/forced simgear compression still work fine?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28603114/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|The 4. Method that I can imagine is to precompute the mipmaps in the loader. 
IIRC tests with some of the guys suffering from this problem, providing 
premipmapped but uncompressed dds files had helped to get a fluent viewer. 
The argument against providing these dds files in general was that these files 
are really huge because of not including any compression and having all the 
mipmaps. 
But that means we could at the point where the warning happens compute the 
mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be 
used to do this I think (or something similar not requireing a context). This 
one is an imported version of the original glu function that is included in 
osg for running on an EGL stack which no longer provides GLU. 
That is take the image scale this to the 1st mipmap, take the 1.st mipmap and 
scale this to the 2. mipmap and so forth. 
 
This would have the advantage that the png's do not deviate from the dds files 
over time.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571679/
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-07-21</nowiki>
}}
}}

{{FGCquote
|I think then, computing mipmaps for any texture file on the CPU in the loader 
thread should globally improove the situation. 
Also avoiding the compression already in the files should help every use case. 
Except that the on disk memory consumption is higher. 
Well and except that the database loader has more work to do on the CPU.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612897/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-01</nowiki>
}}
}}

{{FGCquote
|Doing that differently will provide some overhead that could be kept at a 
minimum I think: 
For the disk usage, I think gzip compressing these will work sufficiently fine. 
Ram usage of the images should not hurt too much. Sure the images are bigger 
in memory. But fgfs is not just about images - far from that. 
On the GPU, you can still use compression for the textures as the internal 
format. This is what flightgear tries to do if the extension is supported 
(checked by osg). 
 
The major point is that there are several ways that use slightly more 
resources to get around this problem. 
But once the patented compression is on disk, there is *no* way back for 
people not having this feature. 
 
If you have better ideas that do not rule out intel and the oss drivers, you 
are welcome!
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|On unix I usually get the gzip plugin installed by osg (osgdb_gz.so). Is this 
also the case for the default win32 case? Is there a osgdb_gz.dll or something 
along the lines in the directory containing the plugins? 
 
If yes, we can already tackle the size problem of the uncompressed dds files on 
disk by just gzip compressing these makging a xxx.dds.gz from a xxx.dds and 
just refering to xxx.dds.gz instead of xxx.dds. At least this works fine here. 
And I assume that this works fine for all unix like operating systems including 
mac?! 
James?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|What about solution 6 with (uncompressed premipmapped dds).gz? 
On linux this should work as long as you have zlib installed which could be 
regarded as a system library there. 
Can we rely on zlib being compield into our osg distributions on win32? We do 
need zlib in any case, it's mostly about teaching osg that it finds our zlib on 
configure and build the gz plugin.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571819/
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-07-21</nowiki>
}}
}}

{{FGCquote
|I implemented a mipmap control and generation tool in effects when I last updated 
the urban shader. For the moment, it relies on hardware when the average operator 
is used for all texture channels but it could easily be modified to compute 
all mipmap on the CPU. look the <mipmap-control> effect option and 
mipmap.[ch]xx in SG material lib
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606692/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees
& buildings)</nowiki>
|author=<nowiki>Frederic Bouvier</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

== Implementation ==
{{FGCquote
|As has been previously pointed out, the current DDS texture set is not 
simply the global png texture set converted. 
 
For our own sanity and those of the users, we need to ensure that there's 
an apples-to-apples comparison being made when we change the default. I 
therefore think we need to create a DDS version of the current default 
texture set.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|2) If we go down this path, we probably want to separate the underlying 
texture format from the materials.xml definition entirely. For example, we 
could simply remove the extention from the materials definition, and have 
the C++ code append the appropriate extension based on a separate property. 
This has a couple of advantages: 
a) Makes testing easier and materials definitions less error-prone. 
Assuming we have some batch job in place to generate dds textures, those 
working on materials definitions could continue to work with png textures, 
and only convert to dds as a final step (or indeed as part of the "make 
release" jobs). 
a) Avoids duplication of materials definitions. Having just spent quite a 
bit of time making the materials definitions more efficient, I'd like to 
avoid making it worse again! 
 
I'm quite happy to do the C++ coding required for this in the materials 
loader - it's probably pretty straightforward.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|That does leave the issue of what happens to the existing dds texture 
definitions where there are special mipmap layers. I'd suggest that we 
have some Clever Script (tm) that is able to work out whether the DDS or 
PNG version of a texture is the master, and then generate the other version 
from it. I admit that the PNG conversion of the DDS will lose some 
information in this process, but it would allow those without DDS support 
to at least use the textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|3) We need a sensible process for dealing with aircraft, which has been 
identified as a significant issue. Again, I think more aircraft developers 
find .png easier to deal with, and there are a lot of aircraft out there 
that would need conversion. It feels like we need some build scripts to 
"compile" aircraft to use DDS textures. 
 
A more far-fetched idea might be to have a cache of dds textures that are 
generated on-the-fly, or when aircraft are loaded by the aircraft center. 
Clearly that impacts initial load time the first time a new aircraft is 
loaded, and would increase the size of .fgfs/ directories massively, but it 
would remove the need for any work by aircraft/scenery developers and could 
be made optional. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

== Challenges ==
{{FGCquote
|"dds on an open source driver (radeon and intel) I was forced to use radeon at some time, and it was fun, the planes were pink :) once libtxc-dxtn installed, dds were loaded fine again, so it can be used on open source if you are ok to use the lib." 
 
Unless there's some way to make sure Linux users have that lib installed automatically, I'd say that's a no. We can't have a random user guess what additional packages to install. And maybe someone can educate me - googling the lib, this appears to be working for mesa - which usually is what we try to avoid if users do 3d rendering via mesa for performance reasons? 
 
Also, what does 'If you are okay to use the lib' mean precisely? If that's some piece of code which circumvents a patented thing and isn't exactly legal and needs to be obtained from special servers outside the normal repo (sort of like the DVD decryption under Linux), then I doubt that's an option. Can anyone clarify?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32786414/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Another potential option would be to convert regions to .dds but keep 
both global-png and global-dds, but making that user-friendly would 
require a way to automatically detect lack of .dds support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|On my system (Intel Ivybridge), DDS works with or without libtxc, but 
this may not be true of all Intel hardware. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|You can specify the dependency on libtxc_dxtn, but then distributions like 
openSUSE cannot ship FlightGear anymore. libtxc_dxtn implements S3 texture 
compression which is patented in many parts of the world. Linux distributions 
therefore cannot ship it. You can easily find it in add-on repositories, but 
as I said, distributions would not be able to include FlightGear creating a 
huge hurdle to installation for users.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787143/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Stefan Seifert</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Debian/Ubuntu's libtxc is libtxc-dxtn-s2tc, which claims to avoid the 
patent at a small cost in visual quality: 
https://github.com/divVerent/s2tc/wiki/libtxc_dxtn 
That site also states that modern hardware doesn't need this software 
fallback anyway (and hence won't hit either this quality loss or the 
slowness of any software decoder), but doesn't define "modern hardware".
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787296/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|The dds textures seem to have some advantages over our png textures and 
using them is tempting. 
But the points from Thorsten R. are good points and if there is any 
chance to have a step-wise transition to the new format, I'd prefer that 
path. 
 
Don't we have an alternate dds texture set already in fgdata that is 
enabled with an option? What about making this the default, keeping the 
png texture set as an alternate. That would get us reports from users 
unable to run dds textures and provide an easy fallback method.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787378/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|We currently have regions-png, global-png and global-dds; as I noted 
earlier, switching to regions-dds, global-png and global-dds has the 
issue that while changing the texture set is easy (dropdown in View > 
Rendering Options), knowing that one needs to do so may not be.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787717/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Can we invert the logic in, say, preferences.xml so xxx-dds is enabled 
by default and switching to xxx-png has to be done in rendering options? 
 
Torsten
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787787/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Changing the default (which is in preferences.xml) is easy: the problem 
is how do users with non-.dds-supporting hardware (if this exists) know 
they need to change back.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787851/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Conversion ==
Also see [[DDS texture conversion]].

{{FGCquote
|the script take the .dds and not convert the png again if both exist(I remember having manually used "compare" to check if both the dds and the png looks the same, and if not i changed some names) 
 
notice that the normal maps are a particular case as you need to tell the effect the texture is dds with a line like: 
 
1 
 
 
just be sure to include this in the normal map effects with png and it will be easier: 
 
0 
 
 
about FG doing the dds conversion , nvcompress is told to be gpl compatible, but i'm not an expert here: 
 
http://nvidia-texture-tools.googlecode.com/svn/trunk/NVIDIA_Texture_Tools_README.txt 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32799214/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean pellotier</nowiki>
|date=<nowiki>2014-09-05</nowiki>
}}
}}

{{FGCquote
|I think this is an inheritance from some other game engine using a different convention, and therefore from the authoring tools that were developed for such an engine (photoshop exporter plugins and the like). If indeed the FGFS DDS textures are only meant to be used in FGFS then this should be fixed at the conversion time. Otherwise, if we want other applications to easily reuse the FGFS textures then it would be better to stick to the most common convention. But I think we all agree that the source for any DDS texture should be kept, which pretty much precludes importing ready made DDS textures from 3rd party sources. Incidentally I think importing DDS artwork from other sources should be discouraged, since it will most likely run afoul of the licensing terms of the original copyright owner.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32799324/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>TDO Brandano</nowiki>
|date=<nowiki>2014-09-05</nowiki>
}}
}}

Nothing as exotic. Just a different "origin" between OpenGL and Direct3D image conventions. OpenGL image origin is located in the lower-left corner, while Direct3D (hence DDS too) considers the top-left as the origin, resulting in a DDS image to appear vertically flipped when read in an OpenGL context. This has repercussions in the way normal-map decoded normals appear (hence the flag in the effects, which signals to the shader to flip the decoded normals). The rest is simply a matter of workflow: either use flipped coordinates and skewed/reversed conventions throughout your whole workflow, or just flip the image and (eventually) set a flag for the shader at "publish" time (said flag could be automatically set by the code on DDS texture load). ''(the latter seems more pragmatic/appealing)''

{{FGCquote
|Automatic conversion script is welcome indeed. Also I'm pretty sure that we have some people here ready to convert a PNG to DDS as soon as you say "Hey boys I created a new PNG file, can you convert this file for me please ?" :-)
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785592/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Clement de l'Hamaide</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|A few world about the conversion: once a png/rgb/jpg found, the script 
try to guess the suitable dds format: with or without alpha channel, 
bumpmap, if a .dds is allready found we just erase the png one, if not 
we use nvcompress to get the dds. After we change the textures name 
called in the differents files and that's it. There's a way to tell the 
script what to do for each file, if the automatic mode is a failure. 
 
I guess speaking theorically is not the best to make an opinion, so if 
some of you are interested to make a test, I will make a 3.2 minimal dds 
fgdata this we, once on my FG pc.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Pros ==
{{FGCquote
|I always got a loading problem with png textures, large textures take 
seconds to load and convert, and that ruin my close flight where you 
can't afford to take pause in the air. 
that's why i did a batch script to convert to dds ALL the textures in 
the data, not only the matérial set, but everything. Now i only flight a 
dds version of flightgear, and am quite happy with it, that's why i 
propose to provide a dds fgdata for test, and maybe to make it an 
alternate download possibility.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Cons ==
{{FGCquote
|FG actually runs with dds textures, it just doesn't render anything reasonable, I believe you get monochromatic colors. But I don't expect the menu to be affected, it doesn't use textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|If it's relevant, I recall having S2TC compression problems when running Flightgear, and updating this package to a newer version manually (outside of the main repos) fixed the issue. I'm on an Intel HD 3000, but I'm guessing that Intel HD 4000 doesn't have this problem, since it seems to have better OpenGL and OpenCL support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787875/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Saikrishna Arcot</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

[[Category:Core development projects]]

Switching default texture format to DDS

2014-09-04T18:09:26Z

Saga: Work very well with my GPU and FG3.0

{{Note|
{{FGCquote
|let's collect some some feedback [on DDS usage in FlightGear] until late November and restart this topic. We probably know by then what we do for the next release. "Somebody" needs to collect the feedback, however.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32791750/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-03</nowiki>
}}
}}
}}

{{WIP}}

== Feedback needed - should Flightgear switch the defaults to dds format for terrain texturing? ==

=== What is this about? ===

The FG development team is considering to switch the format for terrain textures from png to dds. This would offer a number of significant advantages:

* dds is a compressed format, hence the download size of the FG base package may be decreased
* compressed dds can be directly used by many graphics cards, reducing also GPU memory consumption
* dds stores all texture resolution levels, i.e. no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
* the resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use dds for these reasons.

However, the dds compression algorithm is patented, which means that it is not readily available for OpenSource graphics drivers used by Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process dds, for older graphics cards there are non-patented workarounds available which decompress the dds on the software level). The development team is concerned about making the Flightgear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

If there are no problems reported, FG will change defaults to textures in dds format with the 3.4 release, and then phase out the use of png textures.

== What would we need? ==

Flightgear already provides the simple option to test a dds texture set. If you are running on Linux and use an OpenSource graphics driver, please take 5 minutes to help during your next FG session:

* Open the dialog under View -> Rendering

* Under 'Terrain texture scheme', change the default 'Region-specific' to 'Global alternative (DDS format)'

* Press 'Okay' - FG will reload the terrain

* Do you see proper textures on the terrain (they may look different and may also not fit the location perfectly)? If yes, you're fine. If you see monochromatic colors or other rendering artifacts, your system may have problems with dds.

* Change back to the texture scheme you like best

* Enter your experiences in the list below

Thanks for your help!

== Tested hardware and graphis drivers ==
{{Note|Please add your own hardware/results here !}}

=== NVIDIA proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GTX 670M
|310.19
|{{yes}}
|ThorstenR
|-
|GeForce GT 540M
|331.82
|{{yes}}
|Gijs
|-
|N13M-NS Optimus
|340.32
|{{yes}}
|Tom_ch
|-
|GeForce GT640
|343.13
|{{yes}}
|lumni1968
|-
|GeForce GTX 780 Ti
|340.52
|{{yes}}
|Avionyx
|-
|GeForce GT 750M
|331.38
|{{yes}}
|Dutchguy
|}

=== NVIDIA OpenSource driver ===

=== Intel proprietary driver ===

=== Intel OpenSource driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|HD Graphics 3000 (i7-2600K)
|10.2.6
|{{yes}}
|cdesai
|}

=== ATI/AMD proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|ATI Radeon HD 6310
|14.6-1
|{{yes}}
|ZLSA
|}

=== ATI/AMD OpenSource driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|AMD Radeon HD 7950
|10.2.1
|{{yes}}
|Saga
|}

== Excerpts from the ongoing discussion ==

{{FGCquote
|Here is my suggestion how to proceed:

* Let's do your 1) and 2) on as many information channels we have.
* Collect the responses on a public place, I'd suggest a wiki page
* Do this for a well defined time frame. Is three month too much/too short?
* If we have the impression, it's safe to switch to DDS, define the dds texture sets as default, keeping the png sets as a fallback and publish how to use this fallback
* Keep this for one release.
* Depending on the feedback we get, keep it that way or move entirely to DDS.

Does that sound reasonable for everybody?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32788459/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Misc ==
{{FGCquote
|I'd propose [...] this process:
# Get out the information first that one can change materials files, where to do it and what the characteristics of the different sets are.
# Ask users (especially those running with ATI or Intel on Linux) nicely to do a quick check whether dds works fine.

I think we have an information management problem in relation to the user base - a frequent forum situation is that a user requests something that's already there, but the information is just not out. So if we even envision such a change, I would start spreading the relevant information basically yesterday.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== DDS Debate in 2012 (points made by Mathias)==

=== Portability Concerns ===
These kind of precompressed images limits their usage to a specific set of drivers. And no, due to the patent issues no open source code including ours
is allowed to implement compression/decompression code for these image formats. Even if this is easy implementation wise.

I do not care for the on disk format of any image file we have. But the problem is that some kind of precompression that can be stored in these dds files
cannot be used with other drivers than the closed ati and nvidia ones. As long as these patented compression techiques are not used, every OpenGL
driver can use this and displays this fine.

Think: Intel has the hugest marketshare in graphics today. If I remember right, they sell more than ati and nvidia together (*). This kind of change in
effect rules out the majority of users as intel cannot work with these files.

(*) There are several statistics out there, this is the intel one that counts all sold computers. AMD does usually counts the revenue made with graphics
boards (where ati wins I believe) or nvidia that usually limit statistics to professional systems (where nvidia wins).

I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some
better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way.

I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option.
I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures?

this is the reason for the (warning) message. If your machine would refuse to display this you, developing that, would probably just say 'nice try, but it does not work' before you check in something. In the case it displays fine, you probably say 'it works here, so I assume it works also for others, lets do'.
And the message tells you, 'despite of just seeing this working on this current machine, it does not work for others'.

Seriously, I think plenty people not being on this list today and probably never will be in touch with anybody here, will run into this issue.
People here are those few guys from the power users that want to develop this stuff.

Your driver will display this fine. So, in the end I do not care if it is 'your particular video driver' that does
not like this. You will just see this in the best case as the models look wrong, and in the worst case fgfs just crashes the driver if these textures
are used. What I really care about is that these files are expected not to work on a huge amount of graphics boards out there. The point is to tell people doing
textures that they should omit compression so that this message disapears.

The motivation behind this mentioned change is to sort out the best compromise so that the hangs hopefully disappear - which I hope to get with precomputed
mipmaps - and being able to display fine with any driver/gpu.

=== Approaches ===
Ideas raised by Mathias in 2012 [https://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg35523.html]:

I have to say, that not all OpenGL drivers support texture compression, and the models with dds files, are those that I cannot display, because of that.
And in fact this will not happen to the open source drivers before something about 2020 because of patent issues.

Sorry to step in this so late - probably way too late - but is there a reason that the on disk format must be compressed?
The previous strategy to have on disk an format that everybody can read and to make the driver compress them as needed/possible is better I think?

I hope that we can get rid of the compression. Can somebody with the apropriate tools convert the compressed textures to non compressed ones? That could still be dds, but dds without these compressions that produce the warning. So no problem with cubemaps in dds as long as the
compression is not there. Then *everybody* is again able to use this stuff.

* Just do not use the patented compression stuff. The precomputed mipmaps could probably do the job of avoiding the hangs (hopefully? to be checked?). May be we could lower disk space usage by providing a dds.gz or similar wrapper?

* If it's just the mipmaps. May be we can precompute the mipmaps using the cpu in the database loader thread. This would help all textures not only the ones that could be converted. May be this is the most generic solution.

* Implement some kind of image lookup order that knows if the compressed files could be handled or not. On loading an image in case of available compression
first try to find a dds file with the same name of the original one. That involves some 'magic' which often leads to problems but that could at least work.

Other ideas? Also may be creative ones?

Next step is to make sure that compression is not required to avoid the hangs. My favorite bet would be that then the new configure option regarding texture compression needs to be set to none.

=== Precomputed mipmaps ===
points made by Mathias in 2012[https://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg37848.html]:

Could we do dds files without compression but with precomputed mipmaps?

So at next, can you try out which combination of compression/provided mipmaps/forced simgear compression still work fine?

"precompute the mipmaps in the loader. IIRC tests with some of the guys suffering from this problem, providing premipmapped but uncompressed dds files had helped to get a fluent viewer. The argument against providing these dds files in general was that these files are really huge because of not including any compression and having all the mipmaps. But that means we could at the point where the warning happens compute the mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be
used to do this I think (or something similar not requireing a context). This one is an imported version of the original glu function that is included in
osg for running on an EGL stack which no longer provides GLU. That is take the image scale this to the 1st mipmap, take the 1.st mipmap and scale this to the 2. mipmap and so forth.
This would have the advantage that the png's do not deviate from the dds files over time."

computing mipmaps for any texture file on the CPU in the loader thread should globally improove the situation.
Also avoiding the compression already in the files should help every use case. Except that the on disk memory consumption is higher. Well and except that the database loader has more work to do on the CPU.

Doing that differently will provide some overhead that could be kept at a minimum I think:
For the disk usage, I think gzip compressing these will work sufficiently fine. Ram usage of the images should not hurt too much. Sure the images are bigger
in memory. But fgfs is not just about images - far from that. On the GPU, you can still use compression for the textures as the internal
format. This is what flightgear tries to do if the extension is supported (checked by osg).

The major point is that there are several ways that use slightly more resources to get around this problem.
But once the patented compression is on disk, there is *no* way back for people not having this feature.

If you have better ideas that do not rule out intel and the oss drivers, you are welcome!

On linux this should work as long as you have zlib installed which could be regarded as a system library there. Can we rely on zlib being compield into our osg distributions on win32? We do need zlib in any case, it's mostly about teaching osg that it finds our zlib on configure and build the gz plugin.

FredB implemented a mipmap control and generation tool in effects when he last updated the urban shader. For the moment, it relies on hardware when the average operator is used for all texture channels but it could easily be modified to compute all mipmap on the CPU. look the <mipmap-control> effect option and
mipmap.[ch]xx in SG material lib

== Challenges ==
{{FGCquote
|"dds on an open source driver (radeon and intel) I was forced to use radeon at some time, and it was fun, the planes were pink :) once libtxc-dxtn installed, dds were loaded fine again, so it can be used on open source if you are ok to use the lib." 
 
Unless there's some way to make sure Linux users have that lib installed automatically, I'd say that's a no. We can't have a random user guess what additional packages to install. And maybe someone can educate me - googling the lib, this appears to be working for mesa - which usually is what we try to avoid if users do 3d rendering via mesa for performance reasons? 
 
Also, what does 'If you are okay to use the lib' mean precisely? If that's some piece of code which circumvents a patented thing and isn't exactly legal and needs to be obtained from special servers outside the normal repo (sort of like the DVD decryption under Linux), then I doubt that's an option. Can anyone clarify?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32786414/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Another potential option would be to convert regions to .dds but keep 
both global-png and global-dds, but making that user-friendly would 
require a way to automatically detect lack of .dds support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|On my system (Intel Ivybridge), DDS works with or without libtxc, but 
this may not be true of all Intel hardware. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|You can specify the dependency on libtxc_dxtn, but then distributions like 
openSUSE cannot ship FlightGear anymore. libtxc_dxtn implements S3 texture 
compression which is patented in many parts of the world. Linux distributions 
therefore cannot ship it. You can easily find it in add-on repositories, but 
as I said, distributions would not be able to include FlightGear creating a 
huge hurdle to installation for users.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787143/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Stefan Seifert</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Debian/Ubuntu's libtxc is libtxc-dxtn-s2tc, which claims to avoid the 
patent at a small cost in visual quality: 
https://github.com/divVerent/s2tc/wiki/libtxc_dxtn 
That site also states that modern hardware doesn't need this software 
fallback anyway (and hence won't hit either this quality loss or the 
slowness of any software decoder), but doesn't define "modern hardware".
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787296/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|The dds textures seem to have some advantages over our png textures and 
using them is tempting. 
But the points from Thorsten R. are good points and if there is any 
chance to have a step-wise transition to the new format, I'd prefer that 
path. 
 
Don't we have an alternate dds texture set already in fgdata that is 
enabled with an option? What about making this the default, keeping the 
png texture set as an alternate. That would get us reports from users 
unable to run dds textures and provide an easy fallback method.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787378/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|We currently have regions-png, global-png and global-dds; as I noted 
earlier, switching to regions-dds, global-png and global-dds has the 
issue that while changing the texture set is easy (dropdown in View > 
Rendering Options), knowing that one needs to do so may not be.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787717/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Can we invert the logic in, say, preferences.xml so xxx-dds is enabled 
by default and switching to xxx-png has to be done in rendering options? 
 
Torsten
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787787/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Changing the default (which is in preferences.xml) is easy: the problem 
is how do users with non-.dds-supporting hardware (if this exists) know 
they need to change back.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787851/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Conversion ==
{{FGCquote
|Automatic conversion script is welcome indeed. Also I'm pretty sure that we have some people here ready to convert a PNG to DDS as soon as you say "Hey boys I created a new PNG file, can you convert this file for me please ?" :-)
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785592/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Clement de l'Hamaide</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|A few world about the conversion: once a png/rgb/jpg found, the script 
try to guess the suitable dds format: with or without alpha channel, 
bumpmap, if a .dds is allready found we just erase the png one, if not 
we use nvcompress to get the dds. After we change the textures name 
called in the differents files and that's it. There's a way to tell the 
script what to do for each file, if the automatic mode is a failure. 
 
I guess speaking theorically is not the best to make an opinion, so if 
some of you are interested to make a test, I will make a 3.2 minimal dds 
fgdata this we, once on my FG pc.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}
== Pros ==
{{FGCquote
|I always got a loading problem with png textures, large textures take 
seconds to load and convert, and that ruin my close flight where you 
can't afford to take pause in the air. 
that's why i did a batch script to convert to dds ALL the textures in 
the data, not only the matérial set, but everything. Now i only flight a 
dds version of flightgear, and am quite happy with it, that's why i 
propose to provide a dds fgdata for test, and maybe to make it an 
alternate download possibility.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Cons ==
{{FGCquote
|FG actually runs with dds textures, it just doesn't render anything reasonable, I believe you get monochromatic colors. But I don't expect the menu to be affected, it doesn't use textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|If it's relevant, I recall having S2TC compression problems when running Flightgear, and updating this package to a newer version manually (outside of the main repos) fixed the issue. I'm on an Intel HD 3000, but I'm guessing that Intel HD 4000 doesn't have this problem, since it seems to have better OpenGL and OpenCL support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787875/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Saikrishna Arcot</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

Building FlightGear

2014-08-12T12:49:48Z

Saga: Link to the new page for the superbuild on Windows added.

The [[FlightGear]] developers generally release a stable packaged version of FlightGear, with an easy install wizard, about once or twice a year. For convenience, most FlightGear users download and install these packages.

However, the source files used to '''build the whole FlightGear package''' are continuously being developed by dozens of contributors, who collaborate using the source code management system [[Git]] to create a new "unstable" version every few days. If you want to use one of these unstable versions, or tinker with the source files to create your own custom version, the pages below describe how to compile the FlightGear package from the Git source files (repository at [http://www.gitorious.org/fg Gitorious.org]).

If you'd like to use an integrated development environment, illustrated instructions for building FlightGear and its dependencies can be found in [[Howto:Build FlightGear with NetBeans using CMake]], this should work on both, Windows and Linux systems (NetBeans being a cross-platform IDE).

Another option to run the latest code without having to compile everything yourself, is using a precompiled binary provided by the [[FlightGear Build Server]] which is based on Jenkins.

'''Building FlightGear''' may refer to:
* [[Superbuild|Using CMake Superbuilds]]
* [[Superbuild on Windows|Using CMake Superbuild - Windows]]
* [[Building using CMake]]
* [[Building using CMake - Windows]]
* [[Building FlightGear - Linux]]
* [[Scripted Compilation on Linux Debian/Ubuntu|Building using Linux bash script]]

'''Old pages''' :
* [http://macflightgear.sourceforge.net/home/documents/how-to-build-flightgear-cvs-on-mac-os-x/ Building FlightGear - Mac OS X]
* [[Updating FlightGear on Windows]] - get a recently updated version without compiling

{{Building}}

File:PATH environment variable for fgmeta.png

2014-08-12T12:02:48Z

Saga: Summary filled.

=={{int:filedesc}}==
{{File information
|description = {{en|1=A screenshot which show how to add a path in the <tt>PATH</tt> environment variable on windows with OSG as example.}}
|date = 2014-08-11 13:44 (UTC)
|source = {{own}}
|author = [[User:Saga|Saga]]
|permission =
|other_versions =
|other_fields =
}}

=={{int:license-header}}==
{{PD-self}}

[[Category:Screenshots]]

File:VS2012 WD Superbuild overview.png

2014-08-12T12:01:42Z

Saga: Summary filled.

=={{int:filedesc}}==
{{File information
|description = {{en|1=An overview of VS2012 Express for Windows Desktop with the fgmeta solution and build steps.}}
|date = 2014-08-11 12:42 (UTC)
|source = {{own}}
|author = [[User:Saga|Saga]]
|permission =
|other_versions =
|other_fields =
}}

=={{int:license-header}}==
{{PD-self}}

[[Category:Screenshots]]

File:CMake Superbuild Windows after configure.png

2014-08-12T12:00:42Z

Saga: Summary filled.

=={{int:filedesc}}==
{{File information
|description = {{en|1=Screenshot of CMake GUI with fgmeta repository (after configure).}}
|date = 2014-08-11 12:30 (UTC)
|source = {{own}}
|author = [[User:Saga|Saga]]
|permission =
|other_versions =
|other_fields =
}}

=={{int:license-header}}==
{{PD-self}}

[[Category:Screenshots]]

File:CMake Windows select generator.png

2014-08-12T11:58:59Z

Saga: Summary filled.

=={{int:filedesc}}==
{{File information
|description = {{en|1=Screenshot of the generator selector window of CMake GUI.}}
|date = 2014-08-11 12:29 (UTC)
|source = {{own}}
|author = [[User:Saga|Saga]]
|permission =
|other_versions =
|other_fields =
}}

=={{int:license-header}}==
{{PD-self}}

[[Category:Screenshots]]

File:CMake Superbuild Windows configure.png

2014-08-12T11:57:39Z

Saga: Summary filled.

=={{int:filedesc}}==
{{File information
|description = {{en|1=Screenshot of CMake GUI with fgmeta repository (before configure).}}
|date = 2014-08-11 12:26 (UTC)
|source = {{own}}
|author = [[User:Saga|Saga]]
|permission =
|other_versions =
|other_fields =
}}

=={{int:license-header}}==
{{PD-self}}

[[Category:Screenshots]]

File:Command arguments for VS debugger.png

2014-08-12T11:51:42Z

Saga: Summary filled.

=={{int:filedesc}}==
{{File information
|description = {{en|1=Screenshot which show where to specify the command arguments for the Visual Studio debugger.}}
|date = 2014-08-12 11:36 (UTC)
|source = {{own}}
|author = [[User:Saga|Saga]]
|permission =
|other_versions =
|other_fields =
}}

=={{int:license-header}}==
{{PD-self}}

[[Category:Screenshots]]

File:Command arguments for VS debugger.png

2014-08-12T11:42:00Z

Saga: Template used and category of the image specified.

=={{int:filedesc}}==
{{File information
|description = {{en|1=Screenshot which where to specify the command arguments for the Visual Studio debugger.}}
|date =
|source =
|author =
|permission =
|other_versions =
|other_fields =
}}

=={{int:license-header}}==
{{PD-self}}

[[Category:Screenshots]]

File:Command arguments for VS debugger.png

2014-08-12T11:39:22Z

Saga: Screenshot which where to specify the command arguments for the Visual Studio debugger.

== Summary ==
Screenshot which where to specify the command arguments for the Visual Studio debugger.
== Licensing ==
{{PD-self}}

File:PATH environment variable for fgmeta.png

2014-08-11T14:38:40Z

Saga: A screenshot which show how to add a path in the PATH environment variable on windows with OSG as example.

== Summary ==
A screenshot which show how to add a path in the PATH environment variable on windows with OSG as example.
== Licensing ==
{{PD-self}}

File:VS2012 WD Superbuild overview.png

2014-08-11T14:35:56Z

Saga: An overview of VS2012 Express for Windows Desktop with the fgmeta solution and build steps.

== Summary ==
An overview of VS2012 Express for Windows Desktop with the fgmeta solution and build steps.
== Licensing ==
{{PD-self}}

File:CMake Superbuild Windows after configure.png

2014-08-11T14:32:09Z

Saga: Screenshot of CMake GUI with fgmeta repository (after configure).

== Summary ==
Screenshot of CMake GUI with fgmeta repository (after configure).
== Licensing ==
{{PD-self}}

File:CMake Superbuild Windows configure.png

2014-08-11T14:31:36Z

Saga: /* Summary */

== Summary ==
Screenshot of CMake GUI with fgmeta repository (before configure).

== Licensing ==
{{PD-self}}

File:CMake Windows select generator.png

2014-08-11T14:29:39Z

Saga: Screenshot of the generator selector window of CMake GUI.

== Summary ==
Screenshot of the generator selector window of CMake GUI.
== Licensing ==
{{PD-self}}

File:CMake Superbuild Windows configure.png

2014-08-11T14:27:07Z

Saga: Screenshot of CMake GUI with fgmeta repository (after configure).

== Summary ==
Screenshot of CMake GUI with fgmeta repository (after configure).
== Licensing ==
{{PD-self}}

Superbuild

2014-06-27T12:12:35Z

Saga: I've succeed to superbuild it with VS Express 2012 WD thanks to https://gitorious.org/fg/flightgear/commit/d830430e6104ef71c387ae2bffc2b5414049e0d4 (topic: http://sourceforge.net/p/flightgear/mailman/message/32446764/)

== Requirements ==
According to some recent reports, you should make sure to upgrade your cmake binary to 2.12.1 if you encounter any errors [http://forum.flightgear.org/viewtopic.php?f=37&t=21579&p=196700#p196670].
==Building via the superbuild==

A CMake super-build is a project which downloads, configures and builds other projects. Download can be from a web server, or via Git or SVN. Most normal CMake options apply - you can use different generators (Makefiles, VisualStudio, XCode) and pass in options.

===Getting the source===

In all cases, you should get the superbuild by doing a clean clone (from Git) of fgmeta, with the --recursive option:

{{Git clone|--recursive|git://gitorious.org/fg/fgmeta.git}}

This tells Git to clone submodules, which we need since both flightgear and simgear are submodules of fgmeta. The source repository is: [https://gitorious.org/fg/fgmeta here]
Note that providing you cloned with '--recursive', git pull will also update submodules automatically; some documentation and pages may tell you to manually run 'git update submodules' but providing you do the initial clone with '--recursive' option, it should not be needed.

Note the superbuild does not include any data repository or base files - you should separately download these or clone fgdata, and pass the location to fgfs when running in your preferred way, eg via the --fg-root command line argument.

Once the clone is complete, check out the 'next' branch of fgmeta; the superbuild is not supported on the release branches.

{{Git checkout|next}}

===Superbuild on Windows===

Using VisualStudio / msbuild:

Requirements:
* CMake for Windows
* SVN (see [[Tools of the Trade#Source Code Management / Revision Control Systems|here]].)
* VisualStudio 2010 or 2012 (it should works, otherwise please report it)
* Optional: [http://www.microsoft.com/en-us/download/details.aspx?id=8279 Microsoft Windows SDK] (only required for 64-bit builds)
: If you get an error during the installation of the SDK, try uninstalling MSVC redist packages first, then installing the SDK without compilers and then finally re-installing MSVC.
* Optional: [http://www.microsoft.com/en-au/download/details.aspx?id=23691 Visual Studio 2010 SP1] (recommend you install this if you use the 2010 version; overcomes various issues users have had according to the forums.)

We assume you have cloned fgmeta in C:\FGFS\fgmeta. All the example paths below work just fine if you replace C:\FGFS with G:\MyAwesomeDir\AnySubDir.
(Spaces in the paths are untested and might cause issues, but might work fine)

The steps are as follows:
* Make a build dir beside fgmeta - for example C:\FGFS\metabuild
* Run the CMake GUI, and select C:\FGFS\fgmeta as the source dir, and C:\FGFS\metabuild as the build dir
* Run 'Configure' once, and set CMAKE_INSTALL_PREFIX to C:\FGFS\metabuild\install (this step will be automated soon)
: If Subversion_SVN_EXECUTABLE is marked red, look for svn.exe in the folders under where SVN is installed and set it to point at that.
* Run 'Configure' again, and then 'Generate'. This step creates the ''FlightGear-Meta'' solution (.sln) in C:\FGFS\metabuild
* Build the FlightGear-Meta solution in C:\FGFS\metabuild 
:This build step creates ''FlightGear.sln'' in C:\FGFS\metabuild\fgbuild 

: You can build the -Meta solution from a Visual Studio command prompt using msbuild, or open up the .sln in the IDE and hit build. To avoid build errors in the IDE, perform your first build using the 'Release' build configuration rather than a 'Debug' configuration. Building in 'Debug' configuration can fail if some release-mode files (such as for OpenSceneGraph) are not already present in their folders. 

: The first time will be slow - OpenSceneGraph and Boost will be downloaded and compiled, followed by all of simgear and finally flightgear. If the build fails due to a "hash mismatch" in the OpenSceneGraph file, it could be because the source site itself is inaccessible or having temporary issues. To confirm this, check the presence and size of the downloaded OpenSceneGraph-x.x.x.zip file in C:\FGFS\metabuild\src . You might also try and obtain the file directly. To determine where SuperBuild is trying to get the file from, look for the OSG_SOURCE setting defined in C:\FGFS\fgmeta\CMakeLists.txt 

: Once the -Meta build completes, you will already have a flyable executable in either C:\FGFS\metabuild\install\msvc100-64\FlightGear\bin or C:\FGFS\metabuild\install\msvc100\FlightGear\bin depending on whether it's 64 or 32 bit. Other files such as fgrun.exe can be found and copied from the nearby folders under \install if required. (If you build with VS2012, you would rather get a msvc110 directory) 

 It is easier to run FlightGear by closing the -Meta solution, and instead opening the FlightGear.sln in C:\FGFS\metabuild\fgbuild. From here you can set 'fgfs' as the startup project, enter any command line options, and debug / hack / run the code as normal.

Note you will need to add the OpenSceneGraph install directory to the PATH variables in the 'fgfs' target properties; the dir will be something like C:\FGFS\metabuild\install\msvc100\OpenSceneGraph\bin. Again this step will hopefully go away soon, but for the moment is still required.

Using other generators / IDEs: untested, but quite likely to work if they already work with CMake. Try it out.

===Superbuild on Linux===

Requirements:

* compiler (probably GCC)
* CMake - available on all distros
* Boost - available on all distros
* development packages for your distribution. (For OpenGL, OpenAL and OpenSceneGraph dependencies such as FreeType)

See [[Linux distribution required packages|here]] for some lists of packages names for distributions, but be aware these change or go out of date.

(The follow assumes regular 'make' generator, other generators may work, testing welcome)

* make build dir next to your fgmeta clone
* cd into the build dir
* run cmake ../fgmeta -DCMAKE_INSTALL_PREFIX=$PWD/install -DCMAKE_BUILD_TYPE=Release (or Debug for a debug configuration(
* run make -jN (where N is as large a number as your system can support)
* make some coffee
* fgfs should be in install/bin

===Superbuild on Mac===

Make-based build works, XCode is more interesting. Probably only for the brave,

[[Category:Core development projects]]
[[Category:Building from source]]

Fr/compiler flightear avec CMake - Windows

2014-05-04T16:17:38Z

Saga: Les liens pour télécharger les bibliothèques tierces pour msvc pointent désormais sur la dernière version compilé avec succès

{{Main article|Building Flightgear}}
{{en traduction}}
== Programmes requis ==
* [http://www.cmake.org CMake GUI]
* [http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express Microsoft Visual Studio 2010 Express]
* [http://code.google.com/p/msysgit/ msysGit]

== Arborescence de fichiers ==
Sous windows, FG a besoin d'une arborescence spécifique, de façon à trouver automatiquement les dépendances.

la structure à utiliser est décrites ci dessous. Les liens vous permettent de télécharger directement les dépendances pré-compilés (pour "3rdparty", ne prenez que celle qui correspond à votre architecture, (32 ou 64), notez que la version 32 marche sur une machine 64.
<tt>
: ${MSVC_3RDPARTY_ROOT} /
:: [http://flightgear.simpits.org:8080/job/3rdParty-Win/lastSuccessfulBuild/artifact/3rdParty/ 3rdParty] / </tt> ( inclus: boost, plib, fltk, zlib, libpng, libjpeg, libtiff, freetype, libsvn, gdal, ... ) <tt>
::: bin /
::: include /:
::: lib /
:: boost_1_44_0 / </tt> (a télécharger sur le lien "3rdparty" ci dessus) <tt>
::: boost /
:: install /
::: msvc100 / </tt> ( pour VS2010 32 bits, sinon respectivement : msvc90, msvc90-64 or msvc100-64 pour: VS2008 32, VS2008 64 et VS2010 64 ) <tt>
:::: [http://flightgear.simpits.org:8080/job/OSG-stable-Win/lastSuccessfulBuild/artifact/*zip*/archive.zip OpenSceneGraph] / </tt> ( OSG CMake install ) <tt>
::::: bin /
::::: include /
::::: lib /
:::: SimGear / </tt> (vide pour le moment, les sous-répertoires seront créés par la génération) <tt>
::::: include /
::::: lib /
:::: FlightGear / </tt> (vide pour l'instant) <tt>
::::: include /
::::: lib /</tt>

Si vous compilez une version 64 bits , utilisez le dossier suivant pour comme dossier "3rdparty":
<tt>
:: [http://flightgear.simpits.org:8080/job/3rdParty-Win/lastSuccessfulBuild/artifact/3rdParty.x64/ 3rdParty.x64] / </tt> ( 64 bit version ) <tt>
::: bin /
::: include /
::: lib /</tt>

Si vous n'utilisez pas cette structure, vous devrez juste indiquer les chemins des libs à la main, les dossiers des source et des build peuvent être n'importe ou.

NdT: pour du win64, il manque glut, vous pouvez utiliser [http://www.transmissionzero.co.uk/software/freeglut-devel/ freeglut] qui dispose de binaires et lib 64bits dans le package msvc2010 (dans des sous dossier x64).

== Compiler ==
# mettez en place une arborescence comme décrite ci dessus.
# '''Compiler SimGear'''
## Ouvrir CMake gui.
## faites pointer <tt>"Where is the source code"</tt> sur le dossier qui contient les sources de SimGear (que ce soit d'après une archive téléchargé ou avec git).
## faites pointer <tt>"Where to build the binaries"</tt> sur un dossier vide, (peut être n'importe où et avoir le nom que vous voulez, par exemple simgear-build dans le même dossier que vos sources de simgear).
## clickez sur: [[File:CMake GUI Configure.png]]. La première fois que le projet est configuré, CMake ouvre une fenêtre et vous demande: "Specify the generator for this project" c'est à dire quel compileur vous voulez utiliser. Mettez "Visual Studio 10", (ou "Visual Studio 10 Win64" pour du 64 bit), puis clickez sur "Finish". CMake va alors faire un check du system et creer une configuration de compilation préliminaire.
## CMake ajoute les nouvelles variables de configuration en rouge. Certaines ont comme valeur: <tt>-NOTFOUND</tt>. Ce sont ces variables qui doivent attirer votre attention.Certaines erreurs empêchent SimGear de compiler alors que d'autres invalident certaines options, sans empêcher la compilation.
### En premier, renseignez la variable: <tt>MSVC_3RDPARTY_ROOT</tt> . Tant qu'elle ne pointe pas sur le repertoire de l'arborescence ci-dessus contenant "3rdParty" vous aurez une pléthore de: <tt>-NOTFOUND</tt> .donc ajustez la en conséquence plutôt que de devoir spécifier tous les chemin des libs un par un. faites un [[File:CMake GUI Configure.png]] de nouveau.
### Faites pointer la variable <tt>CMAKE_INSTALL_PREFIX</tt> sur <tt>${MSVC_3RDPARTY_ROOT}/install/msvc100/SimGear</tt>. (msvc100-64 pour du 64 bits)
### Regardez les lignes avec des cases à cocher, ce sont des options de compilation qui ont un effet sur les option des programmes compilés.
## recommencez l'étape 5, jusqu'à ce que [[File:CMake GUI Generate.png]] soit disponible.
## clickez sur [[File:CMake GUI Generate.png]].
## Lancez Visual Studio 2010 et chargez la solution SimGear (SimGear.sln) située dans <tt>"Where to build the binaries"</tt>.
## Choisissez <tt>"Release"</tt> dans la barre d'outils de VS2010 [[File:MVSC 2010 solution.png|right]]
## Générez la solution avec F7 ou un click droit sur "Solution SimGear" tout en haut de l'explorateur de solutions, et choisissez "générer la solution".
## Si il y a des erreurs de compilation, retournez dans Cmake, arrangez les choses, puis: [[File:CMake GUI Configure.png]] suivi de: [[File:CMake GUI Generate.png]].
## Lorsque Visual Studio compile tout sans erreurs, click droit sur <tt>INSTALL</tt> (plus bas dans le solution 'simgear' et choisissez "generer le solution", ce qui va placer les includes et fichiers de lib dans <tt>${CMAKE_INSTALL_PREFIX}</tt>
# '''Compiler FlightGear'''
#: reprenez les étapes pour Simgear, en changeant le dossier <tt>SimGear</tt> par <tt>FlightGear</tt>.
# Après avoir ajouté les librairies au path windows, et donné le chemin vers les data à fgfs.exe,il ne vous reste plus qu'a voler!!

==== Options de compilation ====
Pour ajouter [[LaRCsim]]/[[UIUC]] dans votre binaire, utilisez les options:
ENABLE_LARCSIM:BOOL=ON
ENABLE_UIUC_MODEL:BOOL=ON

=== Mise à jour ===
Lorsque vous mettez à jour les sources avec [[git]], il est la plupart du temps inutile de relancer CMake car la solution est capable de reconfigurer elle-même quand des fichiers CMake sont changés. Recompilez simplement la solution depuis Visual Studio et acceptez le rechargement des projets updaté.

Il est aussi possble d'éditer les fichiers CMakeList.txt directement dans Visual Studio puisqu'ils apparaissent aussi dans la solution, et les projets seront reconfigurés lors de la prochaine génération. Pour changer les options de compilation ou des chemins , il faut utiliser Cmake Gui. En cas de problèmes, repérez le fichier <tt>CMakeCache.txt</tt> dans le dossier <tt>"Where to build the binaries”</tt> et effacez le pour reconfigurer en repartant de zéro, ou utilisez l'option du menu: <tt>File > Delete Cache</tt>.

=== TerraGear ===
Terragear peut être compiler de la même façon que Flightgear, changez juste les chemins pour vos source et dossiers de TerraGear.

== Jenkins Windows configurations ==
=== OSG-stable-Win ===
cmake ..\svn -G "Visual Studio 10"
-DACTUAL_3RDPARTY_DIR:PATH=%WORKSPACE%/3rdParty
-DBUILD_OSG_APPLICATIONS:BOOL=ON
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/OpenSceneGraph
-DOSG_PLUGIN_SEARCH_INSTALL_DIR_FOR_PLUGINS:BOOL=OFF
-DFREETYPE_LIBRARY:FILEPATH=%WORKSPACE%/3rdParty/lib/freetype243.lib
-DGDAL_INCLUDE_DIR:PATH=
-DGDAL_LIBRARY:FILEPATH=
=== SimGear-Win-CMake ===
cmake ..\SimGear -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/SimGear
=== FlightGear-Win-CMake ===
cmake ..\FlightGear -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/FlightGear
-DFLTK_FLUID_EXECUTABLE=%WORKSPACE%/3rdParty/bin/fluid.exe
=== FGRun-Win-CMake ===
cmake ..\svn -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT:PATH=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/FGRun
-DFLTK_FLUID_EXECUTABLE:FILEPATH=%WORKSPACE%/3rdParty/bin/fluid.exe
-DGETTEXT_MSGFMT_EXECUTABLE:FILEPATH=%WORKSPACE%/3rdParty/bin/msgfmt.exe
-DGETTEXT_MSGMERGE_EXECUTABLE:FILEPATH=%WORKSPACE%/3rdParty/bin/msgmerge.exe
=== TerraGear-Win-CMake ===
cmake ..\TerraGear -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/TerraGear
-DGPC_LIBRARY=%WORKSPACE%/3rdParty/lib/gpc232.lib
-DNEWMAT_LIBRARY=%WORKSPACE%/3rdParty/lib/newmat11.lib

== External link ==
* [https://gitorious.org/fg/flightgear/blobs/next/docs-mini/README.MSVC README.MSVC] (at Gitorious)

{{building}}

[[en:Building_using_CMake_-_Windows]]

Building using CMake - Windows

2014-05-04T16:13:33Z

Saga: Hyperlink rather to the last successful build for the msvc 3rd party files

{{Main article|Building Flightgear}}

== Required software ==
* [http://www.cmake.org CMake GUI]
* [http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express Microsoft Visual Studio 2010 Express] (MSVC)
* [http://www.microsoft.com/en-us/download/details.aspx?id=8279 Microsoft Windows SDK] (only required for 64-bit builds)
: If you get an error during the installation of the SDK, try uninstalling MSVC redist packages first, then installing the SDK without compilers and then finally re-installing MSVC.
* [http://www.microsoft.com/en-au/download/details.aspx?id=23691 Visual Studio 2010 SP1] (If you get a linking error during the configure process)

== Obtaining source ==
{{Main article|FlightGear and Git}}
Throughout this article it is assumed that you've already set up git clones of the various source repositories (FlightGear, SimGear, data...).

== Directory tree ==
On Windows, assumptions on the directory structure are made to automate the discovery of dependencies.

This recommended directory structure is described below. Clicking the links allows you to download pre-built parts (for 3rdParty, make sure to download the right bits version. You need only one of the zips.). If you do not use the recommended structure you will need to enter paths by hand. Source and build directories can be located anywhere.

'''If you get a login dialog on the ftp server listed above, this means that the max allowed users are reach. Please try a few minutes later.'''

=== 32-bits ===
<tt>
: ${MSVC_3RDPARTY_ROOT} /
:: [http://flightgear.simpits.org:8080/job/3rdParty-Win/lastSuccessfulBuild/artifact/3rdParty/ 3rdParty] / </tt> ( includes boost, plib, fltk, zlib, libpng, libjpeg, libtiff, freetype, libsvn, gdal, ... ) <tt>
::: bin /
::: include /
::: lib /
:: [http://www.boost.org/ boost_1_55_0] / </tt> (latest version can be downloaded from http://www.boost.org/) <tt>
::: boost /
:: install /
::: msvc100 / </tt> ( for VS2010 32 bits, or msvc90 for VS2008 32-bits ) <tt>
:::: [http://flightgear.simpits.org:8080/job/OSG-stable-Win/lastSuccessfulBuild/artifact/*zip*/archive.zip OpenSceneGraph] / </tt> ( OSG CMake install ) <tt>
::::: bin /
::::: include /
::::: lib /
:::: SimGear / </tt> (create this empty for now, subfolders will be created by build process) <tt>
::::: include /
::::: lib /
:::: FlightGear / </tt> (create this empty for now) <tt>
::::: include /
::::: lib /</tt>

=== 64-bits ===
<tt>
: ${MSVC_3RDPARTY_ROOT} /
:: [http://flightgear.simpits.org:8080/job/3rdParty-Win/lastSuccessfulBuild/artifact/3rdParty.x64/ 3rdParty.x64] /
::: bin /
::: include /
::: lib /
:: [http://www.boost.org/ boost_1_55_0] / </tt> (latest version can be downloaded from http://www.boost.org/) <tt>
::: boost /
:: install /
::: msvc100-64 / </tt> ( for VS2010 64-bits, or msvc90-64 for VS2008 64-bits ) <tt>
:::: [http://flightgear.simpits.org:8080/job/OSG-stable-Win64/lastSuccessfulBuild/artifact/*zip*/archive.zip OpenSceneGraph] / </tt> ( OSG CMake install ) <tt>
::::: bin /
::::: include /
::::: lib /
:::: SimGear / </tt> (create this empty for now, subfolders will be created by build process) <tt>
::::: include /
::::: lib /
:::: FlightGear / </tt> (create this empty for now) <tt>
::::: include /
::::: lib /</tt>

NdT: glut is missing for the 64bits build, you can use [http://www.transmissionzero.co.uk/software/freeglut-devel/ freeglut].

== Building ==
# Set up a work directory as described above.
# '''Building SimGear'''
## Open the CMake gui.
## Set <tt>"Where is the source code"</tt> to wherever you put the SimGear sources (from the released tarball or the git repository).
## Set <tt>"Where to build the binaries"</tt> to a new empty directory (could be anywhere and any name, for example naming it simgear-build, at the same folder location as your unzipped SimGear source folder was put).
## Press [[File:CMake GUI Configure.png]]. The first time that the project is configured, CMake will bring up a window asking you to "Specify the generator for this project" i.e. which compiler you wish to use. Select Visual Studio 10 (or Visual Studio 10 Win64 for 64-bit), and press Finish. CMake will now do a check on your system and will produce a preliminary build configuration.
## CMake adds new configuration variables in red. Some have a value ending with <tt>-NOTFOUND</tt>. These variables should receive your attention. Some errors will prevent SimGear from building and others will simply invalidate some options without causing build errors.
### First check the <tt>MSVC_3RDPARTY_ROOT</tt> variable. If it is not set, chances are that there will be a lot of <tt>-NOTFOUND</tt> errors. Instead of trying to fix every error individually, set that variable to the location of the directory structure that is presented above. Then press [[File:CMake GUI Configure.png]] again.
### Set the <tt>CMAKE_INSTALL_PREFIX</tt> variable to <tt>${MSVC_3RDPARTY_ROOT}/install/msvc100/SimGear</tt>.
### Also check the lines with a checkbox. These are build options and may impact the feature set of the built program.
## Repeat the process from step 5, until [[File:CMake GUI Generate.png]] is enabled.
## Press [[File:CMake GUI Generate.png]].
## Start Visual Studio 2010 and load the SimGear solution (SimGear.sln) located in <tt>"Where to build the binaries"</tt>.
## Choose the <tt>"Release"</tt> build in the VS2010 "Generation" toolbar. The right menu should read Win32 for 32-bits or x64 for 64-bits. [[File:MVSC 2010 solution.png|right]]
## Generate the solution with F7 key or right-click the top level "Solution SimGear" in the Solution Explorer and choose Build.
## If there are build errors, return to CMake, clear remaining errors, [[File:CMake GUI Configure.png]] and [[File:CMake GUI Generate.png]].
## When Visual Studio is able to build everything without errors, right-click on the <tt>INSTALL</tt> project (further down within the "Solution Simgear" solution) and choose Build, which will put the include and lib files in <tt>${CMAKE_INSTALL_PREFIX}</tt>
# '''Building FlightGear'''
#: Repeat the steps under Building Simgear, but change the <tt>SimGear</tt> paths to <tt>FlightGear</tt>.
# Enjoy!

==== Build options ====
To include [[LaRCsim]]/[[UIUC]] in your build, set:
ENABLE_LARCSIM:BOOL=ON
ENABLE_UIUC_MODEL:BOOL=ON

=== Updating ===
When updating the source from [[git]], it is usually unnecessary to restart CMake as the solution is able to reconfigure itself when CMake files are changed. Simply rebuild the solution from Visual Studio and accept the reload of updated projects. When the Simgear/FlightGear version numbers change, you do have to re-run CMake.

It is also possible to edit CMakeList.txt files directly in Visual Studio as they also appear in the solution, and projects will be reconfigured on the next generation. To change build options or directory path, it is mandatory to use the CMake Gui. In case of problems, locate the <tt>CMakeCache.txt</tt> file in <tt>"Where to build the binaries”</tt> directory and delete it to reconfigure from scratch or use the menu item <tt>File > Delete Cache</tt>.

=== TerraGear ===
TerraGear can be built the same way as FlightGear, just change the paths to your TerraGear source and directories.

== Jenkins Windows configurations ==
When using CMake GUI, you can add those entries by clicking the Add entry button. Note that you should omit the -D prefix.

=== OSG-stable-Win ===
cmake ..\svn -G "Visual Studio 10"
-DACTUAL_3RDPARTY_DIR:PATH=%WORKSPACE%/3rdParty
-DBUILD_OSG_APPLICATIONS:BOOL=ON
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/OpenSceneGraph
-DOSG_PLUGIN_SEARCH_INSTALL_DIR_FOR_PLUGINS:BOOL=OFF
-DFREETYPE_LIBRARY:FILEPATH=%WORKSPACE%/3rdParty/lib/freetype243.lib
-DGDAL_INCLUDE_DIR:PATH=
-DGDAL_LIBRARY:FILEPATH=
=== SimGear-Win-CMake ===
cmake ..\SimGear -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/SimGear
=== FlightGear-Win-CMake ===
cmake ..\FlightGear -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/FlightGear
-DFLTK_FLUID_EXECUTABLE=%WORKSPACE%/3rdParty/bin/fluid.exe
=== FGRun-Win-CMake ===
cmake ..\svn -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT:PATH=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/FGRun
-DFLTK_FLUID_EXECUTABLE:FILEPATH=%WORKSPACE%/3rdParty/bin/fluid.exe
-DGETTEXT_MSGFMT_EXECUTABLE:FILEPATH=%WORKSPACE%/3rdParty/bin/msgfmt.exe
-DGETTEXT_MSGMERGE_EXECUTABLE:FILEPATH=%WORKSPACE%/3rdParty/bin/msgmerge.exe
=== TerraGear-Win-CMake ===
cmake ..\TerraGear -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/TerraGear
-DGPC_LIBRARY=%WORKSPACE%/3rdParty/lib/gpc232.lib
-DNEWMAT_LIBRARY=%WORKSPACE%/3rdParty/lib/newmat11.lib

== External link ==
* [https://gitorious.org/fg/flightgear/blobs/next/docs-mini/README.MSVC README.MSVC] (at Gitorious)

{{building}}
[[fr:compiler flightear avec CMake - Windows]]

Building using CMake - Windows

2014-05-04T16:01:52Z

Saga: Change the URL to download msvc 3rd party files, previous link was broken (src: http://wiki.flightgear.org/Fr/compiler_flightear_avec_CMake_-_Windows#Arborescence_de_fichiers )

{{Main article|Building Flightgear}}

== Required software ==
* [http://www.cmake.org CMake GUI]
* [http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express Microsoft Visual Studio 2010 Express] (MSVC)
* [http://www.microsoft.com/en-us/download/details.aspx?id=8279 Microsoft Windows SDK] (only required for 64-bit builds)
: If you get an error during the installation of the SDK, try uninstalling MSVC redist packages first, then installing the SDK without compilers and then finally re-installing MSVC.
* [http://www.microsoft.com/en-au/download/details.aspx?id=23691 Visual Studio 2010 SP1] (If you get a linking error during the configure process)

== Obtaining source ==
{{Main article|FlightGear and Git}}
Throughout this article it is assumed that you've already set up git clones of the various source repositories (FlightGear, SimGear, data...).

== Directory tree ==
On Windows, assumptions on the directory structure are made to automate the discovery of dependencies.

This recommended directory structure is described below. Clicking the links allows you to download pre-built parts (for 3rdParty, make sure to download the right bits version. You need only one of the zips.). If you do not use the recommended structure you will need to enter paths by hand. Source and build directories can be located anywhere.

'''If you get a login dialog on the ftp server listed above, this means that the max allowed users are reach. Please try a few minutes later.'''

=== 32-bits ===
<tt>
: ${MSVC_3RDPARTY_ROOT} /
:: [ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ 3rdParty] / </tt> ( includes boost, plib, fltk, zlib, libpng, libjpeg, libtiff, freetype, libsvn, gdal, ... ) <tt>
::: bin /
::: include /
::: lib /
:: [http://www.boost.org/ boost_1_55_0] / </tt> (latest version can be downloaded from http://www.boost.org/) <tt>
::: boost /
:: install /
::: msvc100 / </tt> ( for VS2010 32 bits, or msvc90 for VS2008 32-bits ) <tt>
:::: [http://flightgear.simpits.org:8080/job/OSG-stable-Win/lastSuccessfulBuild/artifact/*zip*/archive.zip OpenSceneGraph] / </tt> ( OSG CMake install ) <tt>
::::: bin /
::::: include /
::::: lib /
:::: SimGear / </tt> (create this empty for now, subfolders will be created by build process) <tt>
::::: include /
::::: lib /
:::: FlightGear / </tt> (create this empty for now) <tt>
::::: include /
::::: lib /</tt>

=== 64-bits ===
<tt>
: ${MSVC_3RDPARTY_ROOT} /
:: [ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ 3rdParty.x64] /
::: bin /
::: include /
::: lib /
:: [http://www.boost.org/ boost_1_55_0] / </tt> (latest version can be downloaded from http://www.boost.org/) <tt>
::: boost /
:: install /
::: msvc100-64 / </tt> ( for VS2010 64-bits, or msvc90-64 for VS2008 64-bits ) <tt>
:::: [http://flightgear.simpits.org:8080/job/OSG-stable-Win64/lastSuccessfulBuild/artifact/*zip*/archive.zip OpenSceneGraph] / </tt> ( OSG CMake install ) <tt>
::::: bin /
::::: include /
::::: lib /
:::: SimGear / </tt> (create this empty for now, subfolders will be created by build process) <tt>
::::: include /
::::: lib /
:::: FlightGear / </tt> (create this empty for now) <tt>
::::: include /
::::: lib /</tt>

NdT: glut is missing for the 64bits build, you can use [http://www.transmissionzero.co.uk/software/freeglut-devel/ freeglut].

== Building ==
# Set up a work directory as described above.
# '''Building SimGear'''
## Open the CMake gui.
## Set <tt>"Where is the source code"</tt> to wherever you put the SimGear sources (from the released tarball or the git repository).
## Set <tt>"Where to build the binaries"</tt> to a new empty directory (could be anywhere and any name, for example naming it simgear-build, at the same folder location as your unzipped SimGear source folder was put).
## Press [[File:CMake GUI Configure.png]]. The first time that the project is configured, CMake will bring up a window asking you to "Specify the generator for this project" i.e. which compiler you wish to use. Select Visual Studio 10 (or Visual Studio 10 Win64 for 64-bit), and press Finish. CMake will now do a check on your system and will produce a preliminary build configuration.
## CMake adds new configuration variables in red. Some have a value ending with <tt>-NOTFOUND</tt>. These variables should receive your attention. Some errors will prevent SimGear from building and others will simply invalidate some options without causing build errors.
### First check the <tt>MSVC_3RDPARTY_ROOT</tt> variable. If it is not set, chances are that there will be a lot of <tt>-NOTFOUND</tt> errors. Instead of trying to fix every error individually, set that variable to the location of the directory structure that is presented above. Then press [[File:CMake GUI Configure.png]] again.
### Set the <tt>CMAKE_INSTALL_PREFIX</tt> variable to <tt>${MSVC_3RDPARTY_ROOT}/install/msvc100/SimGear</tt>.
### Also check the lines with a checkbox. These are build options and may impact the feature set of the built program.
## Repeat the process from step 5, until [[File:CMake GUI Generate.png]] is enabled.
## Press [[File:CMake GUI Generate.png]].
## Start Visual Studio 2010 and load the SimGear solution (SimGear.sln) located in <tt>"Where to build the binaries"</tt>.
## Choose the <tt>"Release"</tt> build in the VS2010 "Generation" toolbar. The right menu should read Win32 for 32-bits or x64 for 64-bits. [[File:MVSC 2010 solution.png|right]]
## Generate the solution with F7 key or right-click the top level "Solution SimGear" in the Solution Explorer and choose Build.
## If there are build errors, return to CMake, clear remaining errors, [[File:CMake GUI Configure.png]] and [[File:CMake GUI Generate.png]].
## When Visual Studio is able to build everything without errors, right-click on the <tt>INSTALL</tt> project (further down within the "Solution Simgear" solution) and choose Build, which will put the include and lib files in <tt>${CMAKE_INSTALL_PREFIX}</tt>
# '''Building FlightGear'''
#: Repeat the steps under Building Simgear, but change the <tt>SimGear</tt> paths to <tt>FlightGear</tt>.
# Enjoy!

==== Build options ====
To include [[LaRCsim]]/[[UIUC]] in your build, set:
ENABLE_LARCSIM:BOOL=ON
ENABLE_UIUC_MODEL:BOOL=ON

=== Updating ===
When updating the source from [[git]], it is usually unnecessary to restart CMake as the solution is able to reconfigure itself when CMake files are changed. Simply rebuild the solution from Visual Studio and accept the reload of updated projects. When the Simgear/FlightGear version numbers change, you do have to re-run CMake.

It is also possible to edit CMakeList.txt files directly in Visual Studio as they also appear in the solution, and projects will be reconfigured on the next generation. To change build options or directory path, it is mandatory to use the CMake Gui. In case of problems, locate the <tt>CMakeCache.txt</tt> file in <tt>"Where to build the binaries”</tt> directory and delete it to reconfigure from scratch or use the menu item <tt>File > Delete Cache</tt>.

=== TerraGear ===
TerraGear can be built the same way as FlightGear, just change the paths to your TerraGear source and directories.

== Jenkins Windows configurations ==
When using CMake GUI, you can add those entries by clicking the Add entry button. Note that you should omit the -D prefix.

=== OSG-stable-Win ===
cmake ..\svn -G "Visual Studio 10"
-DACTUAL_3RDPARTY_DIR:PATH=%WORKSPACE%/3rdParty
-DBUILD_OSG_APPLICATIONS:BOOL=ON
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/OpenSceneGraph
-DOSG_PLUGIN_SEARCH_INSTALL_DIR_FOR_PLUGINS:BOOL=OFF
-DFREETYPE_LIBRARY:FILEPATH=%WORKSPACE%/3rdParty/lib/freetype243.lib
-DGDAL_INCLUDE_DIR:PATH=
-DGDAL_LIBRARY:FILEPATH=
=== SimGear-Win-CMake ===
cmake ..\SimGear -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/SimGear
=== FlightGear-Win-CMake ===
cmake ..\FlightGear -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/FlightGear
-DFLTK_FLUID_EXECUTABLE=%WORKSPACE%/3rdParty/bin/fluid.exe
=== FGRun-Win-CMake ===
cmake ..\svn -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT:PATH=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/FGRun
-DFLTK_FLUID_EXECUTABLE:FILEPATH=%WORKSPACE%/3rdParty/bin/fluid.exe
-DGETTEXT_MSGFMT_EXECUTABLE:FILEPATH=%WORKSPACE%/3rdParty/bin/msgfmt.exe
-DGETTEXT_MSGMERGE_EXECUTABLE:FILEPATH=%WORKSPACE%/3rdParty/bin/msgmerge.exe
=== TerraGear-Win-CMake ===
cmake ..\TerraGear -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/TerraGear
-DGPC_LIBRARY=%WORKSPACE%/3rdParty/lib/gpc232.lib
-DNEWMAT_LIBRARY=%WORKSPACE%/3rdParty/lib/newmat11.lib

== External link ==
* [https://gitorious.org/fg/flightgear/blobs/next/docs-mini/README.MSVC README.MSVC] (at Gitorious)

{{building}}
[[fr:compiler flightear avec CMake - Windows]]