cl.viewent is a placeholder entity_t struct that has nothing to do with anything in the cl_entities list. The only real reason for it to exist appears to be to enable the same drawing code to be used for the viewmodel as for other MDLs. It could have just as easily been done with globals otherwise.
cl.viewentity is (typically) a number between 1 and 16, and is an index into cl_entities. This is the real entity representing "you" in the game.
cl_entities[0] is the world.
cl_entities[1] to cl_entities[16] (assuming 16 players) are you and other players. The slot in here representing you isn't drawn unless chase_active is 1.
Software Quake just minlighted everything to LIGHT_MIN, which was 5. It didn't make any special distinction between players, the gun model or any other entity type.
GLQuake minlighted the gun to 24 (before dynamic lights are added) and other players to 8 (after dynamic lights are added). No idea why the change was made; it might be experimental code (GLQuake was never anything more than experimental in intent), it might be the Way Things Are Meant To Be From Here Onwards, it might have been because of no fullbrights or overbrights, it might have even been a mistake. The only hint we have is that the minlighting of other players to 8 was added by Zoid after he took over maintenance of the codebase, so that would be sometime in mid 1997 when Carmack had moved on to Quake II. It's definitely not original code and shouldn't be seen as Word Of God.
FitzQuake uses 24 because it's 3x8 - one for each channel in RGB. It also scales things a little differently, but the intention seems to be to preserve the colour balance while minlighting. (It uses 72 for the gun model - 3x24 - for the same reason.) It does however get the order different from the way GLQuake did it, applying both minlights after dynamic lights are added (remember that GLQuake did the gun before).
The only reason for software Quake's minlighting to 5 was a performance optimization:
Code: Select all
// guarantee that no vertex will ever be lit below LIGHT_MIN, so we don't have
// to clamp off the bottom
It seems reasonable to assume that if this optimization wasn't needed there would have been no minlighting, although other factors may have then come into play.
Concerns about fairness in multiplayer shouldn't come into this. It's client-side, so everything is wide-open for exploitation. The only half-way reasonable solution would be to move MDL lighting to the server and make it part of the protocol, but a malicious client could just read the data and ignore it. This is a battle that can't be won.