Player coloring system on custom models/entities

Discuss the creation of various model formats for Quake engines, and related matters to modeling.
Post Reply
Ghost_Fang
Posts: 336
Joined: Thu Nov 12, 2009 4:37 am

Player coloring system on custom models/entities

Post by Ghost_Fang »

I know quake allows the player to change pants and shirt color without using a bunch of skins. How does Quake handle or do that? And how would I apply that to my own custom model or models/entities?
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: Player coloring system on custom models/entities

Post by frag.machine »

In software Quake, it's just a color palette trick. In GlQuake, the engine actually generates skin copies for the player model.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
Ghost_Fang
Posts: 336
Joined: Thu Nov 12, 2009 4:37 am

Re: Player coloring system on custom models/entities

Post by Ghost_Fang »

Ok im using Kurok, which is GLquake, how would i replicate that effect on lets say a different model, not necessarily a player model and is it pretty memory efficient?
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: Player coloring system on custom models/entities

Post by leileilol »

it only works on clients. you'd have to rework the color processing with a new field sent by the server to work on other entities.

it's only memory efficient if you use software, since that method used a real-time palette row shift. GLQuake it shifts and makes a new loaded texture. Half-Life also does the same exact thing. This is why gl_playermip is advised for voodoo in glquake's readme (And should be advised on psp for the same reason since THE PSP IS A PSPIECE OF CRAPSP)
i should not be here
Ghost_Fang
Posts: 336
Joined: Thu Nov 12, 2009 4:37 am

Re: Player coloring system on custom models/entities

Post by Ghost_Fang »

so wait, for the PSP i should look into gl_playermip? Basically I want several or many variants of a particular enemy on my PSP game. So is that my best route?
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: Player coloring system on custom models/entities

Post by qbism »

The easiest way is just use multiple skins for the monster. Select the skin in qc ( self.skin) without an engine mod.
Ghost_Fang
Posts: 336
Joined: Thu Nov 12, 2009 4:37 am

Re: Player coloring system on custom models/entities

Post by Ghost_Fang »

well i knew that adding multiple skins was an option, im trying to avoid that option, especially for the psp, it costs memory and increases loading time.
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: Player coloring system on custom models/entities

Post by frag.machine »

With GLQuake one could mod the engine to generate 2 masked skins with pants and shirt colors, and using multitexture and color blending achieve the same effect. Not sure if Darkplaces works this way; I remember mh once wrote a tutorial to add fullbright textures in GLQuake using a similar way, may be a good start point if this feature doesn't exist yet.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: Player coloring system on custom models/entities

Post by qbism »

If I had a PSP, I'd write a software port. :wink:
Ghost_Fang
Posts: 336
Joined: Thu Nov 12, 2009 4:37 am

Re: Player coloring system on custom models/entities

Post by Ghost_Fang »

Hmm, ok so what would one suggest for the PSP (to be memory efficient) and for a programmer whose knowledge lies in QC and stops at editing the HUD engine side? :lol:
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: Player coloring system on custom models/entities

Post by mankrip »

Does the PSP support 8-bit indexed color textures? If so, use it, and implement individual palettes for each entity with custom shirt/pants colors.

It'll require more knowledge than HUD editing, though.
leileilol wrote:it's only memory efficient if you use software, since that method used a real-time palette row shift.
Actually not. What it does is to use a custom copy of the color shading map for each client entity, and each of those colormaps costs 16 KB (256*64) of RAM. So, using custom palettes can be even more memory efficient, since each custom palette would cost only 768 bytes (256*3).

The reasons why they've done it that way in software is because everything had to use the same palette due to the 8-bit color video modes, and using custom colormaps would perform faster than adding an extra color shifting step to the drawing algorithm.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Player coloring system on custom models/entities

Post by mh »

I remember LordHavoc telling me that he changed the colormapping in DP to deal with this without needing new skin uploads.

Skin changing in classic GLQuake is both memory inefficient and slow. Needing to generate and re-upload a new copy of each texture at runtime is very bad for performance, and in an intense firefight this may be happening many many times per second. Try the bigass1 demo if you want a good measurement of the impact of this on your framerates (you might want to switch off dynamic lights and particles so as to isolate the impact of skin changing better).

GLQuake also doesn't mipmap player skins which causes even more performance impact at runtime, even when skins aren't changing. On the PSP, needing to use compressed textures will make things even worse as the data must be recompressed before each time it is uploaded.

By far the fastest and most memory efficient way of doing this is by using a shader and some dependent texture reads. You have one texture of the base skin with the shirt and pants areas removed, one masking out the different areas in the skin (using the RGB channels) and then just set up a colour blend. In DirectQ I use a third texture containing a palette ramp for the shirt, a fourth containing a palette ramp for pants, and an optional fifth containing the fullbright pixels which enables the same end result as GLQuake. This gives absolutely no performance impact whatsoever when skins change and I can timedemo bigass1 at something like 600 FPS.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Player coloring system on custom models/entities

Post by Baker »

Better late than never.

I have not seen skin coloring implemented in any of the PSP engines (I'm talking hardware builds, not the WinQuakey software build).

Basically, all the PSP engines operate as essentially gl_nocolor 1.

The whole TranslatePlayerSkin ordeal consumes too much memory to be implemented in a Quake compatible way on a hardware accelerated video build for the PSP.

The code in GLQuake saves the skin off for every model (unlike Quakeworld which only saves the skin for player.mdl) and allocates a texture for every player and colors it in on every color change. Like stated above, this is all client side.

The multiskin method is the only viable option.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Post Reply