Re: [Flightgear-devel] Textures separation, cleanup
On Wednesday, September 18, 2013 21:06:48 Renk Thorsten wrote: > > - a baseline texture set that is of adequate, but not high quality > > > > (e.g. max 1024x1024 size for landcover, or something else agreed to be > > good enough) to be included by default in the installers > > > > (this would also be friendly to people on older hardware with limited > > > > VRAM) > > > > - high res (and even, ultra-high res) sets, plus a DDS set for those > > > > who want it, which can be downloaded + updated later via terra-sync. > > > > (of course we can have discussions about if the default set should be > > > > really low quality or quite high - but the point is to have levels we > > can switch between centrally ) > > > On the other hand, if ALS is not supposed to be default, I wouldn't save > harddisk space by reducing the visual quality - we want to make a good > first impression for the user. So I would get rid of redundant lowres > textures which have a hires equivalent then. > > I suppose dds can be factored out in any case, as there seems to be a > strong sentiment that dds cannot be default as it doesn't run on Linux > systems with non-proprietary drivers. > > In general, I would definitely like to keep as many textures as possible in > the devel version - when designing regional textures, I find that I really > need material to work with, and many textures can be applied to a > different purpose after a color transformation. Also, it's going to be > rather difficult to package regional textures region by region as many of > them are shared across different regions. > > Hm, I guess in the end I work too much with terrain textures to be really > comfortable with a major change in the way we distribute them - I can see > the redundant lowres bits go, and I can see that the dds set is easily > separable, but I don't really see a grand design beyond. May be just my > personal bias. > > * Thorsten Hi Stuart, Thorsten, Since I'm the author of most of the high-res PNG textures, I'd like to explain why the texture resolution is not the same for every texture type, and to share my opinion on this subject. When I first started to make textures, I looked for the highest resolution aerial photos which could be used with GPL. Unfortunately, not all ortho imagery had the same quality. Some sets were really good, with high resolution, while others had color balance issues or lower resolutions. For some types of terrain, like wooded areas, crop fields, towns, mixed wood- crop, I have found good images, but in some cases I was not able to extract all textures at the same resolution due to visible artefacts or items which would repeat visibly in an unpleasant way. Rock is a special case since I used my own photos which had a high enough resolution to extract a quality texture. So in the end, we end up with texture sizes ranging from 512px to 2048 px. Of course, ideally we would have all high-res textures the same size, and all low-res textures just scaled versions of the high-res ones. Unfortunately, that was just not possible. Finally, I opted for keeping 2048px textures at this resolution, while other textures had 1024 or even 512px resolution, according to their source. I think that today, with every modern game shipping on full-size DVD's, there should be no problem keeping the high res textures at their original, intended size. The size increase is not dramatically large. At the same time, I'd like to state my opinion that PNG counterparts of all DDS textures should be available in the git repo for development purposes. Even if this increases the size of the repo, I think it's a must since DDS is not an open format easily and losslessly convertible to PNG. My 2c on this matter, Adrian -- 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
Re: [Flightgear-devel] Textures separation, cleanup
> - a baseline texture set that is of adequate, but not high quality > (e.g. max 1024x1024 size for landcover, or something else agreed to be > good enough) to be included by default in the installers > (this would also be friendly to people on older hardware with limited > VRAM) > - high res (and even, ultra-high res) sets, plus a DDS set for those > who want it, which can be downloaded + updated later via terra-sync. > (of course we can have discussions about if the default set should be > really low quality or quite high - but the point is to have levels we > can switch between centrally ) I think this is somewhat tied to the question of how the 3.0 default should look like. If the idea is (as has been suggested before) that ALS becomes the default rendering framework, then there are really no hires or ultra hires textures needed since the higher quality level build details procedurally down to cm-scale anyway, so we could have a limit of 1024x1024 textures in the package without any loss of visual quality. On the other hand, if ALS is not supposed to be default, I wouldn't save harddisk space by reducing the visual quality - we want to make a good first impression for the user. So I would get rid of redundant lowres textures which have a hires equivalent then. I suppose dds can be factored out in any case, as there seems to be a strong sentiment that dds cannot be default as it doesn't run on Linux systems with non-proprietary drivers. In general, I would definitely like to keep as many textures as possible in the devel version - when designing regional textures, I find that I really need material to work with, and many textures can be applied to a different purpose after a color transformation. Also, it's going to be rather difficult to package regional textures region by region as many of them are shared across different regions. Hm, I guess in the end I work too much with terrain textures to be really comfortable with a major change in the way we distribute them - I can see the redundant lowres bits go, and I can see that the dds set is easily separable, but I don't really see a grand design beyond. May be just my personal bias. * Thorsten -- 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
Re: [Flightgear-devel] Textures separation, cleanup
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) > 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 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
[Flightgear-devel] Textures separation, cleanup
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) What I'd like is: - a baseline texture set that is of adequate, but not high quality (e.g. max 1024x1024 size for landcover, or something else agreed to be good enough) to be included by default in the installers (this would also be friendly to people on older hardware with limited VRAM) - high res (and even, ultra-high res) sets, plus a DDS set for those who want it, which can be downloaded + updated later via terra-sync. (of course we can have discussions about if the default set should be really low quality or quite high - but the point is to have levels we can switch between centrally ) However, my impression is the current switching is done at the effects / material level (especially between DDS and PNG). I.e C++/Nasal code is not involved in any such switching. (Which will need to be changed, assuming it can be) I'm not clear where the texture file names are being referenced from, and how the paths are being searched. E.g, do the shared Models reference these textures, or do they include their own (my impression is the latter, but maybe it's a mix?). If it's not the models, is it 'just' effects/shaders and scenery materials? Do aircraft reference them? And if so, is it via an arbitrary mixture of Textures, Texture.high and DDS paths? I am assuming we would fallback to the Textures/ dir, so I hope the only fixing of aircraft / scene models required would be replacing any references to Textures.high or DDS files. 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 :) Regards, James -- 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
