Digital colors can be made up of three components: red, green, and blue. Combine these together, and you get final color, eg. yellow is 100% red, 100% green and 0% blue.
The fourth component is, as you mentioned, transparency. Together, these form the tuple RGBA (red, green, blue, alpha) which represent an image.
Now, instead of pixels, think about it ...
This is a fairly common approach to transparency in games that use deferred shading. Proper transparency doesn't work well at all with deferred shading, since only one surface's data (depth, normal vector, color, etc.) can be stored at each pixel, and proper transparency involves multiple surfaces overlapping at a pixel, each requiring independent lighting.
I've talked about this a few times before (see related answers at the bottom) but I'll repeat myself.
As you can imagine, checking every pixel against every other pixel would be very inefficient, even if you limited those pixels to the rectangle range that is actually intersecting. But like you mentioned, your second option also has its share of problems.
There are lots of ways to achieve order-independent transparency.
The first (and I think oldest) type of algorithm is called depth peeling and works by "peeling" one transparency layer per pass (in the most basic version). This Nvidia paper for Dual Depth Peeling shows peeling two layers at the same time.
The second type which I only know as "order-...
This looks like a case of not drawing with a premultiplied alpha texture correctly. Here's a few helpful links on the subject:
If you search for "premultiplied alpha" and iOS you might find a direct solution to your problem. I suspect it ...
Jens covered the different ways pretty well. I would like to add that additive blending is also order independent and it can be used in limited use cases to achieve pretty good results with very little programming effort.
The following image is rendered with a color something like (-0.5, 1.0, -0.5) with additive blending. Positive color values are given for ...
ImageMagick can be really useful for this kind of tasks. Converting your tile with magenta background to an image with transparency is as simple as this:
Judging from a quick look at the libgdx wiki's SpriteBatch entry, alpha blending is on by default.
Blending is enabled by default. This means that when a texture is drawn, translucent portions of the texture are merged with pixels already on the screen at that location.
This means that you can do what you said: open the Hero texture in Paint .NET and "...
What do you get if you try and swap the order you draw them in?
Transparent pixels still create depth buffer entries. If you're drawing the back one after the first it's not processing the pixels behind the front image, making it look like there's no alpha.
For reference, take a look at the Painter's alogrithm.
When rendering with multisampled anti-aliasing, a coverage value is computed for each fragment; this coverage value is based on the fraction of the pixel that would be covered by the fragment based on the triangle that created the fragment. The net result is that the edges of the triangle are anti-aliased. Because the coverage is based ultimately on what the ...
Just don't write to the depth buffer when rendering the particles. This will allow them to all be rendered and blended with each other. You should still perform depth testing though so that they can be properly occluded by geometry in the scene.
Your alpha-blended objects should not participate in a depth pre-pass. For a given final pixel, its color will be a number of colors blended together at different depths: the portion of the color furthest away from the camera will either be the sky/background or an opaque object, and all the other contributions will be from semi-transparent objects. And if ...
I've been the graphics performance guy for a few big-name 3D iOS titles, so I completely feel your pain on this one.
My experience has been that transparent pixels are the most expensive thing you can render on modern iOS devices. Your conjecture is right; the greater number of pixels on the iPhone4 really kills its performance in general, and transparent ...
You don't, at least not for writes. Z-buffer writing/ordering and transparency is not really something you can do easily. Most techniques require significantly more work than you're likely prepared for, like using depth peeling.
Sort your objects. Typically you would sort opaque (or alpha cutout) objects front-to-back with Z-buffering enabled, then do a ...
The term comes from the definition of "channel" that means a specific portion of a frequency spectrum. In this case, the red, green and blue components of a color are often referred to as "channels" (since red, green and blue light are portions of the visible light spectrum).
Since alpha is another component of color in computer graphics (although not one ...
Yes, it's possible. The general idea is called order independent transparency (OIT).
OIT often relies on some form of sorting still (you in fact must having some form of sorting for certain types of blending!) but pushes the work out into the GPU, perhaps sorting per-pixel rather than per-face.
The more advanced and actually feasible forms of OIT require ...
(No experience with 3D programming on iOS, but this should work on regular OpenGL devices.)
I can think of 2 options that might fix this.
Try separating the model in 2 parts, first render the opaque part and then render the transparent part.
Another option might be to disable alpha writing when rendering the object.
What I think is happening is that when ...
Using additive blending order doesn't matter:
// Now turn depth masking on and blending off, so state is unchanged.
This assumes that your sprite texture has a transparent background.
Alpha blending in 3D is tricky, simply due to the fact that you're (usually) still rendering the quad (or polygon) to the depth buffer using the depth buffer, even if your visible texture is just a tiny part of that.
To achieve proper rendering you'll have to render everything in the correct order, essentially from back to front. If you don't use the ...
You want a stencil.
Stencils let you flexibly define regions that love.graphics operations won't affect.
Here's an example. It does this:
Draw some colourful circles.
Set an inverted stencil made of two triangles.
Draw a black rectangle over everything.
See how the black rectangle doesn't actually cover everything? It's cut out where the triangles were. ...
JPG is lossy. Don't use that for sprites -- you will end up with nasty artifacts that will look bad. There's a couple reasons you might want to use colur-keying, but they're a bit lost in todays hardware. Taking a quick look at color key advantages:
They use up less disk space -- there is no alpha channel to store
By consequence, their memory foot ...
This is a pretty advanced topic. Generally people like to use Boolean Set Operations implemented with a BSP tree for this kind of destruction, which revolves around splitting polygons over planes. Take a look at this paper by Naylor to learn how.
This will let you overlay one mesh upon another and perform a subtraction. The results of the subtraction can ...
With the help of Bálint, I successfully got the issue fixed.
Bálint suggested using the discard keyword in GLSL to discard pixels that are not visible (i.e, transparent).
So inside my fragment shader, I'm checking the pixel's alpha value and if it's below a certain threshold, the pixel is discarded and therefore not rendered.
vec4 PixelColor = texture2D(...
Just change your Stencil like below Image:
Stencil Op/Comparison Values
0 - Always
1 - Never
2 - Less
3 - Equal
4 - LEqual
5 - Greater
6 - NotEqual
7 - GEqual
8 - Always // (This is the default for the UI shaders so I suspect this one is technically the 'correct' Always, but any value beyond it will also count as Always)
This looks like a culling issue, like Trevor Powell pointed out. A simple way to test if it really is a problem related to culling is to turn it off like this:
RasterizerState rasterizerState = new RasterizerState();
rasterizerState.CullMode = CullMode.None;
GraphicsDevice.RasterizerState = rasterizerState;
Please note that disabling culling is not the ...
I think the 0.5 falloff is really too strong and unnecessary; with 0.1 instead you will probably discard 95% of the fragments you already discard. You could even smooth the alpha to avoid remaining artifacts:
if (SampledColor.a < 0.1)
SampledColor.rgb *= smoothstep(0.1, 1.0, SampledColor.a);
There are ways to load images without premultiplication in Android as suggested in this thread. It's also possible to do that without any additional memory penalty at least by doing it completely on the native side, but I don't go to the details here.
If you can use premultiplied alpha and it doesn't e.g. make your content pipeline harder, you should. It ...