Texture.cfg

[n4gix 4,947]

I'd like to suggest something no one has yet...I'd like to see a "Texture.cfg" file so that we wouldn't have to duplicate "common textures" in every texture folder... ;)It's silly to have only two or three "fuselage & wing" textures for each "repaint" and then have to include all the remaining "common textures!"

[Guest tdragger]

Well likely some up with something to help reduce duplication, especially now that you've got bumpmap textures, fresnel ramps, etc. Dunno what we'll do or how, but it's something we'll look at.

[Guest]

An how would you do that? Texture mapping is coded into the mdl file, with possible multiple textures in one bitmap and multiple uses for each texture (which can even overlap).Would be one complicated cfg file, and one that would cause no end of trouble when punters start messing it up in attempts to "improve" something, with the subsequent deluge of complaints how "FSX is crap because my textures look like ####".

[n4gix 4,947]

I dare say I'm rather intimately acquainted with how texture assignments are made... ;) However, most "repaints" consists of one or two "altered textures," with the remaining textures simply being copy/pasted into the new texture.xx folder. This is redundant and a waste of diskspace.Actually, it could be done even without a "texture.cfg" file, similar to the way that the panel system looks first in the panel folder for gauges, then falls back to the default gauges folder...In a similar fashion, the texture system could look first in the specific texture.xxx folder, then fallback to the default texture folder for the remaining .bmp files.OTOH, a "texture.cfg" file could simply look something like this:fuse1.bmpfuse2.bmp.texturegear.bmp.texturewing.bmp.texturepilot.bmpIOW, simply allow us to provide a "relative path" to where the "common textures" are located... ;)

[n4gix 4,947]

Thanks, Mike! That's all I asked for... ;)

[tgibson 11]

Hi Bill,The texture system already has a fallback - the main FS TEXTURE folder. If FS cannot find a texture in the plane's texture folder, it will look there. PAI and others already use the main TEXTURE folder for night textures common to many liveries of their AI planes.That said, I would prefer a texture.cfg file to allow specifying a "fallback" folder just for that plane. For example:alias=..c182textureIf FS could not find a texture for this plane in the folder specified in the aircraft.cfg texture= line, it would look in the Cessna 182 texture folder instead. Using this format would also keep the cfg file format the same as other cfg files (panel, sound, etc.).Take care,--Tom GibsonCal Classic Propliner Page: http://www.calclassic.comFreeflight Design Shop: http://www.freeflightdesign.comDrop by! ___x_x_(")_x_x___

[n4gix 4,947]

>Hi Bill,>>The texture system already has a fallback - the main FS>TEXTURE folder. If FS cannot find a texture in the plane's>texture folder, it will look there. PAI and others already>use the main TEXTURE folder for night textures common to many>liveries of their AI planes.Thanks, Tom. I was "fuzzily aware" that such was the case already, but that would become a logistical nightmare quickly, and could be the proximate cause of no end of grief. How many modelers do you suppose use texture names that might prove to be identical, such as gear.bmp or pilot.bmp? ;)Any one of the three methods proposed would be preferable to the current status though: either of my two or yours... ;)

[Guest tdragger]

>An how would you do that? >Texture mapping is coded into the mdl file, with possible>multiple textures in one bitmap and multiple uses for each>texture (which can even overlap).>>Would be one complicated cfg file, and one that would cause no>end of trouble when punters start messing it up in attempts to>"improve" something, with the subsequent deluge of complaints>how "FSX is crap because my textures look like ####".Yeah. I guess you're right. We don't really know how the code works so we'd probably screw it up. Never mind...

[JSkorna 137]

:-xxrotflmao:-xxrotflmaoHope this helps,Jimhttp://www.hifisim.comhttp://sales.hifisim.com/pub-download/asv6...development.jpg http://sales.hifisim.com/pub-download/asv6-banner-proud.jpg

---

http://www.jdtllc.com/images/rcv4bannersupporter.jpg

[W2DR 1,860]

:-)

[Guest tdragger]

Seriously, though, if you think this is a feature we *shouldn't* spend time thinking about that would be good to know, too.

[Guest baksteen33]

Frankly, Mike, I think this is something aircraft developers and the Studios could give a thought in order to define a standard. For standalone aircraft and as far as I would dare to judge, it seems justified to have textures in the aircraft folder. Just as a thesis, couldn't AI AC be treated differently? Couldn't 'repetitive' textures first be looked up in the common texture folder? I neglect how FS or the OS handles this now but could imagine there is room for improvement. FYI, these remarks are based upon the observation that every 'AI manufacturer' seems to handle this differently - as TomG mentioned, PAI uses common textures, MyTraffic does so partially and i.e. Traffic2005 doesn't do so at all. Cheers everybody for taking your time and sharing your thoughts Kind regards Jaap

[n4gix 4,947]

Jaap, here is a prime example of what I'm driving at. I have twelve 'repaints' of the ESDG Citation CJ1.Each texture.xx folder must have all textures under the current scheme, which total 22.1MBs of disk space. The only textures that're different are the fuse and wing textures, which together are a mere 2MBs...HD USAGE currently scheme = 265.2MBsHD USAGE proposed scheme = 44.1MBsSo, as I see it, this would impact far more than just AI aircraft, and would be available for all aircraft without restriction. :)

[Guest baksteen33]

Thanks for the pointer, Bill. I didn't realize common textures for a multiple paint/single addon AC would make such a difference as well. In the meantime and still wondering - to which extent would such changes require (re)coding on MS' behalf? Perhaps such proposals are too late? Let alone that such standards should/could also be agreed upon and adopted by addon developers? AIM, my remarks were mainly aiming at AI performance in dense areas like NY, where lots of similar models fill our virtual skies/airports and the current differences between various AI addons. Question above question and I can easily think of a couple more in this context. OTOH, a common texture concept might have a negative impact on the desired backward compatibility? Anyway, just to say my 'guts speak' really likes the idea. :-) Thanks and kind regards Jaap

[tgibson 11]

I'm not sure if having a number of copies of the same texture file displayed will give any better performance than using multiple but identical texture files (i.e. I don't know if displaying one texture multiple times saves the graphics card some memory, etc.). If it does, then this approach could help the frame rate when displaying large numbers of identical AI aircraft.The approaches used by Bill and myself would not have any backwards compatibitity problems that I can see. If the VC= line (or even the texture.cfg file) were not present, FS would just use the current system for searching for texture files for this old plane.All these proposals may be too late for FSX (hope not), but this is always a good time to propose things for FSXI. MS folk can put them on their "future features" list.Take care,--Tom GibsonCal Classic Propliner Page: http://www.calclassic.comFreeflight Design Shop: http://www.freeflightdesign.comDrop by! ___x_x_(")_x_x___