NewGFX company colour overlays (and shadows)

Alltaken · Post by **Alltaken** » 23 Jun 2005 05:55

Hi guys, i am working down my todo list for things to complete these holidays. and one of the todo's is to finish defining all the important elements of the NewGFX format. so that coders, and artists can feel comfortable in continuing without my input. and without having to get hung up on problems.

-----disclaimer don't judge the lighting or visual quality of the vehicle it is mearly a test of colours it does not poses the feel the GFX in the game will have.------

here are some images for the vehicles. basicly an example of how 'I' envision the shadows, company colours, and base vehicle sprites working.

Base GFX - RGBA - (any company colour area is set to a white material, dirt and other things which would alter a company colour can be applied to this material, and it will be visable after company colour is applied)

Shadow - RGBA - ( the shadow intensity can be controlled within the game, it could be made so that a mouse hover over a vehicle flips the shadow to white, to show that you will click on it. the sprite below the shadow is filtered through its alpha channel)

Company Colour - RGB - (the company colour has 3 colours, R, G, B, which are treated as 3 greyscale images by the game. these channels can then have Hue, saturation, and lightness applied to them to achieve any of 16 million possible company colours. so up to 16^3 colour combos depending on the company colour choosing interface)

quick photoshop version of this in practice. (just photoshoped, but the game would be able to do it on the fly i would hope)

my request is that a coder (possibly mek) is able to code something into OTTD 32bpp suport which can handle an RGB PNG as a company colour overlay.

the colours were "multiplied" (in photoshop) over the base sprite in order to achieve the shaded final view.

the Red channel is company colour No 1
Green channel is CC No 2
Blue channel is CC No 3

thanks people.

uploaded .zip files of the base sprites and the CC sprites are as follows.
http://ottd.mudpuddle.co.nz/testfiles/col.zip
http://ottd.mudpuddle.co.nz/testfiles/base.zip

Alltaken

bobingabout · Post by **bobingabout** » 23 Jun 2005 08:01

looking good. kinda looks something like my idea

mkxx · Post by **mkxx** » 23 Jun 2005 09:50

It looks like good idea! Good.

oboka · Post by **oboka** » 23 Jun 2005 10:14

Won't it be too much sprites to draw and to download?

Anyway, if it is possible its a great idea.

I could write a little program to test your idea.

Alltaken · Post by **Alltaken** » 23 Jun 2005 10:19

oboka wrote: I could write a little program to test your idea.

that would be excellent.

Won't it be too much sprites to draw and to download?

define to much.

looking good. kinda looks something like my idea

yeah thats why i said i already had it sorted

Alltaken

bobingabout · Post by **bobingabout** » 23 Jun 2005 12:14

are you the 1 who would be writing the new 32 bit graphics engine?

Mek · Post by **Mek** » 23 Jun 2005 12:16

bobingabout wrote:are you the 1 who would be writing the new 32 bit graphics engine?

no.. that would most likely be me. basic 32 bit support is working, now i'm trying to add sprite-recolour support, and the above mentioned company colour system.

bobingabout · Post by **bobingabout** » 23 Jun 2005 12:22

32 bit suport is working eh? would that allow the day/night cylces patch to have 2 palletes? 1 for GUI, other for the other things?

mkxx · Post by **mkxx** » 23 Jun 2005 12:41

bobingabout wrote:would that allow the day/night cylces patch to have 2 palletes?

Now - system supports 256colors - that's 8bits. So we need a palette for it. AFTER system will support 32bits-colors - that's about 16millions color and transparency - we will not need to have pallettes. We will be able to use every color we want ;)

SkeedR · Post by **SkeedR** » 23 Jun 2005 14:25

O_O

Wow, that is good.

EDIT by Owen: Turned all the table-breaking rubbish into proper English. Please don't do that again.

Seven Force · Post by **Seven Force** » 23 Jun 2005 14:51

weirdy, you're table-breaking. Either remove it or put some line breaks in there.

Sellu · Post by **Sellu** » 23 Jun 2005 15:22

I have to give a try to that too;)

Alltaken · Post by **Alltaken** » 23 Jun 2005 16:58

Sellu if you want to test it on some of your vehicles, i would love to see the result.

just keep in mind that R,G,B are important in that order. so assign the colours from largest area to smallest in that order.

i would also love to see some dirtyish vehicles done like this, to see how dirt and grime reacts to the company colours being overlayed over the top.

Alltaken

Mek · Post by **Mek** » 27 Jun 2005 07:40

This is how it'll currently look like in my implementation (wich is cheating in quite a number of places, i just can't seem te find the correct formula, can somebody perhaps give me a simple formula that given the Red components of the three company colours (RC1, RC2, RC3), the RGB values of the company colour overlay sprite (CR, CG, CB) and the Red value of the base sprite (RB) returns the Red component for the pixel that should be drawn?

Alltaken · Post by **Alltaken** » 27 Jun 2005 08:24

(User selected company colour/255)*Red channel of the CC overlay (multiply all channels by the red channel value)

then with that number Multiply it with the base sprite colours (channel for channel, don't mix the channels anymore)

then divide all channels by 255.

this should be the final outcome.

if the CC overlay is somthing with mixtures of two colours i.e. red and green. then you will need to do the calculations for both, and then "mix" the results. so add them then divide by 2.

Multiply
Well, I didn't really understand how this worked, so I'll fill in Quartic's elegant explanation along with my own commentary:

From: Federico Mena Quintero
Reply to: quartic@polloux.fciencias.unam.mx

Multiply - Multiplies the pixels of one image by the pixels of the
other one. If the pixels were in the real range [0, 1], it could be
viewed as

for (every pixel)
dest_pixel = source1_pixel * source2_pixel;

And this would also produce values in the range [0, 1]. However, our
integer values are in [0, 255], so the actual formula used is

dest_pixel = source1_pixel * source2_pixel / 255;

This is to 'bring back' the values to [0, 255]. Note that multiplying
an image by another one always darkens the result. This is because a
number in the range [0, 1] multiplied by another number in the same
range will always be smaller than or equal to either of them.

Basically, this treats both images as being of "unit brightness" (I think that's the right term), in other words, with a maximum brightness of one and a minimum brightness of zero. It then multiplies the unit brightness of each image together. Since multiplying anything less than 1 by something else always results in a smaller value, the image always gets darker.

DaleStan · Post by **DaleStan** » 27 Jun 2005 08:42

OT: I like that grass. You might yet convince me that 32bbp is a good thing. The shadows need to be lightened, though. (Translation: gruff compliment for a feature I'm not yet convinced is desirable.)

If you scale each to [0,1] and then do min(RC1*CR+RC2*CG+RC3*CB,1)*RB; what happens? Obviously, it would be perfectly possible to overflow the color range without the min, but if you do (RC1*CR+RC2*CG+RC3*CB)*RB/3 instead, then I fear a major lack of contrast.

Averaging the HSV coordinates (instead of the min call) would probably also work, and might well be better than RGB-multiply-and-add. RGB averaging would not work; if first two company colors are FFFFFF and 010101, and the overlay is #FFFF00, the result should obviously be 808080, but if the colors are FF0101 and 01FF01 do we really want a result of 808001? Averaging the HSV coordinates returns FEFE01 instead, which is a more desireable result. (at least IMO) (I was actually hoping to get FFFF01. Better accuracy in the HSV conversions might return that color, but the idea remains the same.)

Alltaken · Post by **Alltaken** » 28 Jun 2005 01:16

dalestan, actually i would probably think the yuck brown is more accurate than the yellow when mixing red and green

(i use paint, os thats what i expect)

but averaging the HSV stuff would make a lot more sense i think.

Alltaken

Hackykid · Post by **Hackykid** » 28 Jun 2005 11:52

Hmm, i dont know much about this stuff, but this is what would seem most logical to me:

min(1, (RC1*CR) + (RC2*CG) + (RC3*CB) + (RB * max(0,1-CR-CG-CB)) )

this way you can just set percentages for each of the company color, and the percentage that is left (1-CR-CG-CB) gets used for the original color.

PS. i have no idea if this will work out, how it will look, or any of that stuff, this is just what seems most "logical" to me, from a math pov. Still might be an idea to try out.

Mek · Post by **Mek** » 28 Jun 2005 12:53

Hackykid wrote:min(1, (RC1*CR) + (RC2*CG) + (RC3*CB) + (RB * max(0,1-CR-CG-CB)) )

With this formula if either of CR, CG and CB is 255 none of the orriginal sprite is used.... so shadows/dirt will no longer be visible i think... (and i think some more problems which i can't think of right now will also occur...)

dmh_mac · Post by **dmh_mac** » 29 Jun 2005 10:00

Perhaps this can be of some help...

http://www.pegtop.net/delphi/blendmodes/

Probably not though

Transport Tycoon Forums

NewGFX company colour overlays (and shadows)

NewGFX company colour overlays (and shadows)

Who is online