Map textures (materials) handling

[GoogleCodeExporter]

Overall description:
Each map has additional texture file *.tex.
In source code we have ShaderInfo[] - the array of "textures" (I would like to 
call them materials) for current 
map.
Both GAME and CGAME fill the array from .tex file (by (C)G_ParseTexFile() 
functions).
Each "texture" file has shaderInfoNum (second line in the file) materials in 
format:
<surfaceFlag> <color[0]> <color[1]> <color[2]> (color[3] is always 1.0f)
It is continuous numbering, so the file represents shaderNum from 0 to 
shaderInfoNum shaders.
The color is used to create colored particles when the surface is hit.
And the surfaceFlag is real surfaceFlag parameter (consists of bits for 
surfaces like "SURF_WATER", etc).
(I suppose - I don't have any maps sources) when map is created every SOLID and 
(I don't understand why, but it is 
used that way in Trace functions) PLAYER_CLIP contents brushes are filled with 
shaderNum in surfaceFlags field 
instead of real surface flags. In other words ShaderInfo is working like 
palette of materials (surface type and 
color) and each brush has material number stored in surfaceFlag.

The best solution would be to extend brush structure both in Quake map editor 
and in source code with color 
variable, so it will be loaded just during map loading.
But we don't have any map sources to recompile maps back, so until we are using 
vanilla SG maps we have to handle 
those "textures" the same way.

Current trouble with those textures is that we are doing palette match each 
time when we are doing Trace functions 
(which we are doing pretty often). And we treat surfaceFlag from the 
brush/trace structures as material number 
instead of real surfaceFlag which may confuse coders/readers and lead to 
logical errors. And again - there are 
bunch of those Trace*New(2) functions which are meaningless to anyone who is 
not familiar with SG "textures" (in 
other words to anyone).

Possible solution:
As a temporary solution I think we may extend brush/trace structure in source 
code with color member. And fill 
those during map loading with real values according to materials palette from 
*.tex file. That way we may do trace 
as it is done in ioQ3.
Still there will be "dangerous" zone when *.tex file is loading and before it, 
but that is the price of 
mistreating surfaceFlag in original SG maps.
Also I would like to rename the array ShaderInfo[] to surfaceFlagPalette[] 
(shaderInfoNum to be renamed to).
And as a minor thing - to place (C)G_ParseTexFile() functions to one 
BG_ParseTexFile() function to BG source file 
to make it unique. Both QVMs have to load *.tex files in the very same way.

Variables affected:
None.

Original issue reported on code.google.com by igorpana...@gmail.com on 8 Dec 2009 at 9:47

[GoogleCodeExporter]

The color from the material array is used during marks (when a wall was hit by 
pistol fire) creation. I think we may just re-
draw marks images so they won't need the coloring.
For wood and similar surfaces we just use only black color (with no borders) - 
that will make them more natural. And for 
metal you may see that there is no dye around the hole borders when anything 
was hit (I mean real life things not SG), so I 
think that kind of constant color would be good. The same about colored glass. 
Once it has been hit -  the dye around the 
borders won't be the same color, we could use just white or near-white color.

Concerning colored particles - it is actually whole other issue (because 
vanilla's Q3 particles are very heavy for CPU - we 
are suffer about FPS because of them). When metal was hit the particles are 
usually they same (sparkles) - they are independent from the color of surface. 
And colored wood will do colored particles - but I think we may do them a bit 
smaller, 
so that will be look still realistic even without the color (I mean different 
color for each wood surface).

So, that will allow us to get rid of color thing in theses .tex files.
Then the only thing that we will have to maintain is backward compatibility 
with vanilla SG maps. We will have to read the 
surface flags from .tex file (if it is present) and place them to corresponding 
field of each in-game plane during map 
loading.

And of course the next-gen maps won't need that .tex file at all.
That is really important because the next generation maps will be created with 
some general Q3/D3 map stuff. Probably the 
DarkRadiant (very nice thing) will be there. So, to make it more natural we 
better to keep with natural map structure - that 
will make mappers work much easier (because most of them are not familiar and 
don't want to be familiar with specific SG maps making).

Original comment by igorpana...@gmail.com on 27 Dec 2009 at 9:47