Introduce a proper material system
kduske opened this issue · comments
Currently, TrenchBroom only knows texture assets. The textures are enhanced with some material properties such as the filtering mode, the mode of transparency, Quake 2 surface flags / content flags, and some Quake 3 shader properties.
In addition, we bolted on support for Quake 3 shader loading. This is particularly awkward and hard to debug.
We should separate materials from textures. We would end up with a material manager and a texture manager. Materials would be scanned and loaded immediately when a map is loaded (or if triggered manually by the user).
For Quake 3, this would include finding, loading, parsing and creating the shaders. For most other games, this would just mean scanning the filesystem for images and automatically generating materials for them depending on the game, image format, and other properties (e.g. fence textures in Quake have a special character in the filename).
Texture images would be loaded on demand when they first need to be displayed. This would improve loading times considerably because textures that are never displayed because they are not used and filtered out from the browser would never need to be loaded.
We could finally model the different transparency modes properly and handle them in the shaders. This would solve issues such as #4440.
That would be wonderful.