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.

Ters

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.

An_dz

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.

Ters

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.

prissi

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

prissi

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.

kierongreen

Good work - as I said regarding the profiling data, nothing like nice solid evidence to decide which method to use :)

prissi

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.

kierongreen

Strange as I didn't notice the error multithreaded with your patch but did with mine....

prissi

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.

kierongreen

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.

Sarlock

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?
Current projects: Pak128 Trees, blender graphics

prissi

Nowhere sorry. I wanted to attach it here, but it is 128 kB.

DrSuperGood

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.

kierongreen

Simutrans just deals with simple rgb value anything else would slow calculations down too much.

DrSuperGood

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.

prissi

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

DrSuperGood

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.

kierongreen

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.

DrSuperGood

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.

prissi

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.

kierongreen

The previously darkened background should be blended with the darkened colours of the object being painted at night.

prissi

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.

DrSuperGood

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.

prissi

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.

Vladki

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.

Ters

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.

jamespetts

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

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:





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

jamespetts

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 post. Do you still have this? The smoke does look better.
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.

jamespetts

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

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

DrSuperGood

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

jamespetts

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

prissi

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.

jamespetts

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