[http://sourceforge.net/p/ufoai/feature-requests/499 Item 499] imported from sourceforge.net tracker on 2013-01-28 20:20:07

Hey Mattn !
You gave me the mission to think about code optimizations:
So I was thinking about the best steps to take to further optimize the material system, here is number 1:

To ensure fast execution of each map & remove unused operations during map loading we should introduce separate material files for each map instead of having just one material file for a set of maps.
This was not important until now, but as we start to finally use the material system in-game instead of just having the possibility to do so, material files will naturally get bigger & more complex & we should ensure that when a map is loaded just the textures & settings used for that map are loaded into memory.

Take 'tropic' for example: Here we have a map with a big corrupter ufo landing, then we have another one, where a harvester lands, but there are also tropic maps like druglord, where no big ufo will ever land.
Still our current system will load all of the definitions & textures, which should not be the case. There should be different material files, like one for the tropic +bigufo corrupter, another one for tropic +bigufo harvester & one for each of the other tropic submaps...
Another even better possibility would be to have subsections inside the tropic.mat file, which define where specific settings should be used.
Like 'Common' for settings which are valid for all tropic maps & then to have other subsections in tropic.mat like 'Corrupter' 'Harvester' 'Druglord' where just specific definitions are placed & loaded & executed just if the specific map is loaded otherwise those subsections should be ignored.

This system would have other nice side-effects:

It would provide us with a method, where we can easily program 'Special' missions just via the material system, where we then can make a normal map look very special & simulate all kinds of stuff just by using some material system skinning, animations & fx.

This will help map loading & assembly speed, as just specific data gets even loaded into memory & will ensure we have much room left texturewise, even if we use very complex & advanced animations, skinning & fx without increasing our MAX_GL_TEXTURES limit.

It would allow us to have even more individualized animations, skinning & fx.
===== Comments Ported from Sourceforge =====

====== tlh2000 (2010-06-28 15:36:25) ======

i disagree here as this would arise the need to add new material files for each tile of a rma - even if you are using almost the same texture set - and more important, only those textures from a material file are loaded that are used in that map.