| They are calculated, you can see that in lines 290 and 296 of d_scan.c where the S and T coordinates (these are the texture coordinates, just another name for UV coordinates[0]) are calculated. But yeah, they are not stored in the BSP file and are derived from the surface. As for why it is done like that, it isn't for rendering simplicity but for storage. It takes less memory and disk space to store only the surface plane and texture axes and calculate the texture coordinates when you need them than store them on memory/disk for every vertex. Not only you store a few less bytes even for a triangle (with additional memory for each vertex) but also allows sharing of vertex and edge data which are common between surfaces even if their texture coordinates would differ. After all the game had to run in systems with just 8MB of RAM. > I have used Radiant and the “texture lock” was a bit of a joke for a long time. Well, i just tried it in QERadiant and seems to work fine. In any case, yes there are limitations, but when you are sticking to the grid - which is what most of Quake maps do, going off the grid isn't that common - the automatic texture alignment is also very convenient. This was also a big improvement over Doom where every linedef had to be manually adjusted and misaligned textures were commonplace. [0] Traditionally S,T as convention are supposed to refer to coordinates in surface space and U,V in texture space but in practice everyone uses them interchangeably, especially with 3D APIs that use both to mean the same thing. Some older 3D graphics books do make a distinction though. |