News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

Support for PNG Alphachannel for tree graphics

Started by NNW, March 07, 2016, 08:53:06 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

NNW

Support for PNG Alphachannel for trees would be fine, because making "nice looking trees" is atm very hard.

Leartin

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.

Ters

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.

Leartin

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.

Ters

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.

An_dz

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.

prissi

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 ...

Leartin

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.

NNW

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...

prissi

The three different resizing would mean a different treatment of special colors on whther they are transparent or not ... Well thinking.

kierongreen

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!)

Ters

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.

wlindley

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.

kierongreen


prissi

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.

kierongreen

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.

kierongreen



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.

jamespetts

Interesting. What effect on performance does this have?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

kierongreen

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.

prissi

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.

kierongreen

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).

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

kierongreen

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.

kierongreen

Still work in progress, but solved some of the silly errors....



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......

prissi

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?

kierongreen

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).

jamespetts

It's probably better to have more work for a developer now than more work for all pakset maintainers forever, isn't it?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

kierongreen

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.

Leartin

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.

kierongreen

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...

Ters

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.

jamespetts

How exactly would one make these work with semi-automatically rendered Blender files?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

kierongreen

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.

prissi

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.

kierongreen

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.