Contributing in 3D?

[kage]

we could simplify the texpages if we allowed for homeworld-esque palette replacement (though still allowing for traditional team color stuff for team logos, flags, etc).  it would also make games with more than 8 players much easier to implement, and allow for some real player color customization.

[Per]

we could simplify the texpages if we allowed for homeworld-esque palette replacement (though still allowing for traditional team color stuff for team logos, flags, etc).  it would also make games with more than 8 players much easier to implement, and allow for some real player color customization.

I don't know how Homeworld did its palette trick, but I am hesitant to take away the ability to hand craft each player colour. Not convinced that an automatic solution would be equally good. Also I am not a fan of "real player clour customization", because we need to make sure that the colours are clearly distinct.

[kage]

I don't know how Homeworld did its palette trick, but I am hesitant to take away the ability to hand craft each player colour. Not convinced that an automatic solution would be equally good. Also I am not a fan of "real player clour customization", because we need to make sure that the colours are clearly distinct.

i had thought of the color distinction thing... it's not too bad. if a player chooses a color, they essentially put a lock on a certain region of colorspace that no other player can get. server side, client color change requests (lobby only) can just be validated with a color distance check from all other players. optionally (preferably), the server would send color data to each client about all other players -- when selecting a color, the "locked" ranges could be displayed as a darkened circle around the colors selected by each other player: attempting to select a color from any of these locked regions would have no result, and the color selection widget would remain visible until a valid, unreserved color was selected.

if you look, i never suggested "taking away" the hand-crafted textures.  my (as of yet unspoken) idea was that polygons would have to be explicitly set to use the palette-replacement method to use it, therefore such paletted textures would have to be hand-crafted themselves for the palette effect.  this could be implemented as the 0x20000 flag for polygons in a PIE2 like spec.

homeworld allows a player to select dual colors, but my suggestion is that we would go with warzone's single color approach. i have no idea how homeworld actually implemented it, nor have i looked at any other implementations of palette replacement, but i doubt that anyone does simple 1:1 replacement since the doom era of games, as that would look pretty horrible and blotchy.  what i would suggest for warzone is similar in layout to the current team color, as it is the easiest way i can think of, while still allowing full use of the colorspace.

i am referring to a base texture + alpha mask system (i don't know if my terminology is correct).  see the attached image: the left part is the base texture, and the right is the mask.  to make it more clear (for demonstration purposes), the transparent (alpha 0) background has been replaced by magenta, and it has been scaled to be much larger.

the mask area should be treated as grayscale. programmatically, you can just use one color component, but as a rule, the modder shouldn't know or care which, if any, component is used, or even if the 3 color components are averaged into a gray value.  the value for each pixel in the mask should become the alpha component for a given selected player color.  in this example, black represents full replacement (the player color will be displayed exactly in that pixel), and white represents zero replacement (the corresponding base pixel is preserved intact), though whomever, if anyone, implements something like this may choose how to map the mask to the alpha channel. also, if any pixel already has an alpha value other than 255, the alpha value should be directly mapped instead of using one of the other components.  using the now colorized mask, just merge it on "top" of the base texture, and repeat this process for every player color. the results would most easily be remapped into a fresh texpage (one that probably shouldn't be cached on disk).

in the attached example, the base texture (left), has both grayscale regions (in terms of color value, not some kind of image format trick), and color regions. i am using the grayscale regions for plain luminosity (not sure if that term is correct either -- variations on the brightness of the supplied player color). the gold colored regions will be preserved in the final texture, since the mask specifies those areas alpha 0.

if any artists have worked with stuff like this, please comment with better ideas or suggestions.

[cathuria]

Cathuria: Could you look into extending the model's texture with team colour information as described in the link above?

Hmm... does this mean that the actual PNG image map, instead of 256x256, should actually be 2048x256, repeated horizontally eight times with different key hues on some surfaces?

That would actually be quite simple to do, if that's the case.  Or am I misunderstandifying the whole thing...?

[Per]

Hmm... does this mean that the actual PNG image map, instead of 256x256, should actually be 2048x256, repeated horizontally eight times with different key hues on some surfaces?

That would actually be quite simple to do, if that's the case.  Or am I misunderstandifying the whole thing...?

Each image element inside the PNG that should have a team colour needs to be repeated horizontally. The whole PNG image map does not need to be (and should not be) repeated eight times, and a 2048x256 texture for a single model component would be far too big. Yes, it should not be hard to do, just a little work.

[RBL-4NiK8r]

Well its been awhile but that looks like a Cyborg chest and head, and, tho you might have lost me as to what your trying to do, I know most of the Cyborgs looked like sh*t under the colors that Pumpkin used, and that back in my days that was one project I spent a lot of work on while I was doing my Snow Camo MOD for all of my Arttic maps. Personaly I never liked all the flashy colors that came with WZ on there vehicle bodys, and the way Borgs were most of there bodys were made up of the team color, and I had changed that to basicly the tops of there heads with a color strip and there back packs. Now I had also been playing around with a Woodland and Desert Camo, but dont recall how far I got with them, I know I finished my Snow Camo MOD for the most part, and that really changed the look of units, heck I even redid every pixel of the animation for the Borgs walking so it didnt look so cartoonish. Anyways from what I recall of unit color you only needed to be 2-3 pixels wide to be seen in game, and that Pumpkin went a lot more then that in some cases, and that just was a color overdose from my POV. I think some of the work I did on Snow Camo should be around somewhere, you might want to give that a look over.


4nE

[cathuria]

Each image element inside the PNG that should have a team colour needs to be repeated horizontally.

Hmm... some more.
So, I need to redo the UVs but have the part covering the 'team color' surfaces shrunk down to where it can be repeated eight times within the space of the 256x256 map.  Yes?
But the information (in the model file) that I will be able to export will still only point the UVs to one of those eight images... I still have no idea what may be going on in PieSlicer (perhaps I should learn that... aaargh!  My poor little brain already has too much new software to learn... whimper).
So... for starters, did you want me to put out a new file with the UVs redone as above and a new image map with the 8-color-repeaty thing?

[Per]

Hmm... some more.
So, I need to redo the UVs but have the part covering the 'team color' surfaces shrunk down to where it can be repeated eight times within the space of the 256x256 map.  Yes?
But the information (in the model file) that I will be able to export will still only point the UVs to one of those eight images... I still have no idea what may be going on in PieSlicer (perhaps I should learn that... aaargh!  My poor little brain already has too much new software to learn... whimper).
So... for starters, did you want me to put out a new file with the UVs redone as above and a new image map with the 8-color-repeaty thing?

Let's start with the texture, then I will look at making a program to set animation and team colours. If we say that you want to make the base of the ECM device have a team colour (I think that is the most sensible part), then it could be done like in the attached image, where I have rotated and scaled the base's texture to avoid enlarging the whole texture page (and I apologize in advance for mutilating your texture like this).

[cathuria]

Let's start with the texture, then I will look at making a program to set animation and team colours.

Are you saying that you won't need a new model with altered UV coord's, just the modified image map?

[kage]

Are you saying that you won't need a new model with altered UV coord's, just the modified image map?

depends what you have to shove around. if you've got enough spare space to have the teamcolored textures all lined up to the right of the original, then no, you don't need to change the uv coords. either way, you need to change the poly type to anim (teamcolors), and set the an anim params.

[Per]

What Kage said. If you could fit the team colour duplicates into the texture page without moving things around, then you don't need to alter the UV coords of the model. But since you won't be able to do that - I am pretty sure! - you'd have to update the model UV coords, too. Sorry if I was confusing about this.