[32bpp/EZ]BRIX!!!

[MonkeyDrone]

all praise VMR! V453000 Mater Race for the uninitiated.
The noise definitely adds more life to the art. Which translates to adding noise to a lot of other content and more work. Yarrrr,
All the best mister

And what does this mean for the 0.0.1 RC? pushed back a bit longer?

[V453000 :)]

Thanks!

The best part about this is, as I mentioned I can do this in times when I am not at my desktop PC, which basically means I'm not really delaying the first release, just using unutilized time to make it look tons better.

Of course it costs a little more time, but in the amount of work needing to be done on trains, it's basically zero.

To put it into comparable context, I have maglev tracks almost finished with this, that took on and off let's say 6-8 hours.
Integrating them into the workflow will take about 1 more hour, and done.

To compare it, modelling one train with full details, materials and everything, takes just metric shetton of hours, and there is many trains. This is hard to express in numbers because the work times vary and I haven't counted them at all, but work on a single engine is in a matter of days even if I'm very active with it. [of course assuming not working 12 hours a day which isn't going to happen anytime soon. ]

V

[V453000 :)]

Hello!

It's been a while, I have been doing all kinds of things including some work on BRIX.

This time I have barely touched 3D files though! ...

As one of the long term plans for BRIX I was always thinking that it needs to work great not just in x1 zoom, but also in 8bpp.

Main problems of 8bpp converted from 32bpp:
* 1. I could only do it in photoshop (so far)
* 2. Whenever the pixels would be semitransparent (alpha not 0 or 255), photoshop uses some matte/background and it blends the pixel with it before converting. This has various answers, you can blend it with white, black, middle-gray or just alpha blue. All of these values however look wrong in some cases, though the middle-gray seems best. In the picture I show also blue to make it clear what's going on.
* 3. I had to do each picture manually (because of photoshop) ... I probably could have made some photoshop actions or scripts but yeah, no...

Python 4 LYFE!!!1!1!!1!!!
So I was thinking about writing a python script (yes I know, C program would do it faster but I have many uses for python and have the will to learn it for that reason ) which converts the 32bpp images into 8bpp automatically, and allowing me to solve the alpha problem in a way I like. On top of that I can control what it's doing, and add parameters which will let me ignore company/action colours.

Alpha Handling
The alpha handling is it's own world of problems - currently I am reading the alpha of the 32bpp pixel. If alpha is less than 50% (almost invisible), the pixel just gets thrown away (you can see in that parts of the tubular bridges have bigger gap between them, that's what causes it at the moment).
Pixels with more than 50% alpha, but under 90% (almost fully opaque) get processed - if the colour of the pixel is dark, the value gets brightened, if it's bright, it gets darkened. This way it makes a nice edge which adds some shading/volume effect, which I like quite a lot so far. This function is currently very primitive and will need further attention, but this is the general idea of it.

Colour Comparing
When it comes to the colours themselves:
First I load the palette colours from a small PNG ... they are of course in the correct order which tells their ID.
After that I go through every pixel of my 32bpp spritesheet and compare it's colour to all of the palette colours.
The comparing can be done in many ways, right now I am visualizing it as RGB is a cube with each dimension being 1 colour, each of the 2 colours has a place in the cube, and I am calculating the distance between the two points.

Code: Select all

(cr, cg, cb are values from palette, pixRed,pixGreen,pixBlue are values from the 32bpp image ... in this calculation they are interchangeable)
red difference:    dr = pixRed - cr
green difference:  dg = pixGreen - cg
blue difference:   db = pixBlue - cb
distance = dr*dr + dg*dg + db*db

Note: for proper distance I would need to make a square root of this, but since I would be doing that for everything I thought I might as well just leave it out for performance reasons.

Note2: I also find it quite interesting to note that photoshop seems to actually use this formula to calculate the differences, or at least it seems that way since it gives exactly the same results. Of course photoshop does it much faster than my puny python script so far, but let's see about that later.

This method is very simple and easy to do, and I really like what it does so far. It just sometimes doesn't do quite what I would like - for example you can see that a part of the tubular bridge is yellow; I don't want that.
So I am going to try some more elaborate ways how to calculate this distance between colours. Right now I am looking at CIEDE2000 which I am not going to write myself (the formulas for that are insane) but I'll get some python modules which have it already implemented. And let's see what does it give.



Performance
Another issue is the performance. BRIX currently has a few spritesheets which total 329 523 200 pixels (yes 329.5 Megapixels). For all pixels with alpha above 50% (actually minority but still a lot), the script compares the pixel colour to 256 palette colours. With my first attempt, this was insanely slow - 53Mpix image took around 90 minutes to process.
Then Alberth and Cube (colleague from factorio) helpeld me optimize it by just tweaking small things and today I have been able to process about 250Mpix of pictures in just something around 49 minutes!

To optimize further, next I am going to try a different function for taking/saving the pixels (atm using getpixel() / putpixel() ) - Pixel Access im.load() and out.load().
If that's not enough, I'll try to rewrite it for numpy and if I feel particularly brave I will try to get it to run in PyCUDA because I have a really good graphics card. From what I understand, the numpy and PyCUDA approaches would be working on a big array of pixels at the same time so the time could get almost instant, but let's see about that.

And there is a could of other things to make it run faster, like not actually going through all 256 palette colours, but ignoring the special colours (and perhaps even some other colour in some cases - when I feel like some results aren't nice, I can just manually tell the script to ignore that colour and try again, like with the tubular bridges I would just tell it to ignore this specific shade of yellow).


The Usefulness And Outputs
Last but not least, since this converting is already giving me great results (I actually like the 8bpp pictures more than the 32bpp ones), I'm starting to seriously consider making BRIX not 32bpp, but 8bpp. It would still keep the Extra Zoom obviously, and I would probably also release a non-bananas version with the same grfid for people who Really want the 32bpp version (the alpha will still be nice in some parts like the tubular bridges but I'll try to use a dithering-style technique for the transparency even in 8bpp).
This would decrease the filesize of BRIX massively. Another concern I have been seeing recently is that 32bpp seems to work very poorly on totally random computers. Sometimes people with laptops complain, but sometimes also people with top class workstations have issues. And it's not just people from openttdcoop where we have thousands of trains, though the other reporting people might have just used giant maps, I don't know. Regardless, avoiding this whole problem just by keeping the main official BRIX version 8bpp sounds great to me right now. (my mind can go 180 easily )
And it's not just having less to download, the computer having less to run/load. It's also the better consistency with the rest of 8bpp NewGRFs. 32bpp is wild as it allows you to use such a huge range of colours that it actually becomes hard to make them match OpenTTD's palette. And you either match the palette, or you have to replace everything, otherwise the game will always look weird. By using the palette, this point is almost automatically checked and it will always look more consistent with other older NewGRFs or base sets (hopefully - converted 8bpp from 3D is still very smooth compared to hand-drawn pixel art so let's see)


The Script - Palette-Converter-1-7.py
I'm attaching my latest work-in-progress python script here, along with the main input you need - the PNG it takes the palette colours from. https://paste.openttdcoop.org/pfsaafgji You can use it for whatever you want, consider https://en.wikipedia.org/wiki/WTFPL to be it's license. If you would be so kind and tell me that you are using it, it would make me happy though.

Requirements: Python (I'm using 36-32 atm) and some good recent version of pillow
Note: at the moment it's not actually saving a 8bpp image, just normal RGBA with palette colours. I still need to do the last step of saving it as actual 8bpp...

This is basically what I've been doing lately, apart from going nuts with painting postproduction on tracks & trees on my new wacom device (both tracks and trees are almost done).
Hope you find it interesting, be it the process or the product and thank you for reading if you got all the way here

V453000

[Arveen]

<V453000> nobody replying to my brix thread

There you go. Enjoy that sweet reply

[SyberSycho]

Personally don't care much for the 8bpp conversion but I can see the usefulness to make others mods not look out of place if they were build for 8bpp in mind.

I just gonna wait patiently to see the beauty of your work when it's ready for release.

[V453000 :)]

Personally don't care much for the 8bpp conversion but I can see the usefulness to make others mods not look out of place if they were build for 8bpp in mind.

I just gonna wait patiently to see the beauty of your work when it's ready for release.

It's mainly very important because the official bananas version might end up being exclusively 8bpp only

[andythenorth]

I am totally in favour of the 8bpp release, you will be shocked and surprised about that.

Python image processing ftw. Less yak-shaving.

[oftcrash]

Less yak-shaving.

I laughed out loud at this. We used to use this phrase were I worked quite a bit and I've had to explain it quite a few times to people not in IT.

[Sova]

The 8bpp looks really nice. Some more color tweaking is definitely needed but it keeps the soul of Transport Tycoon in mind. Don't get me wrong I love the 32bpp version as well!
Looking forward to a release and hopefully by then my cracktorio addiction will go away .

[V453000 :)]

Hi, I have finally released BRIX 0.0.1. Even though I wanted the first version to have more and be better, here it is.

You can read more info https://blog.openttdcoop.org/2017/04/01 ... -released/

[peter1138]

Damn this is good so far

[SyberSycho]

Looking great so far and I'm really glad you released a playable version for us, as I absolutely love the signals. I have noticed they can clip through bridges they are underneath though. I'm currently using zbase to fill in what isn't done and it look alright but not as good as I know you will make it. Tried having your trains enabled but I think I'm going use the zbase ones for now as I don't enjoy a large gap between wagons on the angled track.

Keep up the awesome work!

p.s. The signals alone to me were worth the release. The tracks are also amazing.

[Alberth]

Tried the set for a little while.

It looks very weird, that very evenly coloured ground, but it's very clean in displaying what is set up:

brix_nuts.png (171.78 KiB) Viewed 6438 times

Just BRIX and NUTS, and nothing else, so industries etc are all default.

Very cleanly visible how all the tracks go here. Farm fields look very off, although for contrast with the empty ground it's not even looking bad.

brix_ore_loading.png (189.26 KiB) Viewed 6438 times

I am not so sure about the 'holes' spread all over the map, they are 'rough area', the black-ish tiles seem nicer to me, less distracting.

[SyberSycho]

One thing I miss more than I realized is being able to see the grid of the map. I don't know if that's an easy addition or not though.

[V453000 :)]

Thanks for the feedback guys, it makes me think about it further...

- super clean tiles will be replaced by noise, aim is to have something roughly similar to original TTD set

- grid is going to come back, probably very subtle, but will be there. It helps with so many things like tiling and orientation in the map.

- I even have some version of farm field 3D models, just never rendered them. Eventually...

Lately I am working on finishing the photoshop postproduction which makes pretty much everything at least 2 levels nicer. Onwards to 0.0.2 ... which probably still won't include proper vehicles :0

P.S. Alberth you better burn for the heresy of using only PBS and making it look ugly with only red variety ftw, stop racist vs. block signals

[SyberSycho]

P.S. Alberth you better burn for the heresy of using only PBS and making it look ugly with only red variety ftw, stop racist vs. block signals

You got told, lol.

Can't wait to see how great is looks with all the PS stuff put in.

[V453000 :)]

P.S. Alberth you better burn for the heresy of using only PBS and making it look ugly with only red variety ftw, stop racist vs. block signals

You got told, lol.

Can't wait to see how great is looks with all the PS stuff put in.

Yeah, me neither, but in general it's really massive ... from the noise through grid to simply better contrast & detail, and I am also colorizing trees in Photoshop

[Kalen]

Still using block signals in 2017 is a danger to public health... they just ought to be removed, along with canals. And maglevs. :^)

[robo]

Thanks for the feedback guys, it makes me think about it further...

- super clean tiles will be replaced by noise, aim is to have something roughly similar to original TTD set

- grid is going to come back, probably very subtle, but will be there. It helps with so many things like tiling and orientation in the map.

- I even have some version of farm field 3D models, just never rendered them. Eventually...

I'm not really an openttd player but there's nothing wrong with clean ground textures, but there could be some variation in colours like in this mod for age of empires:
https://www.youtube.com/watch?v=z5VusA9beuw
The light shading/shadows look good and the right choice of colours is pretty important. The good colours of the AOE2-mod are probably not supported from the 8-bit colour palette of openttd or would require 100% dithering.
Perhaps you get rid of the stupid fences near railroad tracks and add some better basic production chains to vanilla version (Steel production needs coal, who really wants masstransport of gold or diamonds ...)

[R2T9]

Hey V!

It's been a long time since we heard from you and probably a longer time since I've played OTTD...lol!
Browsed through the entire thread today just as a refresher, and dang it was pretty awesome to see the progress!
Speaking of that, how's BRIX going? And on page 4-5 of the thread...there was a mysterious train set...any news on that?
Hope all is well!