Hi James, On Tue, Sep 17, 2013 at 9:56 PM, James Turner wrote: > Hello, > > For the next release (3.0, I think), I want to reduce the size of the > installers by making parts of the base package optional. Some are easy, like > AI Traffic and ATC chatter - the first time you enable that feature, we'll > download (well, terra-sync, really) the relevant files. If you don't use the > feature, you don't download the files ever. > > One large piece (480MB of the base package / fgdata at current counting) is > the Textures and Textures.high directories. Originally I believe > Textures.high was a partial subset of Textures, at higher resolutions, but > that's no longer the case (nor has it been for a long time, I think) <snip> > Any hints on how the mechanism is currently working, and how it could work in > the future would be interesting. This is a 'look at in the next few months' > task, not something I'm planning to tackle next week, so there is no rush. > Indeed, if it turns out to be more complex than I realise, it might even be > too big to tackle for 3.0, but the first step is to understand how it does > work, and how it could work :)
As I'm sure you're aware, most of the space is taken up by Textures[.high]/Terrain The files there should be exclusively used by our terrain definitions under Materials/ - or at least I've made no attempt to keep them consistent for other uses! The actual textures are referenced in the various .xml files under Materials/. The code to do so is in simgear/scene/material/mat.cxx (read_properties). It's pretty basic - looking for a Textures.high variant of the file first, then falling back to a Textures/ directory if it doesn't exist. However, in most cases the textures under Textures/ are very low rez indeed - 256x256. That's a texture typically covering 2kmx2km, so a resolution of 8m/px. I'd be surprised if anyone is deleting the Textures.high directory these days and falling back on them. Note that the files with a "mask.[png|dss]" are used for object/vegetation placement and are typically low resolution and only in the Textures/Terrain directory. The Textures.high versions are typically 1024x1024 or 2048x2048. Perhaps we could replace the Textures/Terrain with the 1024x1024 versions? That doesn't save us much space overall, but would make having Textures.high optional a more reasonable option. Note that the dds textures are referenced explicitly by a separate Materails/dds/materials.xml file, so an alternative would be to make some of the different materials.xml/Texture combinations as separate packages. I.e. package the basic materials (base/materials.xml and default/materials.xml) in the base package, then make the dds/materials.xml and regions/materials.xml and the textures that only they reference separate. I don't know how much a difference that would make for the non-dds textures though as there's a lot of overlap. Finally, one of the things on my TODO list is improve the organization of the materials definitions. At the moment it's a bit of a mess, relying on a single massive list of materials definitions using <condition> blocks on each one. I'd like to provide mode structure so we can have more sensible separate definitions. -Stuart ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
