zBase (32bpp base set by Zephyris)

[LeXa2]

Sorry for keep pointing on this but why don't change the used scheme entirely if the change is going to happen anyways? Why not to use a scheme like what was proposed by me?

Here is pseudocode of the concept that smells promising IMO:

Code: Select all

Blitter::Draw(...)
{
...
     c = this->LookupColourInPalette(PixelMaskIndex);
     v  = Pixel.r + Pixel.g + Pixel.b;
     *dst = this->AdjustBrightness(c, v);
...
}

static int DEFAULT_BRIGHTNESS = 192;
Blitter::AdjustBrightness(Colour c, Uint32 v)
{
... /* Exactly the same implementation as it were, maybe checked if data types used for temporarily calculations are wide enough (uint32 would do) */ ...
}

That way it would:
a) be possible to have even finer gradients in output than with 128 denominator and max(r, max(g, b)) nominator;
b) maintain backwards compatibility with the masked sprites that work now for cases where 32bpp pixels that are being recoloured are drawn with the shades of gray;
c) leave a lot of room for overbright purposes if gfx designer would want to use it (255*3/192 ~= 4x increase in HSV value, i.e. exactly matches current 255/64 ~= 4 max);

It also shouldn't have any implications on the performance as currently it have to compare r, g and b to find the max and with r + g + b it would do exactly the same triple memory access and two add/sub operations done internally in CPU ALUs.

What could be not so obvious with this scheme is that gradients like above wouldn't result in bandless output and one would have to use something like: (0;0;0) (0;0;1) (0;1;1) (1;1;1) .... (63;63;64) (63; 64; 64) (64; 64; 64) sequence to form a "gradient" that would result in bandless result without overbrights. Thus the blender output for areas where masks are expected to be applied would have to be processed (using gimp scripting or by some other means like python script) having 32bpp colours converted into 0..255 ranged grayscale and then this grayscale range mapped into values from the above "gradient" sequence. I could write a tool for doing this mapping in case there'd be need in it.

[Zephyris]

Thus the blender output for areas where masks are expected to be applied would have to be processed (using gimp scripting or by some other means like python script) having 32bpp colours converted into 0..255 ranged grayscale and then this grayscale range mapped into values from the above "gradient" sequence. I could write a tool for doing this mapping in case there'd be need in it.

This is the kind of thing I think should be avoided; remember us artists are simple souls who often don't understand or don't want to do strange post-processing things... I will try and find Xotic750 to see what he thinks...

[LeXa2]

... remember us artists are simple souls who often don't understand or don't want to do strange post-processing things... I will try and find Xotic750 to see what he thinks...

Sure. And artists are not the sole souls who like when things work transparently/obviously . If we'd live in an ideal world where it won't be required to dance with masks which operate in terms of the legacy 8bpp palette concept in the name of maintaining backwards compatibility I'd offer something entirely different for things like applying company colours onto the existing 32bpp sprite. Something like having a masked areas converted internally by the engine into grayscale using L* luminance and then coupling it with a pre-defined hue/saturation effectively making some part of the original 32bpp sprite being tonemapped into the required company colour. BTW it's possible to implement something like this even with current masking approach though it would have negative impacts on the performance due to conversion into L* grayscale followed by the tonemapping being somewhat more computationally intensive than the algo Blitter::AdjustBrightness() currently employs. But the benefit for gfx artist would be huge: he/she could proceed with designing a model using any tone he likes as a company colour and then use the mask (possibly also auto-generated by using smart rendering techniques in blender) to mark places which are expected to be recoloured into company colours. Much easier to understand and use, better from the visual quality PoV, e.t.c., e.t.c.

My main intention here is that it'd better to think now about what could be the best way/approach to implement in case it is agreed that changes are needed. As you noted before, now is just the right moment when it's possible to introduce invasive/severe change. Later on it'd be much harder so I'd be happy if in the end you and devs would come up with a solution that would allow for maximum "transparency" from design PoV and at the same time would produce visually perfect results (which can't be done obviously if you end up with a simple change of divisor from 64 into 128 a.k.a. use 7 bits instead of 6 for non-overbright portion).

[Xotic750]

Thus the blender output for areas where masks are expected to be applied would have to be processed (using gimp scripting or by some other means like python script) having 32bpp colours converted into 0..255 ranged grayscale and then this grayscale range mapped into values from the above "gradient" sequence. I could write a tool for doing this mapping in case there'd be need in it.

This is the kind of thing I think should be avoided; remember us artists are simple souls who often don't understand or don't want to do strange post-processing things... I will try and find Xotic750 to see what he thinks...

I felt when first starting with the new masking in the trunk that it didn't seem ideal. I tried multi-colour masks and found that they didn't work well at all. So, I opted to use a single colour mask to give me 8 steps of adjustment and then chose what seemed visually best to my eye. If the masking is changed then I don't think it will cause me any great issues, probably just a post-processing run on my saved raw images, at worst a change in my blender library and a full re-render. I am all for anything that improves the use and visual aspect of rendered 32bpp sprites, without detrimental effects to game play.

[Michi_cc]

The old 32bpp-ez patch has a more complicated recolouring (based on real HSV values I think). To do that, it executed a ~180 line floating point routine for each recoloured pixel. Not really the most effective use of resources.

-- Michael Lutz

[Zephyris]

The old 32bpp-ez patch has a more complicated recolouring (based on real HSV values I think)

It calculated the hue, saturation and value of the 32bpp pixel, altered all three according to the current recolouring, then converted it back to RGB. On the plus side it worked well, on the minus side it needed to know the colour of the 8bpp pixel before and after recolouring to calculate the hue, saturation and value shift required and was slooow!

[GeekToo]

Hi guys, been away for some time due to real-life.
Catching up on latest developments, and I think it's great what you're doing Zephyris. If there is anyone that can do a task like creating a full baseset, it must be you.

You got a nice discussion here about CC. You may know I have some experience with it, and it is a pain in the ass.
Michi is absolutely right that the last recolor mechanism in the ez-patch is much too complicated, and even worse, is using floats (i.e. slow like Zephyris noticed). It was implemented by Szvengar in one of my previous periods of inactivity, and I already started optimizing it to integral vars, but obviously, there is not much sense in completing that now.

Back to CC: it is complicated. One of the things that make it difficult is the fact that the company colours sometimes share the same hue, like white and grey, or yellow, orange, brown, or lightblue darkblue.

Which implies that you can not take all brightness values from the 32bpp sprite. The last 32 ez-patch did take the hue from the CC, and the saturation and value from the 32bpp sprite. That does look good, but also has a problem: white and grey CC look the same, so the 32 ez patch algorithm also was not perfect.

Some things that I encountered in the past:
-You want the full range from black to pure white after recolour. If you also colorize a white pixel in the source 32bpp sprite, you will lose the specular highlights, and that does not look good.
-Taking brightness values from the mask is unnessesary, only complicating stuff for graphics artists
-But you also want a difference between lightblue and darkblue CC.
-You want a relatively simple recolor algorithm for speed.

I gave this a lot of thought in the past, and a solution could be to define a midpoint, whose value is determined by the CC.
You determine the brightness of every pixel in the 32bpp source sprite by simply adding r+g+b (ranging from 0-3*255. And you want to map this to an output range of 0-3*255 too, but with a difference between white CC and grey CC.

Which means that the midpoint for white would be e.g. 2*255, and for grey 1*255.
In practice: if the value of the added rgb is < 1.5*255, multiply by the midpoint factor, and if the values are larger, multiply by another factor that can be easily determined by simple math. The midpoints could be determined in advance from the palettes, no need to do that for every pixel.
That way you would have the full output dynamics, and still have difference between CC of the app. same hue.

Hope this makes some sense, else I will try to make some charts.

[Zephyris]

-You want the full range from black to pure white after recolour. If you also colorize a white pixel in the source 32bpp sprite, you will lose the specular highlights, and that does not look good.

True, but I think the current multiply brightness by rgb and divided by a constant achieves this.

-Taking brightness values from the mask is unnessesary, only complicating stuff for graphics artists

this is also achieved with the current algorithm.

-But you also want a difference between lightblue and darkblue CC.

this I the main limitation of the current algorithm, as you have always have to pick a very dark mask colour. Changing the divisor to 128 would, IMO, solve this...

[peter1138]

-Taking brightness values from the mask is unnessesary, only complicating stuff for graphics artists

Brightness value of the colour in the mask is vital to be able to use the recolouring maps properly. Using a single colour in the mask for the whole image to be recoloured is not intended.

-But you also want a difference between lightblue and darkblue CC.

this I the main limitation of the current algorithm, as you have always have to pick a very dark mask colour. Changing the divisor to 128 would, IMO, solve this...

Or use a lighter mask colour and use a lower value in the 32bpp part, no?

[Zephyris]

-But you also want a difference between lightblue and darkblue CC.

this I the main limitation of the current algorithm, as you have always have to pick a very dark mask colour. Changing the divisor to 128 would, IMO, solve this...

Or use a lighter mask colour and use a lower value in the 32bpp part, no?[/quote]Yes, but:
[1] The current multiplication is so bright that this could generate colour banding.
[2] The edges of CC regions are tricky if the CC region is very dark in the 32bpp image. Think of CC neighbouring grey. The CC mask could ommit the anti-aliased CC/grey boundary -> a very dark boundary to the CC. The CC mask could include the anti-aliased CC/grey boundary -> a very overbright boundary. The CC/white boundry could not be anti-aliased, but this starts to defeat the point of 32bpp. [if the cc and grey regions were similar in brightness then it would be far less noticeable).

[LeXa2]

You determine the brightness of every pixel in the 32bpp source sprite by simply adding r+g+b (ranging from 0-3*255).

That's OK from out "programmers" PoV but isn't an obvious/transparent thing from gfx artist/designer PoV.

...Hope this makes some sense, else I will try to make some charts.

As for me, you're perfectly clear on what you write and everything I've read so far makes a good sense. Still IMO if we're discussing here "how to implement CC properly" in the broad definition of the "how" (instead of discussing something like "what is the minimal set of changes to be applied to the currently used algo so it would perform slightly better") then we should look at the problem at a bit different angle.

Let me try to summarize requirements that seem important to me wrt to CC and rest of recolouring matters:

• We want to make the process of designing new 32bpp sprites suitable for CC recolouring as simple as possible from gfx artist PoV. Best case is if it would be possible for artist to simply render out the 32bpp sprite with whatever colours it had been designed with and then render out same pic with another output settings which would produce mono-coloured mask that simply covers the areas that are about to be recoloured into CC by the engine. Same stands for other types of recolouring like church colours, city buildings colours, e.t.c.
• Translating source 32bpp pixel into recoloured CC pixels should be as obvious/transparent/intuitive as possible from artist PoV. We shouldn't to something like "pure white translates into CC, neutral gray - into black, and rest pixels got red on days from monday till friday and blue on weekends" .
• Scheme used should allow for easy and fast processing of the existing palette-remap-based recolouring for legacy 8bpp stuff.
• It should be as computationally cheap as possible (no - or minimum possible amount - of fp; minimum amount of branching; minimal count of mul/div/mod ops and memory accesses).
• Recoloured pixels should be allowed to map into either pure black and white with as smooth gradient transition in between as possible.

What we have at our disposal from the source data perspective are five distinct bytes representing each pixel. IMO in case we assume that expected CC recolouring results are pixels being various lights/shades of a single tone (i.e. we don't want to produce, say, red pixels when recolouring some sprite into dark blue CC) it is sufficient to only store two bytes for every pixel to be CC recoloured - namely "target lightness" and "target alpha" - so we're good to go here. It also means that we have three bytes - r, g and b - to be converted somehow into single value that'd be used as a "target lightness". The way we do this conversion determines would it be "intuitively obvious" for artist to use. With the scheme used currently it is not.

Next question to deal with is if we should make a distinction between existing available colours in CC palette range. I.e. we could possibly stick with the "CC recolouring" being mapping into pre-defined set of colours that are hardcoded into engine (or are supplied as a special "32bpp recolor sprites" in GRFs - which we would have to "invent" then) or we could use palette colour as a "base colour" to work with - like it is done now. For me second variant seems to be preferred while first one have a potential to be less complicated wrt computational complexity.

Now, having above written, here is my vision of the possible solution (as it looks to me now, as the view evolves as I spend more time thinking about this):

• 32bpp portion of the sprite: we either require grayscale here (i.e. r==b==g) or perform RGB=>Grayscale conversion of the fly using some proper luma weighting algo (CIE L* is my favourite here but it require more computation to calculate compared to simple gamma-corrected luma weigthing; simplier approximation could be used here - like Blitter::MakeGrey - if we'd stick with "on the fly conversion to grayscale" approach). What we want is to produce a single luma value to work with later on.
• 8bpp mask portion of the sprite: keep it the way it is now pointing to the in-game palette index that would be used as a "base colour" used for recolouring.
• Recolouring process: goal is to have a resulting in-game pixel luminosity to be in direct proportion to the source 32bpp pixel luminosity. HSL model fits well here. RGB->HSL values for palette colours could be pre-calculated on palette init (and re-calculated on PaletteAnimate() calls for affected parts). HSL->RGB conversion isn't the computation-free heaven but it is something that could be done in integer sufficiently fast. We use source sprite 32bpp luma as a factor to modify base CC colour L value in a way so for source luma == DEFAULT_BRIGHTNESS we end up with L unchanged, for source luma == 0 we end up with L == 0 and for source luma == MAX_BRIGHTNESS we end up with L == 255. What it basically means that we want to interpolate between three given points using any interpolation technique we would find reasonable. It could be simple linear interpolation approach or something more fancy (but computationally-demanding) like plain-old cubic splines or even "forget about performance" variants like weighted B-splines. I'd start with implementing simple linear interpolation and staying with it as long as it would produce visually pleasant-enough results.

How does it differ from the existing scheme:
a) luma a.t.m. is assumed to be the same as V value of the pixel converted into HSV. It is not the best choice and that one of the reasons behind the tendency to produce overbrighted pixels (illustrated here: http://en.wikipedia.org/wiki/HSL_and_HSV#Disadvantages);
b) AdjustBrightness which currently serves as an interpolating function have a response curve that "skyrockets to the lights" with brightness increase and only starts to "compensate for overbright" when V value hits maximum at 255. If you plot Y'601 or Y'709 curve for this algo it'd look like straight line up to DEFAULT_BRIGHTNESS and then it would slow down "raise rate" (decrease acceleration/second derivative) a bit. For most CC colours it'd hit max 255 value long before input V would reach 255. Having divisor changed to 128 simply stretches response curve 2x relative to input V value giving much wanted precision at darken part (V<128) but cropping lighten part so for some (probably, most) CC colours saturation into white is no longer achived even at input V=255.

I've made a spreadsheet with graphs in OpenOffice Calc which could be used as a good "learn by experimenting with numbers" appliance. You could find it in attachment along with two PDF exported from it illustrating response curves for existing implementation vs. proposed HSL-based implementation for divisors equal to 64 and 128. IMO looking at graphs helps a lot to understand the problem we face and what benefits would HSL-based approach provide.

P.S. Looking at the graphs it actually is obvious that for "plain simple linear interpolated" L response curve there's no need at all to convert to/from HSL - recolouring would be just a matter of calculating three linear interpolated values - r, g and b - with a knots at input V == DEFAULT_BRIGHTNESS for r, g and b set to values taken from the company colour. Using HSL and interpolating L value would only be reasonable in case response curve interpolation calculations are way more expensive than HSL->RGB conversion.

[Zephyris]

The issue with the HSV system you suggest is it forces all recolouring to go to white for the brighter shades. Using the brightness*rgbvalue/128 I suggested it would be an artist configurable option; use a mid CC palette entry for recolouring which does not go to white in the highlights, use a light CC palette entry for recolouring which does go to white (or near white for some of the darker CCs) in the highlights.

[LeXa2]

The issue with the HSV system you suggest is it forces all recolouring to go to white for the brighter shades. Using the brightness*rgbvalue/128 I suggested it would be an artist configurable option; use a mid CC palette entry for recolouring which does not go to white in the highlights, use a light CC palette entry for recolouring which does go to white (or near white for some of the darker CCs) in the highlights.

It's HSL, not HSV - they're pretty different for our matters. Yeah, scheme I suggest implies response curve that for input luma == MAX produces white. If a place that is expected to be masked is rendered in grayscale or in shades of a single colour - having response curve like proposed makes things work "as intuition suggests" producing white where 32bpp pixel is white and producing black where it's black. TBH what we're discussing here is just a shape of the response curve. Assuming that (a) we're not limited by the precision of calculation (we are, but let's omit this for now), (b) the response curve is selectively monotonic (first derivative is defined in every given point between 0 and MAX) and (c) selection of the base CC colours is wide enough to cover most of L* ranges for the given tone - visually same recolouring could be achived no matter the form of the response curve as long as you "cook" your mask and 32bpp pixels properly.

Thus main question to answer here is: what are your expectations about the way things work? If that's "I'm satisfied with the current scheme and only want to have more precision in dark parts coupled with smaller response to each +1 V increase; I would use some form of a black magic to generate or hand-craft masks using lighter/darker base CC colours to control overbrighting" - then it's enough for you to simply change divisor to 128 and live with it. If not - then you'd have to formulate more specifically what your expectations are .

Upd. Uploaded pic showing results of proposed HSL-based approach + DEFAULT_BRIGHTNESS==128.

2012-08-17-OTTD-Recolour-Pic#01.png (8.12 KiB) Viewed 3450 times

[Zephyris]

Upd. Uploaded pic showing results of proposed HSL-based approach + DEFAULT_BRIGHTNESS==128.

2012-08-17-OTTD-Recolour-Pic#01.png

Well that does look rather good, and would be very compatible with most existing graphics.

[blaou]

Hello, first post and i start off with few problems.

I can't download zbase, connection always cuts. Is there a mirror link?

Edit: wow, finally got the whole file

ZBase doesn't show up under "Online content service" in OpenTTD.


These links are broken (readme.txt).

2. Next, download the latest zBase package. There are a few sources:
- the development homepage http://bundles.openttdcoop.org/zBase
- official mirror: http://www.openttd.org/download-zBase

[planetmaker]

ZBase doesn't show up under "Online content service" in OpenTTD.

These links are broken (readme.txt).

2. Next, download the latest zBase package. There are a few sources:
- the development homepage http://bundles.openttdcoop.org/zBase
- official mirror: http://www.openttd.org/download-zBase

He, good find... the "official mirror" does not yet exist I fear. That's what one gets for a simple copy&paste
It's also not yet on the online content service as it's both, still in development and the content service can't yet deal with its size. Should thus be changed, too, I guess.

[Zephyris]

Yeah, the readme does need correcting...


Re: CC/Recolouring
I would like to see this sorted soon, what kind of consensus feeling do people have?

[LeXa2]

Re: CC/Recolouring
I would like to see this sorted soon, what kind of consensus feeling do people have?

Dunno what devteam thinks on this, hope they would come up with some resolution soon. As for me, I've spent half a day this weekend experimenting with other types of interpolation to use in the proposed recolouring scheme. Interpolation to use here should be monotony preserving thus natural cubic spline isn't suitable for this case. Experiments/drafts I had hacked in OOCalc show that Hermite-spline based algos - namely Catmull-Rom spline interpolation or Fritsch-Carlson monotone cubic interpolation - might be a good choice here to replace linear-interpolation. What I'm doing right now (not as fast as I'd wanted to because of other IRL duties) is benchmarking the computational cost of the spline-based approaches vs. linear-interpolation vs. original AjustBrightness() implementation. Hopefully I'd come up with numbers today or tomorrow late evening, depending on the amount of "free" time I'd have from IRL duties.

P.S. Having spline-based interpolation in place of linear interpolation could be implemented as a user-configurable option so one could chose if he/she wants to trade max FPS for better visuals and vice verse. "Better visuals" here means a bit more smooth gradient transition compared to one on the pic I've posted earlier demonstrating the results of the linear-interpolated approach.

[planetmaker]

Hopefully I'd come up with numbers today or tomorrow late evening, depending on the amount of "free" time I'd have from IRL duties.

P.S. Having spline-based interpolation in place of linear interpolation could be implemented as a user-configurable option so one could chose if he/she wants to trade max FPS for better visuals and vice verse. "Better visuals" here means a bit more smooth gradient transition compared to one on the pic I've posted earlier demonstrating the results of the linear-interpolated approach.

I've now seen many many lines with words and some images on what is supposed to looks better. But nothing really visually catching which shows me the performance impact of all these suggestions. I guess without good argument in that direction...

I don't want to sound rude nor do I find it uninteresting. But I'm afraid it starts to become tl;dr to make a good decision without re-reading many lengthy postings all again. And without a concise summary of your suggested changes, the current implementation and the implications of your changes, especially also for example wrt speed impacts on both an empty game and maybe coop game 200 or 201..

[LeXa2]

...shows me the performance impact of all these suggestions. I guess without good argument in that direction...

That's exactly the reason I've been quiet last few days in this thread . Having a proposal without actual reference implementation + results of benchmarks isn't of a much use really (except for curiosity matters like "is it possible to do this way?" and "how would it look like?" - which is enough for me but... ). Thus what I want to come up with finally are two or three patches with "reference" implementations + benchmarks showing "the difference" for the worst case (it terms of "pixels per second" processing speed) + pics showing visual changes. Pics are hardest to do here as there are not much of 32bpp masked sprites to work with so I have to stick with something like "gradient masked sprite" Zephyris posted earlier in this thread.

Upd. Yet another question to devteam (I know it's offtop here but as we're anyways discussing zBase-related offtop...): is the grfcodec's issue tracker located here - http://dev.openttdcoop.org/projects/grf ... query_id=5 - a correct place to post grfcodec's bug reports to? As I posted a report there days ago and it doesn't seems that there'd been any reaction (like comment or issue assinment to one of the devs, e.t.c.) up to now.