The International Simutrans Forum

Development => Technical Documentation => Topic started by: NNW on March 07, 2016, 08:53:06 AM

Title: Support for PNG Alphachannel for tree graphics
Post by: NNW on March 07, 2016, 08:53:06 AM
Support for PNG Alphachannel for trees would be fine, because making "nice looking trees" is atm very hard.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on March 07, 2016, 12:29:06 PM
Alphachannel would be great for everything, not just trees. However, there are some older threads (Like http://forum.simutrans.com/index.php?topic=9113.0 or http://forum.simutrans.com/index.php?topic=10892) which indicate that it's a significant performance hit if done with the current graphic system and a lot of work otherwise.

Anyway, I am all in favour for pretty much any suggestions on how to do it in the aformentioned threads. Even just 50% transparency could be huge for creating anything made of glass, shadows, and very small details.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Ters on March 07, 2016, 03:58:06 PM
Unfortunately, 50% is just as slow as all they other percentages, except 100% and 0%. Dithering transparency, as is done for some tree shadows in pak64, is the only option in the foreseeable future, I think.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on March 07, 2016, 08:16:33 PM
Yet we do have transparency in the marker of the mouse cursor, and can display transparent station coverage, transparent trees, transparent buildings, transparent reserved ways,... The game already gives you the option to have a screen composed of ground and overlapping transparencies. Not sure why that's better than having transparent AA-pixels on the edge of objects, of which there would be significantly fewer on the screen.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Ters on March 07, 2016, 09:40:53 PM
A single transparent mouse cursor is something completely different from thousands of transparent trees, plus possibly other objects. Transparent hiding is an option one can easily turn off if it kills performance. (Is it even on by default?) I'm not sure how easy it is to switch off transparency that is embedded in the image, and also keep things looking decent.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: An_dz on March 07, 2016, 10:50:36 PM
As to explain, transparent trees and buildings are simply one coloured masked transparent objects.

As for images you are adding 8 bits per frame, that enlarges a lot the number of data. Every pakset will enlarge by 4/3 of its current size.

pak128 which now has 402MB would go to 536MB. That's the first impact of adding transparency, the way Simutrans deals with the graphics might not be ideal for adding 8 bits.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 07, 2016, 11:23:32 PM
Within the current system you can draw a bitmap either normal or transparent. Mixing them is not really implemented. The most difficult reason is probably on how to decide to deal with resizing of the bitmaps. At the moment the special colors tend to "bleed out" when resized, to preserve the night time feeling. However than would not work for shadows.

The performance hit may be not much worse than special colors, apart from requiring a read before write.

But the first thing to get clear on:
What would be possible, if the resizing is solved:
- It would be: 25% transparency->75% darker, 50%->50% and 75% transparency->25% darker.
- What not would work in the current system at all is color blending. (Or, to be more specific, what could work is color blending with a special color. But I would have no idea have to prepare a single layer PNG to achieve that.) In the Simutrans bitmap, a Pixel is either solid color, or a night color (special). With have more than 30000 night colors left, so there could be 226 shades of transparency easily added (and maybe 3 grey levels).

If there is a consent that already simply darkening is enough, then that could be probably encoded using the tranparency if >12% into three levels and make the image transparent whenever background==255,255,231 and transparency>87,5%.

Since shadows overlapping into foreground (which may happen with trees) will be cut, or might cast very weird shape on things in front of them. Depending on vehicle drawing order the shadow of vehicles would be jumping between tiles. (It does for planes, but those are fast, and have no trailer, so one does not notice it much.)

But this requires some new reserved colors and then again lots of drawing errors after running makeobj on old PNGs.

Or somebody comes up with a good solution on how to use the alpha channel to create a transparency special color in three levels (but only in tiles with the 255,255,231 background color). Or maybe even use 255,255,231 + transparency>87,5% = empty ...
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on March 08, 2016, 05:59:07 PM
I'd think these are two very different functionalities for different usage.

Darken, even if it's just black, is very useful for shadows (replacement for the ugly dithered shadows)
Since they would be part of the graphic rather than created by the game like the plane shadow, I don't think they would cause any trouble in the drawing orders. If restricted to black, it would only take 3 special colors, possibly shades of gray close to the given percentages.
The way how to scale that in the game seems pretty clear to me. As far as I can see, special colors have the top priority, after that it's normal colors, darkest first. Lowest priority for transparency. Applying the same with inclusion of Darkened area. they would have lower priority than any color, most opaque first. Which means within those darken colors, 75%black would have highest priority, and 25%white the lowest. (Though white would not have any visual effect at all)
To create an antialiasing effect, darken is not too useful though - It works if the graphic you are using is dark already, or if the background behind it is very bright, but that's somewhat unreliable. You really need a blending effect to do that, even if that is more work and not good for performance.

Therefore I think it would be best to have both, possibly starting with black shadows since that's easier, but not under the pretext it could be used for anti-aliasing in trees.
I guess the real issue with blending is that it would be rather silly to use it for antialiasing if you are just going to zoom in and out the same way as you always did without implementing a similar blending for that. At least that would be my concern, just like the current dither-shadow gets really ugly really fast in anything but 100%Zoom, any zooming implementation for transparent blend pixels that follows the current logic is bound to be troublesome.


That being said, just as a disclaimer: Pak192.comic has black outlines anyway, any antialiasing we could possibly do is with black, where blending and darkening is the same thing. Therefore I might be biased since blending would just be used for semitransparent materials, like a glass roof over a station, but surely not for trees.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: NNW on March 09, 2016, 06:58:41 AM
Ok, that seems to be a lot more complex that i has thought. To bad, i cant use the pretty trees in ST, that povray can trace...
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 10, 2016, 08:58:59 PM
The three different resizing would mean a different treatment of special colors on whther they are transparent or not ... Well thinking.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 13, 2016, 12:09:33 PM
Really though any change on this level would probably best be accompanied by a change in image format to support 32bit graphics (24bit+8bit), get it all done in one go. You could incorporate bits indicating special colours into this (e.g. lowest bit of red indicating light, lowest bit of green indicating primary player colour, lowest bit of blue indicating secondary player colour, if green and blue are both set interpreted as flashing, or maybe grab lowest bits of transparency for same purpose...).

Improving clipping so that multicore display can be used all the time might even improve performance enough to offset most of the hit from transparency. That's all quite a lot of work though and I for one am going to be busy until June at earliest with real life (again, pesky elections and referendums!)
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Ters on March 13, 2016, 12:31:29 PM
I think the best format to support everything would be to split the special colors into a separate layer. That was what I did in my OpenGL experiments.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: wlindley on March 17, 2016, 06:35:48 PM
If the color system is to change: Suggest industries have a primary and secondary color (right now they are only assigned a single color) and have some special colors for the gradations of each.  That way, many different industry shops or factory pieces can be coded as a single bitmap, with the flags / signs / awnings changing automatically.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 17, 2016, 07:11:49 PM
I'm trialing alpha images just now...
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 17, 2016, 08:53:13 PM
Ok, I will halt then my exercises into this ...

Just some commend to internal 32 bit: The internal working of Simutrans is not the limit, as there are really many unused special colors (32500 to be exact). So the alpah blending would be not pĆ¼roblem colorwise (and also performancewise, I would say). Doing 32 bit is really a break, as 4x more data has to be moved, which make the difference between 16 and 4 frames per second.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 17, 2016, 11:15:49 PM
Currently I'm just making the alpha come from a separate simutrans image using just the red channel from this (i.e. only 5bits/32 levels of transparency), not touching the 16/32bit issue at present.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 18, 2016, 02:23:44 AM
(http://simutrans-germany.com/files/upload/smokealpha.png)

Very much work in progress (namely that the way climate alpha works is incompatible with other image alpha at present)... Away for weekend but will see what progress can make next week.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on March 18, 2016, 11:52:34 AM
Interesting. What effect on performance does this have?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 18, 2016, 07:39:22 PM
No noticeable effect in limited testing, would need proper benchmarking of a busy section of a map to see. Am experimenting with smoke first, but lots still to do.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 18, 2016, 10:40:24 PM
As said before, one could either use the alpha channel from an image with the closest foreground color to have a blend to that color. We have really enough special colors left to get there without fundamental changes to the engine.

Which graphics are blending in your image? Somewhat it is not so obvious for me.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 18, 2016, 10:47:32 PM
Smoke rising from steam engines is semi transparent - it's a fairly subtle, have tried tweaking it a bit more but something doesn't seem to be working totally correctly. Am just using separate ordinary Simutrans format image to store alpha (in the red channel!). Obviously that still leaves other potential uses for green or blue channels in that image (or not).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on March 19, 2016, 12:57:42 PM
Incidentally, what sort of graphics had you imagined benefiting from this - just smoke and trees or other things, too? There are an awful lot of graphics in Pak128.Britain.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 19, 2016, 09:10:15 PM
For pak128.Britain smoke and some station roofs. Shadows don't exist in pak128.Britain so trees don't really need alpha. Adding shadows would be a major undertaking and I'm not convinced worthwhile as difficult to make them look good against contours.

Other paks may differ.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 20, 2016, 08:52:32 PM
Still work in progress, but solved some of the silly errors....

(http://simutrans-germany.com/files/upload/smokealpha2.png)

Alpha only implemented officially for smoke (but some other skin objects may work). Syntax in dat file is:

Obj=smoke
Name=Steam
Image[0-9]=smoke.0.<$0>
Alpha[0-9]=smokealpha.0.<$0>


Note that alpha must have same pixels filled as image or bad things will happen (crashes!)

Edit - also a lot of this patch is swapping around RED and BLUE alphas in the code as these had been the wrong way round for years......
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 20, 2016, 09:30:53 PM
I still do not like the extra alpha image, as it will be also hard to keep in sync with the original image. Why not use the alpha channel of the original image?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 20, 2016, 09:40:19 PM
Using alpha channel would require more work (this would have to be extracted, then be written as a red channel to a separate image - internally this would be as above, with Image[] and Alpha[] but pak maintainers wouldn't see this).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on March 20, 2016, 09:45:30 PM
It's probably better to have more work for a developer now than more work for all pakset maintainers forever, isn't it?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 20, 2016, 09:47:33 PM
Indeed - this is a work in progress patch one reason why I wanted to get something workable with the simplest objects so can work out how will be implemented more widely.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on March 20, 2016, 10:42:04 PM
Question would be how/whether the other channels (green, blue) could be useful. For example, they might be used at a later point to mark parts of images which are not supposed to darken at night. But if no use, not even a hypothetical later use, could be found, then you would not need it.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 20, 2016, 11:39:09 PM
Yes - other channels could be used to mark player colours or other special colours. So some discussion may be needed as to exactly what image format should be. Of course, just because alpha channel could be read from the main image, wouldn't mean other channels couldn't still be read from another image and then combined. However that would be a bit messy...
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Ters on March 21, 2016, 09:43:32 AM
If rendering where to be done using the GPU, one would have the base day image that darkens with the fading daylight and a night overlay image that is overlaid at constant intensity during night. This means you can have lights in any color desired. However, player colors have so far been neglected.

The simplest way of implementing player colors with GPU in mind, might be to have an image with two channels plus a mask/alpha. One channel would be for intensity of primary player color, and the other would do the same for the secondary color. (0.0 would be black, 0.5 the player color, and 1.0 white.) The mask would say whether there actually is supposed to be a player color at all, which I suspect is faster than doing conditionals on special color values in the pixel/fragment shader.

This might be horribly inefficient to do in software, though.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on March 21, 2016, 09:57:36 AM
How exactly would one make these work with semi-automatically rendered Blender files?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 21, 2016, 05:53:47 PM
I had thought about having played colour as another channel(s). I'm also not sure what should happen regarding PNG alpha and the current pale blue transparency. I think both need to be used, if only to maintain compatibility with existing images.

Regarding semi-automated rendering, that depends what you are talking about. For alpha if read from PNG alpha channel then blender options could be changed to use that. Been ages since I tinkered with those but you'll need to ensure that totally transparent pixels are marked as light blue, with pixels having any hint of alpha not being blended with the background but using their own colour only and alpha. This might involve combining two render images, one to set a mask using current settings, the other to get alpha for each pixel. Or a way of post processing an alpha image to set all totally transparent pixels to light blue.

Player colours would add an additional rendering step to the above with just the player colour(s) rendered, then this copied to the relevant channel.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 21, 2016, 11:38:47 PM
You could still define that any pixel with color 255,255,231 will be transparent, no matter what alpha.
If alpha>12,5% or so, then find the next base color from the color map from the forground pixel and add one of three transparency levels. That would generate 256*4=1024 special colors in the almost empty special color range.

That way you would not need extra images, can do the resizing together and still have color blending.

Blending every tile will cut the framerate to 1/3 or so, so that is probably too much. Also the multithreaded redrawing might create strange artefacts at the seems with too much blending uses.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 21, 2016, 11:54:27 PM
Not sure how that 256*4 special colours works? Yes can have alpha and 255,255,231 but makeobj will have to ensure these remain in sync.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 22, 2016, 09:52:13 PM
I though the following:
makeobj defines image as the area which does not contain 255,255,231 and have a transparency less than 224.
If the transparency level is >0 then the base color will be chose from the player color palette, and the the special color will be 32768+256+256*base_color_index+transparency_level and the latter is transparency/96
That way the images cannot get out of sync and transparency can be added directly from a render.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 25, 2016, 06:55:26 PM
Makeobj can reads alpha from png alpha channel and store this in pak.
Simutrans can display alpha for smoke, fields, trees and buildings (other objects can be added in due course)

There's no changes needed to dat files.

Makeobj had to be a bit more clever about determining what is a valid alpha channel and what isn't though.

I also had to make a bit of a judgement call as to how low in the code alpha display should be implemented. The level I've chosen means objects need to implement routines to return alpha image numbers, which will then be automatically displayed. A lower level would be possible but this would require fairly radical changes to simgraph and the way images are stored...

Please test!
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 25, 2016, 11:52:08 PM
Hmm, I think it will be still easier to integrate the transparency into one image. I will give a patch hopefully tomorrow to compare. Having two bitmaps certainly would save on non-transparent bitmaps

However, I would still have every image possible with transparency and not so much efforts for each object, and it would be just ignored, if not there. I am curious how high the impact on the low level routines would be.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 26, 2016, 12:05:10 AM
We can see... the makeobj part can be reused regardless of implementation in Simutrans. My worry was having to duplicate the rescaling routines which having separate images avoids...
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Yona-TYT on March 26, 2016, 12:06:06 AM
It looks great... big difference.  :thumbsup:
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on March 26, 2016, 03:15:34 PM
May I kindly ask for a compiled windows version for testing purposes?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 26, 2016, 09:37:12 PM
I would wait until the makeobj format is settled. Also the visual result of both implementation would be different.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 26, 2016, 09:59:37 PM
Alternative implementation here at a slightly lower level which means all objects drawn as part of simobj can have alpha...

To do this I added alpha_nr to images which can then be used to call the alpha display routines. alpha_nr is set to IMG_LEER if the image has alpha, or the image is alpha itself....
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 27, 2016, 12:50:57 AM
OK, here is my take. If an image has alpha it will be drawn using the slow routines. Otherwise it will all be the same. I added a tree. Screenshot too, not too spectacular. (THus marked by red lines.)
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 27, 2016, 01:53:28 AM
Hmmmm. I guess question is are we wanting to allow shadows (for which 2 bit transparency is fine) or allow a range of effects. The difference is quite noticeable on the smoke graphics I made:

(http://simutrans-germany.com/files/upload/smokealpha2.png)
Smoke images as displayed with my patch.

(http://simutrans-germany.com/files/upload/smokealpha-prissi.png)
Using same images with prissi's patch.

Incidentally whichever way we implement alpha we should probably commit the code tidying parts of both patches (e.g. moving special colours from tab to bildbesch in prissi's and the long standing incorrect alpha colour channel names fixed in mine).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on March 27, 2016, 09:47:21 AM
Wonderful!  This is very exciting.  I have a bunch of alpha tree images that I can offer for testing purposes, but it will have to wait a few days until I return back to my main computer with all of my Simutrans development projects.  I also have vehicles and buildings available with alphas, if this patch is intended to be able to support those as well.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 27, 2016, 10:26:02 AM
Both patches support alphas for everything in the game play area (mine doesn't for menus, window tool icons etc though, I suspect prissi's does although behaviour might be a little odd if a window background has alpha as objects in the game play area behind large windows might not get updated automatically).

I would caution against putting alpha in images just because you can though. With both patches there is a slowdown on image plotting for alpha images, maybe not that much, but if there's a lot of objects on the screen all with alpha images it could be significant.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on March 27, 2016, 11:43:02 AM
Absolutely.  For those of us with high-end computers, the performance hit may be worth it for the enhanced graphics capabilities.  The only way to know for sure is to test it with various degrees of alpha images enabled (trees, vehicles, buildings, etc).

Given that for my purposes, performance is less important than appearance, I'd be happy to make the trade off.  It'll also make my Blender-->Simutrans transition process faster as I won't have to spend the time carefully selecting an alpha channel threshold level each time I make an import.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on March 27, 2016, 02:42:13 PM
Quote from: prissi on March 26, 2016, 09:37:12 PM
I would wait until the makeobj format is settled. Also the visual result of both implementation would be different.

As I said, testing purposes. This is a patch to enhance visuals, so it seems appropriate that graphic artists play around with it to see how it works, especially with two versions around. While programmers will know best which method is more efficient in which scenarioes, the most efficient method would always be not to have alpha channel. Efficiency can't be the only consideration. So if you are willing to exchange performance for appearence, you need to know which method ultimately looks better and by how much. Additionally, I think working with a restricted "alpha palette" is similar to working with a restricted color palette. You can create graphics for the limited palette that look great, but if you try to downsample from a bigger palette, you might be disappointed. Therefore, prissis patch might bring results just as good as kierongreens if proper alpha is carefully chosen - but harder to do and inconveniant to use. Convenience in use should therefore be another factor, which again is probably best decided by graphic artists who will make use of alphachannels.

It's especially important considering without direct access just from screenshots, many questions remain open. For example, what happens if something transparent is in front of a special color, either nightcolor or player color? Can you have transparent special colors? Can you use 25% transparency in both front- and backimage to get 44% transparency in sum? How does zooming handle transparencies? Are any of these different for the two methods?
Or do you only want feedback from the "general public" once stuff is already accepted and in the nightly? That would seem odd.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 27, 2016, 05:07:52 PM
Regarding limited palette for alpha - yes, this does make life more complicated as to get acceptable results dithering would be needed - with the artist applying this separately for both alpha and colour components. This isn't the easiest things to do and does remind me of displaying images in 256 colour modes back in the mid 1990s...

Unfortunately I'm not in a position to make Windows builds at present as mingw stopped working for me a while back.

A few brief comments on your questions though - each patch keeps most image routines as at present. Hence zooming and overwriting pixels (whether player colour or special day/night etc) on screen already work as expected for both patches. They also work fine with the day/night cycle for normal colours. However prissi's patch supports special colours in images with alphas whereas mine does not (for mine if an image has special colours then alpha doesn't display).

On another note when I compile pak64 with prissi's version this produces an assert error running simutrans in the bild_besch image rotation routines (I'm guessing somewhere an offset has been set which would cause the assert to fail?). Doesn't happen in pak128.Britain though...
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 27, 2016, 08:35:57 PM
I think some of the visual differences between the two patches come from the fact that I use 0 as opaque while you use 255 as opaque, when I read the patch. The display routines in coth cases only support 25/50/75% transparency (or did I get this wrong?)

Also transparent player color were important to me, as one could have a station with window panel on top in player color (although support of that in my patch is still very limited). I also try an approach which will have way less impact on drawing (i.e. still using assembler for most of the draing without adding much new code).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 27, 2016, 08:41:53 PM
My patch supports 32 levels (5 bits of transparency). 5 bit alpha has been in Simutrans for years since climates were introduced because it's used in generating landscape tiles. That's one reason I've used the method I did for general alpha, because these routines are already there.

Yes the alpha gets flipped in your patch but it still works as intended - if you look at the smoke you can see the centre is opaque, the outside semi transparent, which is the same as in mine, it's just the boundary between the two is more obvious in yours because of the 2 bit alpha.

It should be fairly easy to add player colours to my implementation I hope. Certainly people would expect this when alpha is added to trunk.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 27, 2016, 10:42:50 PM
Ups, well 32*256 is also possible. I did overlook that. But supporting this is easy, I just changed colorpixcopy. So also 32 trasnparency levels. I found out that my tree was broken, possibly because my Gimp skills together with the poor GUI.

OK, here is the code which is more flexibel and much faster and supports player colors. It even involves less changing and works now with transparent trees too.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 27, 2016, 10:47:50 PM
I still favour a full range of colours being able to be used but will see what's possible... Incidentally at present my patch should support player colours just not the special night time ones.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 28, 2016, 01:15:00 PM
Ok, version of my patch which supports player and special colours and alphas
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 28, 2016, 07:58:54 PM
Ok, here a small correction of mine, no further changes of function. Codewise, I am of course leaning to mine since it does not need extra support for the objects and uses less data for display; but I am biased.

SO let's summarize the two patches:

both:
full support of special colors and player colors

kierongreen:
+ full 15 bit color support
+ can control which are transparent an which not
- need code for each object to enable transparency
- pak sizes nearly double when using transparency
- slower since more data used to render twice (need profiling to quantify)

prissi:
+ almost any image (not for ground tiles) can use transparent colors
+ no extra efforts codewise on the objects
+ paks size stay the same (also in memory)
+ potentially faster code as only transparent bit are using slow routine (need profiling to quantify)
- transparent base colro is limited to one of the 240 base colors
- color will be one of the 224 indexed colors (the ones the player colors are finally choosen from)

Now the important question: Does the finer control with 15 bit colors instead of choosen 8 bit makes a visual difference (especially since blending means mixing with other colors anyway)?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 28, 2016, 08:50:47 PM
To add - mine now works at low level so any image can have transparency. So really the difference is:

kierongreen:
any 15 bit colour, and special/player/index colours can have colour alpha
larger pak size

prissi:
special/player/index colours only can have alpha
pak size remains same

As you say, profiling could determine which is quicker, I've not noted a slowdown so far with mine even on screens with many objects (smoke), however that might change if people started using also on all object.
indexed colour alpha
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 28, 2016, 10:38:37 PM
Thanks, I overlooked that your last was low level too. So now both would be similar for pak developers. (Honestly, most of the time for this patch  I needed to get the transparency right in Gimp ... )

As currently pak size is not the limit (although some paks nearing 1 GB for graphics alone) the question is really, does 15 bit gives a visual difference than 8 bit base color and how much impact on the drawing. I think we need some screenshots on smoke and more profiling with trees (and maybe more than one too).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 28, 2016, 10:50:04 PM
Indeed - I suspect for pak64 it wouldn't make too much of a difference with colours but for rendered paks it would be more noticeable.

It really depends what pak authors try to do with this. For shadows and transparent roofs (or even the greyscale smoke) the palette should cope fine. However having a full range of colours allows anti-aliasing around image edges which would look odd with a restricted number of colours. That said, adding alpha to that many images could well slow the game down too much in any case...
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 29, 2016, 08:44:28 AM
I think it may be best to combine the best of both and possibly extend the image system a litte further.

Now we have (in my patch)

(transparent pixels) (either normal pixels or with highest bit set pixel to color transform and transparency) (either zero for end of line or repeat)

maybe we should get introduce two flags

$8xxx for all following pixel transparent followed by alpha (new color alpha new color alpha) with actual length = runlen*2
$4xxx repeat this following color runlen times with actual length = 2
$Cxxx repeat following transparent color with actual length = 4

The values $8000, $4000, $C000 would be then a zero length transparent run, just to switch to transparency (for example).

This might save also a lot of memory on larger comic paks as well (and also for player colored stuff in pak64 and others).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Dwachs on March 29, 2016, 02:08:22 PM
I like kierongreen's approach more as it uses the existing routines and is not bound to special colors. Performance should not be a problem if the screen is not completely filled with transparent objects. One could also disable it on max zoom out.

Kieron, what happens if the png-images of the object and the alpha-map do not match perfectly? Is the run-length encoding taken from the object image anyway?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 29, 2016, 09:28:23 PM
Dwachs - RLE is shared between alpha and colour images yes. Code writing images enforces this and it is assumed when reading.

It's worth noting that my patch does leave 10bits per pixel unused currently. This may be seen either as a drawback or potential for future uses (e.g. player colour aliasing)
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 29, 2016, 11:04:59 PM
Ok, a proof of concept to have both 15 bit colors with 32 levels of transparency without wasting much space as indicated above. (One could still discuss on how to store them in memory). The zooming is not finished, because I am not sure to continue with it. It would certainly enforce 100% sync, since any transparent pixel cannot be opaque at the same time.

This is still a hack, as there is no compression of identical pixels yet (i.e. a true RLE) and no good zooming, since I am not sure if I should continue.

Thus, seeing how difficult it was to get the desired transparency for a simple tree into GIMP, I highly doubt that there will be many transparency images coming up soon which are not shadow or smoke, and hence blending with one of the 224 nearest colors may do the trick quite well. Moreover, due to the preferred fast calculation (maybe there should be a setting for makeobj to allow on demand only 25/50/75% transparency), there are only 3 bit red and blue and 3 bits green used anyway, thus in total 512 colors. The difference to 224 base colors (about 7.5 bit) is then a 3/4 bit per color and seems minor to me given the double memory footprint and computation effort.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 29, 2016, 11:19:41 PM
3d rendered images have alpha channels available for no additional cost to the artist (or indeed, as pointed out in some cases a saving). Hence why I said that pak64 might not be representative of other paks in terms of colour usage.

In terms of the wasted space - in pak128 images are around 4KBytes each compressed. We've only just gone beyond the 65k image limit, so even if every single pak has an alpha channel added that would add approximately 250MByte of disc space and memory usage.

Regarding speed of calculation I'm not sure - have we done profiling here? The 32 level alpha is fairly efficient - a separate multiply of red/blue, and green components followed by a bit shift divide of each and writing the combined value (at least in my patch).

Edit:
Had a quick look through that latest patch - that's a lot of work you've put into changing routines in simgraph. With the amount of extra code in there what's the performance hit (I note you haven't done the red/blue, green optimisations yet or would the compiler do this?).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Ves on March 29, 2016, 11:27:51 PM
Will an object (say a vehicle or a three) automatically blend to the ground/to other objects, or does one have to manually add the blending to the edges of every object graphic? Would there be a possibility/desire to blend objects automatically?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 29, 2016, 11:45:14 PM
Blending objects is something that has to be done by the artist. Also it may not look great in Simutrans, rather unsharp (but that depends on pixel size and object).

For pak64 the memory impact is indeed neglible (although true RLE might even speed up drawing). But the last time I checked pak128 it was 402 MB on my harddisk, pak128.britain 229 MB, pak128.german (which is most likely to received many alphas soon) 161 MB, and pak129.comic 109 MB. Most of this space (about three quarter) is from the images. Ok, some of them are merged on load.

Also only about half of them could get transparency (trees, factories, smoke, buildings with shadows), although vehicles with shadows seems unlikely soon (as they will clash badly with the non-shadowed ones).

Adding 250 MB of main memory has some impact, especially for small VPS networking servers and smartphones and tablets and the likes where we slowly work to support them too. But then I may be too old fashioned ...

Profiling has not been done yet, sorry.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 30, 2016, 01:19:14 AM
Regarding memory consumption when simutrans is running - it would be trivial in my patch (a couple of lines in image_reader.cc and a setting in simuconf or similar) to add a reduced graphics quality setting for lower specification hardware which ignored and did not load the alpha image. You'd still have the graphics stored on disc but storage really is practically meaningless these days (even for older hardware running simutrans an extra 100mb disc space is insignificant).

Regarding adding alphas Ves, as prissi points out this will need to be done manually. Alpha could be used to give soft shadows, smooth image borders and more realistic glass, smoke and fire but this would require significant work from artists (they do like a challenge though!). The point prissi makes about unsharp is also well made - alpha would not be something to be used everywhere and anywhere just for the sake of it as it could just make everything look blurry.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 30, 2016, 10:47:40 AM
I did some last thing, using 3 4 3 for encoding of the base color (31 transparency levels and 1024 colros just was enough space). That shoudl give in the end the same appearance. But tonight I will try to get some useful profiling out of it. I just want to have some more trees and some made transparent.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on March 30, 2016, 11:05:42 AM
I'll be back to my main computer on April 2nd and will upload a bunch of alpha-enabled trees at this time, if that will be useful.  I'll also upload some buildings and vehicles as well, to round out the testing.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on March 30, 2016, 01:47:05 PM
That would be most helpful. Manually giving trees shadow is very painful.

EDIT: It is really hard to make shadows using this feature, because at the border of a shadow the transparent color is already different, but the transparency is just below the first level. So every shadow has a blueish halo. It may work better, when there is no background at all, i.e. alllayer but the trees are transparent.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on March 31, 2016, 06:31:01 PM
Indeed - best starting off now rendering with no background colour, with the blue added back in later to any completely transparent pixels.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on April 02, 2016, 12:13:29 PM
As promised, here are some trees with alpha enabled.  I have included the same tree in pak64 format with and without shadows for comparison purposes.

Having shadows that taper to the edges should produce a better effect with the alpha channel.

I wasn't able to test them so I can't be sure that they are in the right format or don't have some other issue with the images that I didn't notice.

I'll produce more images as I have available time.  The shadows took a bit of work as I had to cast them in Blender on a white surface and then remove the surface after to just pick up the alpha values.  There might be an easier way, I'll have to investigate.

(http://www.ssgholdings.ca/simutrans/images/pak64_cedar_tree.png)(http://www.ssgholdings.ca/simutrans/images/pak64_cedar_tree_shadow.png)
(http://www.ssgholdings.ca/simutrans/images/pak64_alder_tree.png)(http://www.ssgholdings.ca/simutrans/images/pak64_alder_tree_shadow.png)
(http://www.ssgholdings.ca/simutrans/images/pak64_birch_tree.png)(http://www.ssgholdings.ca/simutrans/images/pak64_birch_tree_shadow.png)

Combined in to one image:

(http://www.ssgholdings.ca/simutrans/images/pak64_trees_alpha.png)
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 02, 2016, 10:27:35 PM
Unfourtunately this is completely wrong. ONLY the shadow must be transparent, the tree must be solid (or it looks really wierd. Here is the correct shadow.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 03, 2016, 07:37:19 AM
Trees can have some transparency, as you can see between the leaves and branches, but the fading to black doesn't look quite right.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on April 03, 2016, 08:18:46 AM
I made a mockup with Sarlocks trees by just placing them in a screenshot in photoshop. This is "normal blend", and as an artist this is what I would expect Simutrans to produce as well. This is somewhat important since testing via paking and starting new games takes way longer, you don't want to do that for every pixel.

What I see in the mockup is fine. The trees would not mix well with existing ones, but that's intentional. Their relation to old trees is pretty much the same as that of old trees to comic trees, and everyone has his own preferences.

So what does it look like when using the patch? Since 'mere mortals' can't test it on their own, wouldn't it be a good idea to at least show a screenshot of how it looks instead of just claiming it's wrong and looks weird? That way, everyone can see and state whether it looks weird to them, and compare it to the mockup to see how well Simutrans implements transparency...
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on April 03, 2016, 12:45:19 PM
That looks very good.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on April 03, 2016, 01:35:40 PM
(http://www.ssgholdings.ca/simutrans/images/alpha-tree-sample.png)

Maybe I've misunderstood what this patch was intended to accomplish, or is capable of, but alpha on trees makes a massive difference in their appearance in game.  The vast majority of a tree is partially transparent.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 03, 2016, 08:36:56 PM
It looks more or less like on your screenshot, which is not how trees look in real life to me (they are not that transparent, especially not the trunk ... ) This is most notable to me in forests, onsnow and close to a straight wall like the factory. But I admid that this is might be also a matter of taste.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on April 03, 2016, 09:45:30 PM
Obviously trees are not transparent, but they are not confined to pixels either.

I attached an image of a tree trunk with a grid. Assuming you tried to convert the tree to a very small image a tenth the size, each pixel would be as big as a square on the grid. If you look on the left tree, its trunk would be two solid pixels wide. The right, identical trunk is alignes slightly different, so it would be a column of solid pixels accompanied by a column of 50% transparent pixels to either side.
If the trunk was thinner, you may have no solid pixels anymore, just like the ones sarlock rendered. I'd try to avoid such situations, and have at least one trunk pixel completely solid, but I do pixelart where sarlock renders, so these are different philosophies from the start.


Nevertheless, I think a big part of the problem is that it indeed does not look that good in the game. I made another mockup by simply replacing the previous screenshot. In the mockup, the trees are better visible than in the game screen. Therefore, we have a discrepancy that needs to be explained. Maybe transparency is "rounded down" when it is a not supported transparency level? If something like this reduces visibility, it should be easy to fight simply by duplicating the trees in photoshop (or similar software) and put the copy on top of the original, thus reducing the degree of transparency.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 04, 2016, 12:19:00 PM
Comparison between patches:

(http://simutrans-germany.com/files/upload/tree-screenshot-prissi.png)

Prissi's patch

(http://simutrans-germany.com/files/upload/tree-screenshot-kg.png)

My patch. There are a few artifacts around the edges which I'm investigating the cause of, however in general I think this achieves the artists intent better than prissi's.

I would note that there appears to be a bug in prissi's patch which prevents the complete compilation of pak64 with it. I have to use the standard pak64 with only the tree paks overwritten, as pak64 textures don't compile correctly and cause Simutrans to crash on startup. This doesn't happen with pak128.Britain.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on April 04, 2016, 01:37:53 PM
That second shot looks very nice!  The first one is odd: if you look at the trunk of the cedar tree, it completely disappears.  Parts of the trunk are at 240-255 alpha.  It almost looks as if the alpha is inverted (edges of the tree are darkest and the middle with the highest alpha is almost transparent).

The artists can always tweak the alpha to suit individual tastes.  The trees that I am using for these renders were built to have the alpha channel stripped out... I would slightly change the construction of the tree for an alpha-enabled image so that the middle part of the tree is closer to 0% transparency in many spots.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 04, 2016, 03:23:52 PM
(http://simutrans-germany.com/files/upload/tree-screenshot-kg2.png)

Fixed issues with my patch (attached, now code changes pixels which are fully transparent alpha to be the simutrans transparent blue when writing the image) and new screenshot of the same trees scene above.

Regarding inverting, for some reason prissi included code to deliberately to this in his patch....

Edit - I tried removing the inverting code from prissi's patch but that didn't fix problem (made it much worse infact!)
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on April 04, 2016, 05:45:53 PM
Wow, that looks great!  I'll try to set aside some time and make some more tree renders for testing.  I'll make some in pak 128 format as well.

This is very exciting... it opens up so many possibilities!
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 04, 2016, 09:45:02 PM
pak128 ones, especially ones suitable for pak128.Britain would be welcome :) There going to be different seasons too? Having leaves gradually fall as autumn deepens should be quite pretty with alpha.

Will need to think whether shadows should be added to pak128.Britain with this - one reason I didn't include them from the start was that they didn't look great without alpha (though fixed shadows can still look odd in some situations, and it's a fair bit of work so will see).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 04, 2016, 11:39:30 PM
There seems then something very wrong with Irfanview and gimp, because both interpret alpha 255 as fully opaque. Anyway, I corrected my patch.

The textureslope you provided for pka64 is an 8 bit indexed image with alpha ... Hence the crash as parts of its will be now considerated transparent and thus can no longer rotate. Here a new makeobj that will strip the transparency from paletted images and invert the alpha as intended.

(I was confused an though the Halo pixel was my error and thus inverted the alpha. However, I still get the Halo with the trees; only when I really reduce the first transparency to be more than 32 or so this will vanish.)
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 05, 2016, 12:26:21 AM
OK - can confirm that crash issue is fixed.

Same scene for comparison with latest version of prissi's patch:

(http://simutrans-germany.com/files/upload/tree-screenshot-prissi2.png)

There are a few artifacts visible around trees, and a zooming comparison reveals differences between patches::
(http://simutrans-germany.com/files/upload/patch-comparison.png)
(my patch on left, prissi's on right)

Currently as I see it between the patches we have:
my patch - better alpha and colour reproduction
prissi's - smaller pak file

Performance between the two is unknown yet, but as I said above it would be trivial to add an option to disable alpha with my patch which would allow users finding the slowdown a problem to solve this at the expense of graphics quality. From what I've seen of prissi's it would probably be more complicated to do this (but then if prissi's doesn't slow down plotting this is a moot point, can only say that from what I've seen neither slows plotting down drastically in tests so far).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Dwachs on April 05, 2016, 06:38:08 AM
Indeed, kierongreen's patch version looks much better. I would also not worry too much about performance. The usage of alpha transparency could be toggled off if performance is too bad, like this is done for the clipping drawing method.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 05, 2016, 07:14:41 AM
Incidentally I think for prissi's patch one possible reason for drop in quality (other than restricted palette) is zoom routines not dealing with alpha. With mine it gets dealt with like any other colour channel.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Isaac Eiland-Hall on April 05, 2016, 07:37:52 AM
Sorry to be offtopic, but I'll be very brief: I just wanted to thank you all for the hard work on this. I think whatever we end up with will just be a small but amazing little addition to Simutrans. I love watching the discussion and seeing this come together. .....oops, I was gonna be brief. OKBYE :)
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 05, 2016, 09:10:15 AM
In the current incarnation there should almost no visible difference between the patches in standard zoom (but for errors ... ) since for most transparency levels the additional information in kierongreens patch is lost when blending. But the zoom routines handle alpha like a special color, i.e. alpha pixel gets extended rather than be omissed (as could happen with kierongreens patch. Indeed, changing that would be trivial. I still have to convers more trees to alpha (since otherwise they will be removed upon loading) and some smoke and stations and then will try my standard profiling game.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on April 05, 2016, 02:27:37 PM
Give these two a try:

(http://www.ssgholdings.ca/simutrans/images/pak128_douglas_fir_with_alpha.png)

(http://www.ssgholdings.ca/simutrans/images/pak128_hemlock_with_alpha.png)

I agree about the shadows: I didn't use shadows for my own personal pak128 trees as I didn't like how they looked with the alternating pixel setup.  Using shadows with the alpha transparency, however, looks quite nice.

I made these without shadows so that you could compare them against the current pak128.Britain trees.  The first tree is more sparse and has more transparency in between the branches while the second is more solid in the centre.  This gives a chance to compare the two styles.

It's important to keep in mind that artists will adapt their style to whatever end product this patch creates: through a process of trial and error we will find what does and doesn't "look nice" and develop a style that works.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on April 05, 2016, 04:18:56 PM
I'd like to know more about the interaction with special colors. For that matter, I created some "test images" - kierongreen, would you please test them?

first tests the interaction of transparent pixels with player color. If it works as intended, you should be able to choose the colors of the mona lisa portrait by changing the player color settings.
second tests the interaction of transparent pixels with light. I used the same mona lisa, but a bit darker. I'm interested in how that looks at night.
third tests the interaction of transparent light pixels with other light. If it works as intended, there should be some orange lights mixed in the flames.
fourth two test the interaction of transparent light pixels with normal stuff. I made a blue one after I realized that green might not be too visible.

I have no idea if any of these would work, since they are a bit beyond tree shadows - but it's all about finding the limits :D

(https://dl.dropboxusercontent.com/s/jtj5d570e7374ey/transtest.png)
obj=building
name=monalisaplayer
needs_ground=1
type=cur
BackImage[0][0][0][0][0][0]=./images/transtest.0.0
FrontImage[0][0][0][0][0][0]=./images/transtest.1.0
---
obj=building
name=monalisalight
needs_ground=1
type=cur
BackImage[0][0][0][0][0][0]=./images/transtest.0.1
FrontImage[0][0][0][0][0][0]=./images/transtest.1.1
---
obj=building
name=fire
needs_ground=1
type=cur
BackImage[0][0][0][0][0][0]=./images/transtest.0.2
BackImage[0][0][0][0][1][0]=./images/transtest.0.3
BackImage[0][0][0][0][2][0]=./images/transtest.0.4
FrontImage[0][0][0][0][0][0]=./images/transtest.1.2
FrontImage[0][0][0][0][1][0]=./images/transtest.1.3
FrontImage[0][0][0][0][2][0]=./images/transtest.1.4
---
obj=building
name=spotlight green
needs_ground=1
type=cur
BackImage[0][0][0][0][0][0]=./images/transtest.0.5
---
obj=building
name=spotlight blue
needs_ground=1
type=cur
BackImage[0][0][0][0][0][0]=./images/transtest.1.5
---
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 05, 2016, 07:26:53 PM
QuoteI'd like to know more about the interaction with special colors. For that matter, I created some "test images" - kierongreen, would you please test them?

(http://simutrans-germany.com/files/upload/leartin-kg-alpha.png)
My patch

(http://simutrans-germany.com/files/upload/leartin-prissi-alpha.png)
prissi's patch

Incidentally you've managed to find some bugs with the recoding in my patch with those images - after player colour change it takes a while (and zooming in/out) for the image to change... Will investigate.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on April 05, 2016, 09:08:16 PM
 :o honestly, I did not even expect it to work that well. It's beautiful <3
By combining frontimage and backimage, you can mix playercolours with black and white to gain a substantial amount of shades. You can also mix lightcolors to create new lightcolors - not the full spectrum, even if you had RGBCMY the saturation would be somewhat limited, but still a huge step up from 10 colors.

I frankly love it! 10/10 would paint smurfa lisa again!
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 05, 2016, 09:51:01 PM
OK, there were some bugs with high transparency (those discolored stray pixels) and zooming of player colors in mine. Here is hopefully something without these issues anymore and some more test objects. (I think a transparent dialogue skin was also tried by dithering some time ago and might be another good test object.)

And unfourtunately smoke does not support front and back_images ...
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on April 06, 2016, 08:00:45 AM
Quote from: prissi on April 05, 2016, 09:51:01 PM
unfourtunately smoke does not support front and back_images
The original intention of frontimages, seperating "in the back of vehicles" and "in the front of vehicles" only made sense for a few types of objects - ways, stations, depots.
In pak192.comic, we frequently use the frontimage differently - usually for animation, since if something is only changing position you can do that with offset, saving frames. Plus, moving parts are usually unaffected by seasons, so you can reuse the same animation frames over different static seasoned images, saving images in memory. Now they became even more useful with transparency blending.

So could we have an optional "Image2" that is always drawn right after and on top of the normal image (as opposed to back- and frontimage where something else can be inbetween) to gain access to all the benefits frontimage provide? I don't exactly see how it would be useful for smoke (yet), but I think it would be very beneficial. Especially that trick for all shades of player colors.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 06, 2016, 09:59:00 AM
Adding a second image is technically possible for sure but will slow things down, doubly so since alpha plotting will be used. Given the limited circumstances it would be used in I feel it probably wouldn't be worth adding.

Incidentally it seems like a multithreading race condition in activating special colours during image recoding is causing errors with my patch. That might be quite difficult to solve without having separate colour maps for each player, which could be a good thing anyway. However if prissi is going to be committing his patch it's not worth me investing any more time in mine, so I'll leave this for now.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 06, 2016, 09:24:00 PM
The profiling will be done with single threaded mostly, as multithreaded has been given unreliable results before. Although I am not sure how to make sure that then partial clipping (_pc) routines get their fair share then.

About the second image: Front image animation is the recommended way for most animations an certainly nothing specific to pak192.comic. However, an overlay for everything somewhat defies the meaning of overlay. Then a true 32 bit image would have the same memory consumption and drawing bandwidth without all the limitations and gains we have currently from using 16 bits.



Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on April 07, 2016, 09:38:24 AM
Quote from: prissi on April 06, 2016, 09:24:00 PM
an overlay for everything somewhat defies the meaning of overlay.
Then a true 32 bit image would have the same memory consumption and drawing bandwidth without all the limitations and gains we have currently from using 16 bits.

Buildings already can have frontimages. Is the frontimage potential in buildings affecting performance in a significant way? I don't think so, since if that was the case, it would have been restricted to depots and stations. There hardly are animations in most paksets, and where they are they could be done by animating the backimage, so you would not lose any functionality.
Would adding the same potential to vehicles do significant harm? I really don't think so, cause that would not even double the potential frontimages on the screen - except when your screen shows an armada of boats at sea. Conclusion: Potential does not do the harm.

Used Potential can do harm. If we were to use some transparent playercolor overlay on each vehicle, that's probably a significant performance hit old PCs can't take. Of course, the same is true if it was used on other structures that already have the potential - let's put animated disco lasers on every roof! ... Actually, I startet adding animated smoke to each snowy house with chimney. Would probably look better if it was transparent, too. So yeah, of course, if you give me new toys tools to play work with, I'll do my best to destroy that old win95 PC on grandpas attic. Good thing there are more reasonable paks like p64 you can still play on that machine.  ;)

The difference between "changing to 32bit images" and "adding frontimages to more objects" is therefore that:
one certainly hits performance and makes the game unplayable on old systems without any initial gain,
but a potential of nicer colors (possibly not even visible difference for common user),
one hardly hits performance and does not make the game unplayable on old systems while still having no initial gain,
but a potential of adding more player colors and more lightcolors for a performance hit each time it's used.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 07, 2016, 10:01:24 AM
The difference is that front images are there for a specific reason: to be plotted over any vehicles on a tile. Having an additional image would only be there for the purposes of transparent overlays (and logically you would need second images for front images also, so up to 4 images per tile).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on April 07, 2016, 11:36:28 AM
Quote from: kierongreen on April 07, 2016, 10:01:24 AM
The difference is that front images are there for a specific reason: to be plotted over any vehicles on a tile. Having an additional image would only be there for the purposes of transparent overlays (and logically you would need second images for front images also, so up to 4 images per tile).

Hold on: Whoever implemented frontimages could have restricted them to stations and depots, like the ability to be placed on a way. This was not done. In any building but station/depot, frontimages are only there for the purpose of non-transparent overlays. Either even that's enough for them to be useful, or they simply don't do anything bad - including dropping performance.

Sure, the only purpose for an additional image in a vehicle would be that of a transparent overlay. Or a non-transparent overlay even. I once had an end wagon which was the same as the leading wagon, but turned and with red lights. Typical case where I would use frontimage if it was a building, not a complete copy. - not requiring transparency.
But yes, the main part would be to add additional lightcolors and additional player color shades to the mix. What's easier, implementing an "overlay" image for vehicles and possibly groundobjects, signals, ... or actually allowing many more lightcolors and playercolorshades?

And no - having "Image2" does not mean you need to have "Backimage2" and "Frontimage2". Just like having frontimage and backimage in some objects does not mean they need to be in all.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 07, 2016, 11:41:02 AM
Stations and depots are buildings internally though. Hence adding for one you might as well add for all. I wasn't stating that every pakfile would have to have 4 images but that this would be expected to be supported by the program for consistency.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 07, 2016, 09:48:17 PM
Animation would hit performance, if done on enough buildings. Same for transparency or anything else.

The profiling has yield some strange results. The biggest consumer in my patch (22%) was
display_img_stretch_blend
display_blend_wh_rgb
although I do not call this in my patch at all. I think there are some issues with my mingw.
display_img_xx (which had been at 5-10% in old profiling ages ago) was not in the list at all.
Maybe I need to install Linux again for a proper profiling.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 13, 2016, 10:11:26 PM
OK finally got some profiling:

prissi V7 twice as much time than baseline, same pak size.
kierongreen V4 triple time need for display, twice pak size

Without transparency neither mine nor kierongreen is slower.

Three or 31 level of transparency do not have an impact.

In detail

prissi V7

  %   cumulative   self              self     total           
time   seconds   seconds    calls   s/call   s/call  name   
48.51     27.47    27.47                             colorpixcopy(unsigned short*, unsigned short const*, unsigned short const*)
24.04     41.09    13.62                             display_img_nc(short, short, short, unsigned short const*)
  3.98     43.34     2.25                             pixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  2.03     44.49     1.15                             display_img_wc(short, short, short, unsigned short const*)
  1.80     45.51     1.02  8496986     0.00     0.00  display_img_aux(unsigned int, short, short, signed char, int, int)
  1.21     46.20     0.69    12930     0.00     0.00  karte_t::sync_list_t::sync_step(unsigned int)
  0.74     46.62     0.42     4310     0.00     0.00  karte_ansicht_t::display_region(koord, koord, short, short, bool)
  0.65     46.98     0.37    90815     0.00     0.00  haus_tile_besch_t::get_besch() const
  0.60     47.33     0.34  5508308     0.00     0.00  obj_t::display(int, int) const
  0.53     47.62     0.30  2271370     0.00     0.00  objlist_t::display_obj_bg(short, short, unsigned char) const
  0.53     47.92     0.30                             void display_img_pc<(pixcopy_routines)0>(short, short, short, unsigned short const*)
  0.44     48.17     0.25  8901805     0.00     0.00  clip_line_t::inc_y(xrange&, int&, int&) const
  0.41     48.41     0.23    70777     0.00     0.00  haus_besch_t::get_animation_time() const
  0.41     48.63     0.23                             display_fb_internal(short, short, short, short, unsigned short, bool, short, short, short, short)
  0.39     48.85     0.22 12743014     0.00     0.00  karte_t::is_within_limits(short, short) const
  0.39     49.08     0.22                             create_alpha_tile(bild_besch_t const*, signed char, bild_besch_t const*)
  0.35     49.27     0.20  8296751     0.00     0.00  get_xrange_and_step_y(int&, int&)
  0.34     49.47     0.19    40198     0.00     0.00  display_text_proportional_len_clip_rgb(short, short, char const*, unsigned short, unsigned short, bool, int)
  0.32     49.65     0.18        1     0.18     9.30  karte_t::interactive(unsigned int)
  0.32     49.83     0.18                             BZ2_bzDecompress
  0.30     49.99     0.17 14616543     0.00     0.00  planquadrat_t::get_kartenboden() const
  0.30     50.16     0.17  1874850     0.00     0.00  grund_t::display_boden(short, short, short) const
  0.28     50.33     0.16  1961050     0.00     0.00  grund_t::display_obj_all(short, short, short, bool) const
  0.26     50.48     0.15    64748     0.00     0.00  gebaeude_t::sync_step(unsigned int)
  0.25     50.62     0.14    31838     0.00     0.00  interrupt_check(char const*)
  0.23     50.74     0.13 10549744     0.00     0.00  grund_t::get_hoehe() const
  0.23     50.88     0.13  1961050     0.00     0.00  objlist_t::display_obj_fg(short, short, unsigned char, bool) const
  0.21     50.99     0.12  2754090     0.00     0.00  objlist_t::display_obj_vh(short, short, unsigned char, unsigned char, bool) const
  0.19     51.10     0.11 20881723     0.00     0.00  karte_ptr_t::operator->()
  0.19     51.22     0.11 12001622     0.00     0.00  obj_t::get_flag(obj_t::flag_values) const
  0.19     51.33     0.11  8792400     0.00     0.00  baum_t::get_age() const
  0.19     51.44     0.11    62075     0.00     0.00  karte_t::is_fast_forward() const
  0.19     51.55     0.11                             longest_match
  0.18     51.65     0.10 20278534     0.00     0.00  grund_t::get_flag(grund_t::flag_values) const
  0.18     51.74     0.10 12150910     0.00     0.00  obj_t::is_moving() const
  0.18     51.84     0.10  4396200     0.00     0.00  baum_t::get_outline_image() const
  0.16     51.94     0.09 11538312     0.00     0.00  koord::koord(short, short)
  0.16     52.02     0.09  9012841     0.00     0.00  karte_t::access(int, int) const
  0.16     52.12     0.09  1961050     0.00     0.00  planquadrat_t::display_obj(short, short, short, bool, signed char, signed char) const
  0.16     52.20     0.09    11938     0.00     0.00  win_poll_event(event_t*)
  0.16     52.30     0.09     4310     0.00     0.00  karte_ansicht_t::display(bool)


Kireon V4

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
time   seconds   seconds    calls   s/call   s/call  name   
65.11     48.85    48.85                             pix_alpha_recode_16(unsigned short*, unsigned short const*, unsigned short const*, unsigned int, unsigned short, unsigned short)
11.58     57.55     8.69                             display_img_alpha_wc(short, short, short, unsigned short const*, unsigned short const*, unsigned char, int, void (*)(unsigned short*, unsigned short const*, unsigned short const*, unsigned int, unsigned short, unsigned short))
  4.69     61.06     3.52                             display_img_nc(short, short, short, unsigned short const*)
  1.87     62.47     1.40                             pixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  0.95     63.17     0.71  4499521     0.00     0.00  display_rezoomed_img_alpha(unsigned int, unsigned int, unsigned int, short, short, signed char, unsigned short, int, int)
  0.90     63.85     0.68    12909     0.00     0.00  karte_t::sync_list_t::sync_step(unsigned int)
  0.67     64.35     0.50  8492824     0.00     0.00  display_img_aux(unsigned int, short, short, signed char, int, int)
  0.57     64.78     0.43  5509635     0.00     0.00  obj_t::display(int, int) const
  0.56     65.20     0.42                             colorpixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  0.43     65.52     0.32  8991301     0.00     0.00  clip_line_t::inc_y(xrange&, int&, int&) const
  0.33     65.77     0.25                             void display_img_pc<(pixcopy_routines)0>(short, short, short, unsigned short const*)
  0.32     66.01     0.24     4303     0.00     0.00  karte_ansicht_t::display_region(koord, koord, short, short, bool)
  0.31     66.24     0.23  8367499     0.00     0.00  get_xrange_and_step_y(int&, int&)
  0.31     66.47     0.23    90767     0.00     0.00  haus_tile_besch_t::get_besch() const
  0.31     66.70     0.23    40163     0.00     0.00  display_text_proportional_len_clip_rgb(short, short, char const*, unsigned short, unsigned short, bool, int)
  0.31     66.93     0.23     4303     0.00     0.00  karte_ansicht_t::display(bool)
...


Baseline

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
time   seconds   seconds    calls   s/call   s/call  name   
48.32     17.68    17.68                             display_img_nc(short, short, short, unsigned short const*)
  7.86     20.55     2.88                             pixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  3.18     21.72     1.17  8504237     0.00     0.00  display_img_aux(unsigned int, short, short, signed char, int, int)
  3.03     22.83     1.11                             display_img_wc(short, short, short, unsigned short const*)
  2.61     23.79     0.95    12930     0.00     0.00  karte_t::sync_list_t::sync_step(unsigned int)
  2.09     24.55     0.77                             colorpixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  1.20     24.99     0.44  5510121     0.00     0.00  obj_t::display(int, int) const
  1.12     25.40     0.41                             void display_img_pc<(pixcopy_routines)0>(short, short, short, unsigned short const*)
  1.04     25.78     0.38  8898019     0.00     0.00  clip_line_t::inc_y(xrange&, int&, int&) const
  1.04     26.16     0.38  8290592     0.00     0.00  get_xrange_and_step_y(int&, int&)
  1.01     26.53     0.37    90827     0.00     0.00  haus_tile_besch_t::get_besch() const
  0.89     26.86     0.33    64748     0.00     0.00  gebaeude_t::sync_step(unsigned int)
  0.85     27.16     0.31     4310     0.00     0.00  karte_ansicht_t::display_region(koord, koord, short, short, bool)
  0.82     27.46     0.30    70787     0.00     0.00  haus_besch_t::get_animation_time() const
  0.79     27.75     0.29  2271370     0.00     0.00  objlist_t::display_obj_bg(short, short, unsigned char) const
  0.74     28.02     0.27                             display_fb_internal(short, short, short, short, unsigned short, bool, short, short, short, short)
  0.71     28.29     0.26 12755840     0.00     0.00  karte_t::is_within_limits(short, short) const
  0.68     28.54     0.25                             create_alpha_tile(bild_besch_t const*, signed char, bild_besch_t const*)
  0.60     28.75     0.22        1     0.22    10.37  karte_t::interactive(unsigned int)
  0.57     28.96     0.21  1874850     0.00     0.00  grund_t::display_boden(short, short, short) const
  0.55     29.16     0.20  1961050     0.00     0.00  objlist_t::display_obj_fg(short, short, unsigned char, bool) const
  0.55     29.36     0.20                             BZ2_bzDecompress
  0.52     29.55     0.19 20278534     0.00     0.00  grund_t::get_flag(grund_t::flag_values) const
  0.52     29.75     0.19                             non-virtual thunk to gebaeude_t::sync_step(unsigned int)
  0.46     29.91     0.17    37382     0.00     0.00  display_text_proportional_len_clip_rgb(short, short, char const*, unsigned short, unsigned short, bool, int)
  0.44     30.07     0.16  1961050     0.00     0.00  grund_t::display_obj_all(short, short, short, bool) const
  0.41     30.23     0.15     4310     0.00     0.00  karte_ansicht_t::display(bool)


prissi V7 with non-transparent images from baseline (kieron should have here nearly baseline)

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
time   seconds   seconds    calls   s/call   s/call  name   
48.08     17.66    17.66                             display_img_nc(short, short, short, unsigned short const*)
  7.43     20.39     2.73                             pixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  3.95     21.84     1.45                             display_img_wc(short, short, short, unsigned short const*)
  2.78     22.86     1.02  8506616     0.00     0.00  display_img_aux(unsigned int, short, short, signed char, int, int)
  2.29     23.70     0.84    12939     0.00     0.00  karte_t::sync_list_t::sync_step(unsigned int)
  2.14     24.48     0.79                             colorpixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  1.42     25.00     0.52  5516012     0.00     0.00  obj_t::display(int, int) const
  1.28     25.48     0.47  8945006     0.00     0.00  clip_line_t::inc_y(xrange&, int&, int&) const
  1.20     25.91     0.44    90874     0.00     0.00  haus_tile_besch_t::get_besch() const
  1.20     26.36     0.44     4313     0.00     0.00  karte_ansicht_t::display_region(koord, koord, short, short, bool)
  1.06     26.75     0.39                             void display_img_pc<(pixcopy_routines)0>(short, short, short, unsigned short const*)
  0.79     27.04     0.29  1962415     0.00     0.00  grund_t::display_obj_all(short, short, short, bool) const
  0.79     27.32     0.29        1     0.29    10.71  karte_t::interactive(unsigned int)
  0.74     27.59     0.27  2272951     0.00     0.00  objlist_t::display_obj_bg(short, short, unsigned char) const
  0.68     27.84     0.25                             display_fb_internal(short, short, short, short, unsigned short, bool, short, short, short, short)
  0.65     28.09     0.24  8332987     0.00     0.00  get_xrange_and_step_y(int&, int&)
  0.63     28.32     0.23    70830     0.00     0.00  haus_besch_t::get_animation_time() const
  0.60     28.54     0.22 12757252     0.00     0.00  karte_t::is_within_limits(short, short) const
  0.60     28.75     0.22    40134     0.00     0.00  display_text_proportional_len_clip_rgb(short, short, char const*, unsigned short, unsigned short, bool, int)
  0.60     28.98     0.22                             create_alpha_tile(bild_besch_t const*, signed char, bild_besch_t const*)
  0.57     29.18     0.21 12173572     0.00     0.00  obj_t::is_moving() const
  0.56     29.39     0.20  1876155     0.00     0.00  grund_t::display_boden(short, short, short) const
  0.54     29.59     0.20     4313     0.00     0.00  karte_ansicht_t::display(bool)


And finally prissi7 only using the 25% 50% and 75% transparency (faster) with my patch (does not make much difference!)

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
time   seconds   seconds    calls   s/call   s/call  name   
47.75     24.48    24.48                             colorpixcopy(unsigned short*, unsigned short const*, unsigned short const*)
25.87     37.74    13.27                             display_img_nc(short, short, short, unsigned short const*)
  3.71     39.65     1.90                             pixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  1.84     40.59     0.94                             display_img_wc(short, short, short, unsigned short const*)
  1.66     41.44     0.85  8488408     0.00     0.00  display_img_aux(unsigned int, short, short, signed char, int, int)
  0.78     41.84     0.40  5503238     0.00     0.00  obj_t::display(int, int) const
  0.70     42.20     0.36        1     0.36     7.87  karte_t::interactive(unsigned int)
  0.62     42.52     0.32                             void display_img_pc<(pixcopy_routines)0>(short, short, short, unsigned short const*)
  0.59     42.82     0.30  8293189     0.00     0.00  get_xrange_and_step_y(int&, int&)
  0.59     43.12     0.30  2268735     0.00     0.00  objlist_t::display_obj_bg(short, short, unsigned char) const
  0.55     43.40     0.28    33167     0.00     0.00  interrupt_check(char const*)
  0.52     43.66     0.27   113496     0.00     0.00  log_t::debug(char const*, char const*, ...)
  0.51     43.92     0.26  8899568     0.00     0.00  clip_line_t::inc_y(xrange&, int&, int&) const
  0.47     44.16     0.24                             create_alpha_tile(bild_besch_t const*, signed char, bild_besch_t const*)
  0.43     44.38     0.22     4305     0.00     0.00  karte_ansicht_t::display_region(koord, koord, short, short, bool)
  0.37     44.58     0.19 12137255     0.00     0.00  obj_t::is_moving() const
  0.37     44.77     0.19                             BZ2_bzDecompress
  0.36     44.95     0.18  1958775     0.00     0.00  grund_t::display_obj_all(short, short, short, bool) const
  0.35     45.13     0.18 14600202     0.00     0.00  planquadrat_t::get_kartenboden() const
  0.35     45.31     0.18    63369     0.00     0.00  karte_t::is_fast_forward() const
  0.33     45.48     0.17  9002641     0.00     0.00  karte_t::access(int, int) const
  0.31     45.64     0.16 12729435     0.00     0.00  karte_t::is_within_limits(short, short) const
  0.31     45.80     0.16  1958775     0.00     0.00  objlist_t::display_obj_fg(short, short, unsigned char, bool) const
  0.29     45.95     0.15                             display_fb_internal(short, short, short, short, unsigned short, bool, short, short, short, short)
  0.27     46.09     0.14    12576     0.00     0.00  dr_sleep(unsigned int)
  0.27     46.23     0.14                             longest_match
  0.21     46.34     0.11 20861272     0.00     0.00  karte_ptr_t::operator->()
  0.21     46.45     0.11 10537638     0.00     0.00  grund_t::get_hoehe() const
  0.21     46.56     0.11  4965882     0.00     0.00  local_display_obj_bg(obj_t const*, short, short)
  0.21     46.67     0.11    40171     0.00     0.00  display_text_proportional_len_clip_rgb(short, short, char const*, unsigned short, unsigned short, bool, int)
  0.21     46.78     0.11     4305     0.00     0.00  karte_ansicht_t::display(bool)
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 14, 2016, 10:04:34 AM
Nothing like good scientific evidence to make a decision on! :) In terms of practical usage by pak authors, how many objects were on the screen to get that kind of slowdown?

Attached is patch which simply swaps the red and blue labels around for alpha colour components (which are used for landscape tiles at present). Just checking here before committing that red is always the highest bits in the pixel and blue the lowest? (when I originally wrote the code I assumed it was the other way round but seemingly not...). Also is this order of colour bits true across all platforms (maybe I'm getting slightly paranoid about endianess...)?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Ters on April 14, 2016, 03:00:46 PM
Quote from: kierongreen on April 14, 2016, 10:04:34 AM
Also is this order of colour bits true across all platforms (maybe I'm getting slightly paranoid about endianess...)?

Not even within the same platform, if we count IBM compatible PCs as one or just a handful of platforms.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: An_dz on April 14, 2016, 04:46:28 PM
Quote from: Ters on April 14, 2016, 03:00:46 PM
Quote from: kierongreen on April 14, 2016, 10:04:34 AM
Also is this order of colour bits true across all platforms (maybe I'm getting slightly paranoid about endianess...)?
Not even within the same platform, if we count IBM compatible PCs as one or just a handful of platforms.
Anyway that's the most common I know, probably the reason why it's called RGB and not BGR.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Ters on April 14, 2016, 06:04:16 PM
Quote from: An_dz on April 14, 2016, 04:46:28 PM
Not even within the same platform, if we count IBM compatible PCs as one or just a handful of platforms.

Anyway that's the most common I know, probably the reason why it's called RGB and not BGR.

I think that has to do with color spectrums going from lowest frequency (red) to highest frequency (blue).

Windows actually uses BGR to specify palette colors for device independent bitmaps (which is what BMP files contain), but uses RGB for palette colors on a device and possibly the data in true-color DIBs. Ironically, the BGR data type is called RGBQUAD, so just because it says RGB, doesn't mean that it is.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 14, 2016, 07:47:35 PM
Internally we use R5G6B5. How this is stored, is another matter. Back in climate routines it was the other was round, so it is just a name swap.

There were lots of trees, which is the worst case for my patch (as it has to use the colorpixcopy all the time). Let me try a slightly  different variant for a final run.

Here is the image, every tree with transparent shadow, transparent stations, transparent smoke.

Ok, tried some optimisations, but they were just shuffling time around. So version 7 of my patch is probably as fast as it will get.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 20, 2016, 09:39:17 PM
Ok, did much more profiling and played around with some other stuff. It will not get faster than the most simple implementation (a little depressing that anything like separated lockup table etc. did not work). The attached version might be faster should there be ever a 1 pixel transparent border around any image (I would say one should better avoid this, though).

So I submitted version 7 as I found no errors with recoloring when activating several players at the same time. Shoudl this become an issue the attached patch would require even less recoding by lookup tables.

I will submit the first transparent images to pak64, so you can try those out using the new makeobj (which is too large to attach).

It feels a little unfair to kierongreen to submit my version, since he started all the hard work. I thank here very much for pushing it.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 20, 2016, 10:50:29 PM
Good work - as I said regarding the profiling data, nothing like nice solid evidence to decide which method to use :)
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 20, 2016, 11:25:13 PM
OK, profiling had to be single task, or the profiling crashes. With multithreads I discovered the same player error (probably) as you reported for your patch. Switched to V9 patch, since it had the same speed, but required the correct palette only for the transparent runs.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 21, 2016, 06:55:08 AM
Strange as I didn't notice the error multithreaded with your patch but did with mine....
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 21, 2016, 07:28:07 PM
It showed with player colors and only if there are more than three different player colors draw at about the same time. I tested it with one of the pak64 networkgames and got multicolored stations ...

On a more general note: I am also not sure if darkening of transparent colors is a good idea, since the background darkens too. (The only exception are the light colors of course, since these change appearance and hue.) Especially the transparent station roof get very dark in the night, not looking very much like glass any more.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 22, 2016, 07:17:00 AM
People can use transparent special colours for glass if they want though and it achieves the desired effect. For antialiasing it is critical that transparent colours darken.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on April 22, 2016, 02:30:06 PM
Thank you so much to both of you for programming this!  I am so excited to start testing it...  ;D

If this is in the nightly now, I'll give it a download.  Where can I find the most recently compiled makeobj?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 22, 2016, 09:02:41 PM
Nowhere sorry. I wanted to attach it here, but it is 128 kB.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: DrSuperGood on April 23, 2016, 02:04:58 AM
How is the alpha managing gamma correction? For that matter how is Simutrans handling gamma correction?

Up until now I assumed all simutrans pak64/128 art was in sRGB color space as without transparency (only using simple masking) or blending (nearest pixel zoom) the composition output is correct. However as soon as transparency or blending is performed then the scene has to be transformed into linear RGB color space so that the mathematics involved are efficient and produce the correct output.

For example, say you want something 50% transparent in an alpha blending situation. This corresponds to an alpha value of ~127 assuming an 8 bit alpha but normalized it is a value of 0.5. Since alpha is always linear what this should mean is that 50% of the light for a pixel comes from the transparent foreground and 50% of the light comes from the background. With a bright red opaque background (1.0, 0.0, 0.0) and a bright green 50% transparent foreground (0.0, 1.0, 0.0) the resulting output should be composed of half the intensity of both layers and in this case be a dim yellow (0.5, 0.5, 0.0). However this assumes linear RGB colour space, where halving a channel value halves its brightness, which almost all displays are not. As such the correct output on the user's display for the blend operation should be around (0.73, 0.73, 0.0) as most displays (except Mac) are calibrated roughly around a 2.2 gamma curve (~sRGB). If one does not factor in the gamma correction then the output for the blend operation is incorrect and will appear considerably darker than intended, for example displaying the (0.5, 0.5, 0.0) blend output will show up as a very dark yellow colour.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 23, 2016, 10:27:53 AM
Simutrans just deals with simple rgb value anything else would slow calculations down too much.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: DrSuperGood on April 23, 2016, 01:41:44 PM
QuoteSimutrans just deals with simple rgb value anything else would slow calculations down too much.
So the alpha calculations are wrong then?

There is a reason old game consoles such as the SEGA Genesis and SNES did not support alpha and that is because correct alpha is very difficult to compute in a non-linear colour space (which is almost every display ever made). Such consoles uses non-linear sprites for composition so to compute correct blending was near impossible.

Modern GPUs do all the required gamma correction in hardware completely transparently. Since D3D9 and OpenGL counterpart you can specify "sRGB" textures which when texels are required they will gamma correct into linear colour space. You can also specify sRGB output buffers which will automatically convert the linear RGB results into sRGB. Both are advertised as having no overhead with the hardware required performing the operations at the same cycle/bandwidth cost as if linear RGB textures were used.

Without factoring in gamma correction it is impossible to do correct blending. All the results will suffer colour skew and generally bias too dark.

The reason gamma is still used is because it is the most bandwidth efficient way of representing images for users. Originally it was because of how electron guns in CRTs operated but modern displays operate or can be compensated linear. However the human eye operates with a gamma curve and hence representing colour channel data with a gamma curve allows more perceivable colour depth than would be possible with purely linear colour of the same bit depth. All modern GPU hardware does the appropriate conversions for free so it is considered trivial to use a gamma colour space however this was not always the case and why alpha and bilinear filtering were big things when they were introduced.

This is for existing display technology. HDR displays, which are something new and apparently big this year, likely use a completely different colour space as they have to be able to reproduce considerably more discernible colours than previously possible. Hence HDMI and such have special formats for them.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 23, 2016, 02:35:12 PM
Simutrans uses internally anyway RGB 565, so it is rather two generation away from HDR ...

But because the blended areas feel dark, I am considering to not darken the transparent colors. (Like the transparent trees and houses in the stable, which will not darken during night).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: DrSuperGood on April 23, 2016, 03:33:49 PM
QuoteSimutrans uses internally anyway RGB 565, so it is rather two generation away from HDR ...
However it still has to deal with gamma correction, as that has been around for over 40 years.

If the RGB 565 are in linear colour space then you can gamma correct the output quite efficiently. If the 565 are in sRGB then things are a whole lot more complicated.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 23, 2016, 09:57:20 PM
Quote from: prissi on April 23, 2016, 02:35:12 PM
Simutrans uses internally anyway RGB 565, so it is rather two generation away from HDR ...

But because the blended areas feel dark, I am considering to not darken the transparent colors. (Like the transparent trees and houses in the stable, which will not darken during night).
Please keep behaviour as is, all colours (apart from special colours of course) should darken no matter what transparency is.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: DrSuperGood on April 23, 2016, 10:18:25 PM
QuotePlease keep behaviour as is, all colours (apart from special colours of course) should darken no matter what transparency is.
Except alpha blending does not work like that... Maybe I am misunderstanding what is trying to be achieved here.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 23, 2016, 11:22:20 PM
At night time the base color darkens and the background darkens. Thus it gets even darker than in a just transparent  region. You could see this with the new pak64 stations.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on April 24, 2016, 08:09:03 AM
The previously darkened background should be blended with the darkened colours of the object being painted at night.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 24, 2016, 09:34:09 PM
As I said that is how it is done.

Internal the darkening multiplier is 0.316 for red/blue and 0.475 for green (not sure why the latter). If we have a grey shadow (0.5 0.5 0.5)  with 50% transparency, then the blended color will be 50% of the initial in the bright (1 1 1) to (0.75 0.75 0.75).

In the dark we would have normal white (100 100 100) to (0.32 0.48 0.32).  The grey would become (0.16 0.24 0.16), and blended with 50% we would have (0.24 0.36 0.0.25). That is exactly the outcome as if the original color (0.75 0.75 0.75) would have darkend.

Nevertheless, while mathematically correct it feels too dark. Probably there is rally some alpha magic needed for darkening to simulate a gamma correction.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: DrSuperGood on April 24, 2016, 10:16:56 PM
Quote
Nevertheless, while mathematically correct it feels too dark. Probably there is rally some alpha magic needed for darkening to simulate a gamma correction.
As already stated, the mathematics only work in a linear colour space which is not what practically every display is. Unless there is gamma correction at at-least 2 stages the results will be mathematically wrong. This is why transparency was such an advanced feature added as standard around 2000 to games consoles and graphics.

The linear colour (0.24, 0.36, 0.24) represents the approximate sRGB (what most displays are set to) 8 bit per channel pixel value of (133, 160, 133). This is opposed to (61, 92, 61) which you get without gamma correction.

The correct colour workflow would be to get sRGB source images (which artists create, they are likely most used to creating them in this colour space), convert them to linear RGB at some time (stored as, or just when needed depending on pipeline) for blending, and then convert the blending results back into sRGB for display. All modern GPU hardware can do this at no additional cost since D3D9 and its OpenGL counter part. Modern GPUs have special purpose hardware built just to do this without adding overhead.

The problem is that Simutrans is not hardware accelerated so the sort of mathematics required are quite computationally expensive, hence the need for GPUs in the first place. I am not sure there is a performance shortcut to floating point colour in this situation, hence the reason why most shader pipelines operate almost exclusively with floating point colours.

People might be asking "Why use gamma in the first place?". Although the physical reasons to use it have long since gone (CRTs without correctors), the practical reasons still remain. A gamma curve of 2.2 gives a more linear brightness scale as far as our eyes can see (not physically), and hence uses bandwidth more efficiently.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on April 24, 2016, 11:02:48 PM
The images in Simutrans are made for visual correctness, i.e. in whatever color scheme you one screen was done.

The darkening a night time is done with a exponential, so some kind of gamma in already in place (and a greenisch hue, although for night view I would rather expected a blue one.) And the shadow is now 50% but the shadow is also optimised for visual appearance. So for bright everything is ok.

One could easily also change alpha for the dark state. That way gamma can be simulated.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Vladki on April 25, 2016, 06:51:20 AM
To darkening transparent colors. Wouldn't it be easier to do the transparency blending with daylight colors and then darken the result?

Only some special colors (lights) would need to be blended after darkening the rest.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Ters on April 25, 2016, 03:01:29 PM
Quote from: Vladki on April 25, 2016, 06:51:20 AM
To darkening transparent colors. Wouldn't it be easier to do the transparency blending with daylight colors and then darken the result?

Only some special colors (lights) would need to be blended after darkening the rest.

What if there are multiple blending stages, which can happen when one transparent image is in front of another? If you wait until all that is resolved, and only darken the end result, the distinction between special colors and non-special colors is gone by that point.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on September 14, 2016, 01:34:01 PM
I am looking for the alpha .png and .dat files for Pak128.Britain, and I notice that they have been lost when the forum went wrong. I do not think that these have yet been put into the Github/SVN repository for the Standard version. Would it be possible to re-upload them somewhere so that I can integrate them into the Experimental version?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on September 15, 2016, 07:41:55 AM
Quote from: jamespetts on September 14, 2016, 01:34:01 PM
I am looking for the alpha .png and .dat files for Pak128.Britain, and I notice that they have been lost when the forum went wrong. I do not think that these have yet been put into the Github/SVN repository for the Standard version. Would it be possible to re-upload them somewhere so that I can integrate them into the Experimental version?
Quote from: Sarlock on April 05, 2016, 02:27:37 PM
Give these two a try:

(http://www.ssgholdings.ca/simutrans/images/pak128_douglas_fir_with_alpha.png)

(http://www.ssgholdings.ca/simutrans/images/pak128_hemlock_with_alpha.png)

I agree about the shadows: I didn't use shadows for my own personal pak128 trees as I didn't like how they looked with the alternating pixel setup.  Using shadows with the alpha transparency, however, looks quite nice.

I made these without shadows so that you could compare them against the current pak128.Britain trees.  The first tree is more sparse and has more transparency in between the branches while the second is more solid in the centre.  This gives a chance to compare the two styles.

It's important to keep in mind that artists will adapt their style to whatever end product this patch creates: through a process of trial and error we will find what does and doesn't "look nice" and develop a style that works.

No alterations needed to dats
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on September 15, 2016, 11:26:09 AM
There were no modifications to the existing Pak128.Britain trees, nor snow images for these trees?

What I was really looking for, however, were the .dat and .png files that you attached to this (http://forum.simutrans.com/index.php?topic=15314.msg151169#msg151169) post. Do you still have this? The smoke does look better.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on November 20, 2016, 06:40:06 PM
Apologies for waking this dead topic, and apologies if I am asking a question that has already been answered here; what exactly is the correct way to use alpha in Simutrans?

For Pak128.Britain, files have conventionally been exported from Blender with a black background and no alpha channel. The black background was then replaced with the background blue colour in the GIMP before the images could be used in Simutrans. One problem with this was that Blender would mix the background black with the image itself at the edges, so making the edges of the objects appear excessively dark. There was no way (that I could find) of making Blender export with the Simutrans background blue (and even if it could, it would mix the colours at the edges with this, which would look worse than the black).

Do I understand that this transparency will allow, amongst other things, transparency at the edges of objects (i.e., a semi-transparent transition between object and background)? I can export from Blender with RGBA, giving a fully transparent background. If I then use the flood fill tool to replace this with the Simutrans background colour, a halo of semi-transparent pixels around the main graphic remains.

Will this now produce an image which, when prepared into a Simutrans .pak file, will work properly and where the semi-transparent edges will show as such in-game? (I presume that this was the intention for the trees?) If so, would this be a sensible thing to do for all graphics, or should its use be restricted because of its impact on performance?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on November 20, 2016, 08:02:01 PM
It's really a case of weighing up performance impact vs looks.

Haven't tried exporting from blender directly but worth trying - I think it should work if it produces RGBA PNG
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: DrSuperGood on November 20, 2016, 08:07:29 PM
As far as I am aware the alpha blending implementation is flawed due to a lack of colour space awareness. As such I would refrain from using it for blending edges or other such complex purposes as the results will look wrong. It works for shadows because any form of alpha is better than nothing.

Alpha blend algorithms assume linear colour space, where something twice the value is twice as bright. However the display buffer values assume sRGB (or HDR, it uses the same brightness response curve) values, where something twice the value is approximately 2 to the power of 2.3 times as bright (actual formula is more complicated). Without factoring in this difference in response the alpha blend algorithms will produce visually wrong results. Mostly it will be too dark or with colour skew since eyes operate in a non-linear way where brightness saturates out dark details.

Modern 3D games factor in colour space correction either automatically in the form of sRGB output (most correct) or as part of the HDR lighting shader (sufficient, some times with deliberate errors for effect). In fact, modern graphic hardware can implicitly convert between sRGB response to linear and the inverse without any performance overhead at all, hence why alpha blending and lighting is trivial in modern graphic applications.

Implementing the correction in software will likely cause a huge slowdown as it requires floating point (or at least high precision) operations. Hence why alpha was avoided so much until recently, with some games offering options to turn it off for performance.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on November 20, 2016, 08:37:25 PM
Ahh, yes, I see - using alpha as I suggested above would result in dark halos around objects? Gamma is a tricky subject indeed. Thank you both for your help. For shadows/smoke, the pixels are supposed to be darker in any event, so I don't suppose that it matters much.

On a tangential matter, I wonder whether the blackness issue might be avoided by exporting to alpha anyway and using the flood fill tool with a threshold of greater than 1 to flood fill the near transparent pixels, although I suspect that it might be difficult in some cases to get the right threshold setting.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on November 20, 2016, 09:39:29 PM
If you export with RGBA for the sole purpose of avoiding to define a proper background color: yes, it would work. But better make sure it is really transparent and really not. Any value which is not really transparent will cause the whole image to be blend, which is noticable slower and may not produce the expected results (for a render).

Still, not only shadows (and lights) but also player colors are useful targets for blending.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on December 10, 2016, 06:49:40 PM
Quote from: prissi on November 20, 2016, 09:39:29 PM
If you export with RGBA for the sole purpose of avoiding to define a proper background color: yes, it would work. But better make sure it is really transparent and really not. Any value which is not really transparent will cause the whole image to be blend, which is noticable slower and may not produce the expected results (for a render).

Still, not only shadows (and lights) but also player colors are useful targets for blending.

Has anyone actually tried this in practice and tested the results?

I ask because I have done this for pedestrians. I initially attempted to make pedestrians the usual way for Pak128.Britain, by exporting from Blender with a black background in plain RGB, and then flood filling the special background colour with a tolerance of zero . However, because pedestrians are very small, the anti-aliased blending between their edges and the black background dominated them and they looked very dark.

I then attempted to use a transparent background in Blender and export them with RGBA. The results were much better: the pedestrians have much better edges and look much more natural. Performance does not seem noticeably degraded even with very large numbers of pedestrians, although I have not actually tested the performance.

Looking at the images in the GIMP, what I see is that there is a 1 pixel (approximately) wide halo around the pedestrians of blended pixels. Despite the sub-optimal blending algorithm in the game itself discussed by Dr. Supergood, this is not noticeable in practice, whereas the blending with the black background in the GIMP makes the edges of the images look noticeably wrong.

So far as pedestrians are concerned, therefore, it seems that, from an image quality perspective, using the alpha blending to export images improves the image quality over the conventional method rather than worsens it, and there is no noticeable impact upon performance (at least not with graphics multi-threaded).

One great advantage of this process is that it eliminates the need for all post-processing, which can greatly improve productivity. With the conventional method, I need to export from Blender, move the exported images to a post-processing directory, consolidate them all with ImageMasker, then open each consolidated image in The GIMP and flood fill the background. Sometimes, extra work is needed on an individiaul image, such as where there are pure black pixels representing, for example, windows on the border of the image itself, which need to be re-filled with black pixels manually; other times, there are islands of black where the image has transparent centres, as with semaphore signals or sailing ships. With the new method, all that is needed is to move the images from their output directory to the relevant pakset directory.

Such disadvantages as there are with this method may well end up being outweighed by advantages, therefore. Has anyone actually tested producing vehicles with this system to see whether it is workable? I am planning to rescale all of Pak128.Britain's road vehicles over Christmas, and it would be a great advantage if no post-processing were required afterwards. Smaller vehicles (such as the private cars) are likely to benefit particularly from the better looking borders.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on December 10, 2016, 07:16:00 PM
The code treats fully alpha pixels as though they are special transparent colour no matter what their RGB value is.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on December 10, 2016, 09:55:08 PM
Quote from: kierongreen on December 10, 2016, 07:16:00 PM
The code treats fully alpha pixels as though they are special transparent colour no matter what their RGB value is.

Yes, I had gathered that. What I am interested in is to what extent that a halo of 1-2px wide around an object of partially transparent pixels will really have on performance. As noted, I have not seen any noticeable difference with pedestrians.

May I ask what matters - the total number of semi-transparent pixels on screen at any time, or the number of objects that have at least some semi-transparent pixels in them?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on December 10, 2016, 10:08:40 PM
Both count - routines for plotting semi transparent pixels are slightly slower than standard ones in general and additionally every semi transparent pixel within each image will cause a further slowdown. If you've found that slowdown to be acceptably small then great - and as you say, multithreading may be reducing the impact somewhat (but memory bandwidth may still be a limiting factor)
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on December 10, 2016, 10:37:10 PM
From what I understand, at least on fairly modern architectures, multi-threading is closely linked to memory bandwidth.

Another advantage of the alpha process is that it will make it much easier to explain to new content creators how to produce graphics for the pakset as it cuts out two whole steps.

Edit: Incidentally, I am having a look at the Pak128.Britain trees to see whether I can export them using this new method, as I suspect that it would greatly improve their appearance. However, I cannot find the smaller trees to simulate their various levels of growth. May I ask how this was done, if you remember - was it just a case of scaling the base tree or were there actually different models for younger and older trees? Also, how exactly were the trees made? The models seem so fantastically complex that it seems most improbable that each leaf was modelled individually by hand.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on December 11, 2016, 04:15:32 PM
The alpha blending does not change anything concerning multithreading. So as longs as the rendering is does not cause the framerate to drop, just the CPU load and memorey bandwidth will be higher. (But the latter not much, since I guess most of the stuff on one tile might anyway happen in some of the caches.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Vladki on December 13, 2016, 09:50:15 PM
Quote from: jamespetts on December 10, 2016, 09:55:08 PM
Yes, I had gathered that. What I am interested in is to what extent that a halo of 1-2px wide around an object of partially transparent pixels will really have on performance. As noted, I have not seen any noticeable difference with pedestrians.

But the difference in appearance IS noticeable. It really looks good.  :thumbsup:
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on December 19, 2016, 12:18:05 AM
I am not sure that using an alpha blend for all objects works very well. Take the below example of a 'bus: the band of alpha around the body is such that the wheels are actually a little transparent. This would not, I imagine, look very good compared to more solid wheels, and, moreover, would look inconsistent with other graphics in the pakset.

I suspect that alpha is best left for trees and smoke after all - even the pedestrians I suspect would probably have been fine had they been exported using version 2.65a or earlier of Blender as I have now discovered is necessary to avoid black bands around objects.

Edit: Actually, when I looked at that graphic on the forum, the transparency on the wheels seemed hardly noticeable, so I ran some tests in game. Can anyone spot the difference between the standard and the transparent version?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on December 19, 2016, 08:35:04 AM
Giving this a full test is still on my "to do" list, but I came to the same conclusion, that for most vehicles it didn't seem to make much difference.  For other objects, such as trees, it makes a huge difference in terms of the types of graphics you can make available.

I'm hoping to be able to devote some time to testing this in the coming few weeks, I want to see how it works for catenaries, power lines, stations with glass and certain buildings (particularly to soften the edges of peaks, etc).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Vladki on December 19, 2016, 11:12:01 AM
pak128-sweden-ex has semi-transparent catenary: see the last screenshot here http://forum.simutrans.com/index.php?topic=15743.0

I can see some difference between bus wheels in the above post, but even the "better" ones are quite blurry. Transparency makes the wheels almost unnoticeable. I have not seen them in game though...
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on December 19, 2016, 12:38:10 PM
My thought at present is that, if the difference between graphics that require a fair bit of post-processing work and graphics that require no post-processing work at all is trivial, then it is better to go with the graphics that require no post-processing work because more graphics can be made in the same amount of time.

The complexity is that, whilst transparency will greatly improve tree and smoke graphics (and also the shadows in some depot graphics), using it for, e.g., signals where all the existing graphics have well-defined edges for the posts and rear ladders (with hand-amended transparent cut-outs for the ladders) may end up looking inconsistent with other objects and indistinct.

I am interested in how it looks for power lines and sailing ships, however.

Edit:

There is a further complexity: I have recently discovered that Blender versions of greater than 2.65 simply do not work properly with the traditional method of producing graphics for Pak128.Britain (using a black background and filling with the special colour in the GIMP) because they changed how alpha works: graphics produced with version 2.66 onwards have a black border at the edge of graphics where the black background has been blended with the objects.

Using the transparency method will allow more recent versions of Blender to be used, as well as making graphics production easier; but it has the disadvantage that the graphics will in some respects be inconsistent with those produced using the older method. It is not an easy decision for a pakset maintainer to take.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: wlindley on December 19, 2016, 02:01:15 PM
Could the fuzzy-edge problem be mitigated by having Blender export 2x or 4x size bitmaps, and then simply scaling them down?  Any one-pixel-wide translucent border of an object then would become only 1/2 or 1/4 or less in strength.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on December 19, 2016, 02:02:37 PM
Quote from: wlindley on December 19, 2016, 02:01:15 PM
Could the fuzzy-edge problem be mitigated by having Blender export 2x or 4x size bitmaps, and then simply scaling them down?  Any one-pixel-wide translucent border of an object then would become only 1/2 or 1/4 or less in strength.

That would then eliminate the advantage of not having to do any post-processing.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: kierongreen on December 22, 2016, 10:40:29 AM
Try seeing what this looks like in winter - black tyres against black tarmac and a green bus against grass won't highlight edges as much as on snow.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on December 22, 2016, 12:01:55 PM
Here it is with snow: the green 'bus has the alpha and the red 'bus has no alpha.

Edit: Darkening the material for the tyres helps - see the second image.

Edit 2: Increasing the wheels to their correct size seems to make a substantial difference: see the third image of the AEC Regent STL in the snow.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on December 23, 2016, 05:33:45 PM
What I've been using to date from Blender is a RGBA export using F3.  It outputs the alpha along with the image, then I've been taking it in to GIMP and stripping the alpha channel from the image and adding the transparent background.  With the alpha channel option in Makeobj now, I can directly import in to Makeobj from Blender.  Export from Blender with F3 (which could be automated with your scripts) and then presto - it should work.  Removing the transparency fixing step will be a huge time saver for me (as well as improve the graphics quality significantly).
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on December 23, 2016, 05:55:52 PM
Yes, indeed - this is the intention. This is what I am doing with the 'bus graphics at present.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on December 23, 2016, 06:16:33 PM
I just jumped in to do some testing and I realize that I don't have an up-to-date version of Makeobj.  I had downloaded what I thought was a nightly version some time ago but I see it's still 55.4 and doesn't seem to support the alpha channel in the graphics I provided to it (it just strips them out).

I tried in the past to compile it but ran in to so many difficulties that I abandoned the attempt.

I did a fairly extensive search for it but can only come across the older version that doesn't support alpha.

If someone could kindly point me to where I could find a recent compile for Windows, I would greatly appreciate it and return the favour with a flood of new alpha-enabled graphics.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on December 23, 2016, 06:51:38 PM
I did find when compiling makeobj for Experimental that a newer version of libpng than is provided with Ubuntu is needed to make alpha work, or else the alpha will just be replaced with black. Version 1.5 works, whereas 1.2 does not.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: An_dz on December 24, 2016, 01:07:22 PM
I've compiled my own libpng so it's probably 1.6, do you need it for Windows Sarlock?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on December 24, 2016, 01:19:28 PM
Quote from: Sarlock on December 23, 2016, 06:16:33 PM
If someone could kindly point me to where I could find a recent compile for Windows, I would greatly appreciate it and return the favour with a flood of new alpha-enabled graphics.

I always wonder why makeobj is not released with nightlies, at least if something changed. It's essential to create content, after all. (An_dz, is it possible to automate makeobj releases?)
I'm interested as well, though at this time I can't return the favour in the same way, as I'm occupied with life.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: An_dz on December 24, 2016, 03:00:38 PM
I don't have an 'always on computer' so it would not be reliable.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: prissi on December 24, 2016, 09:53:42 PM
It was not released with the nightlies since the format of things in makeobj (like transparencies, climates, half-height tiles) sometimes changes until it stabilised. Also the version of things released is not know. Generally it was considered bad to have stuff released for a nightly version, as normal people may end up downloading that stuff too.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on December 26, 2016, 01:50:09 AM
For some more examples of how using alpha rendering from Blender with no post-processing works in practice, have a look at this (http://forum.simutrans.com/index.php?topic=16518.0) thread in the Pak128.Britain forum.

For paksets that use 3d rendering to produce graphics, this feature has the potential to transform productivity in the creation of new graphics. In practice, its flaws (incorrect alpha blending and increased computational intensity) seem so far to be minimal in comparison with the improved appearance overall and, more importantly, the much quicker and easier workflow.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on January 04, 2017, 07:00:23 PM
Given the greatly improved quality of the alpha graphics compared to the non-alpha graphics, I wonder whether there is anything to be said for using alpha in the transition between different types of climates? I am sure that alpha would make the following transition look much better, for instance:

Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on January 04, 2017, 07:26:26 PM
That's already there, you use a png where each color channel (R, G, B) is used for a climate. I attached an example file you could use for testing purposes.

Obj=ground
Name=SlopeTrans
Image[0][0]=climatexture.0.0
Image[1][0]=climatexture.0.1
Image[2][0]=climatexture.0.2
Image[3][0]=climatexture.0.3
Image[4][0]=climatexture.1.0
Image[5][0]=climatexture.1.1
Image[6][0]=climatexture.1.2
Image[7][0]=climatexture.1.3
Image[8][0]=climatexture.2.0
Image[9][0]=climatexture.2.1
Image[10][0]=climatexture.2.2
Image[11][0]=climatexture.2.3
Image[12][0]=climatexture.3.0
Image[13][0]=climatexture.3.1
Image[14][0]=climatexture.3.3

Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on January 04, 2017, 07:37:11 PM
Interesting - thank you for that. That seems to be smaller than the one used in Pak128.Britain-Ex; is that for 64 sized paksets? May I also ask whether a shore version exists?

Thank you again.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on January 04, 2017, 07:46:48 PM
Obj=ground
Name=ShoreTrans
Image[0][0]=shore.0.0
Image[1][0]=shore.0.1
Image[2][0]=shore.0.2
Image[3][0]=shore.0.3
Image[4][0]=-
Image[5][0]=-
Image[6][0]=-
Image[7][0]=-
Image[8][0]=-
Image[9][0]=-
Image[10][0]=-
Image[11][0]=shore.1.0


These are the ones used in pak192c, based on pak64 when half heights came out. I'm not sure if you can resize them to another pak size, but it should not be hard to scale the images times two and just try.

EDIT: IIRC, Experimental does not support half heights, thus these probably won't work for you. I think before half heights it was be done quite differently.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Ters on January 04, 2017, 08:53:23 PM
Earlier, it seems only red and blue were used for slopes. Shores has been red, green and blue since 2008. Only the upper row as shown in Leartin's examples existed. Interestingly, pak64 only uses blending between colors for shores (ever since 2008), but not for slopes.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: jamespetts on January 04, 2017, 09:59:04 PM
The easiest way of bringing this to Pak128.Britain, I think, was using The Gimp to blend the two colours together on the transitions. Here is a screenshot of what the same snow/green transition looks like after blending:

Edit: I notice that the Pak128.Britain shore texture seems already to be blended, albeit not as much as this.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: An_dz on January 07, 2017, 02:53:40 PM
Here's makeobj r7988 (http://simutrans-germany.com/files/upload/makeobj.7z) as Leartin and Sarlock asked.
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Sarlock on January 07, 2017, 06:01:38 PM
Thank you, thank you, An_dz!


That transition looks great, James!
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: Leartin on January 11, 2017, 04:16:50 PM
Quote from: kierongreen on December 10, 2016, 07:16:00 PM
The code treats fully alpha pixels as though they are special transparent colour no matter what their RGB value is.

I noticed a little inconsitency: This does not work for indexed graphics. It's not a big deal, but if it would work, one could completely abolish background-blue in the workflow and any future tutorials. Maybe there is a simple way to fix it?
Title: Re: Support for PNG Alphachannel for tree graphics
Post by: An_dz on January 12, 2017, 01:19:50 PM
/* Don't output alpha channel on indexed images (There is a bug in libpng that the first pixel of such a bitmap ihas alpha 0xFFxxxxx */

Seems to be easy, but there's a bug, we should try with the latest version.