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-...
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 ...
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.
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 ...
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 ...
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 ...
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 ...
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)
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. ...
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(...
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 ...
For general transparency handling, you could use some form of order-independent transparency.
Typically, though, you sort by Z-distance along the camera view vector before rendering (you can get a "good enough for most uses" approximate with dot(camera.view, object.worldpos - camera.worldpos)). A high-powered rendering pipeline will sort all of its objects ...
If you want your character's look to change uniformly (i.e. at any time, all sprites are at the same point of transition between states), the simplest way I can think of is to create them as separate skins in Spine. The Unity runtime tfor Spine then lets you render the skeleton with either skin, so you can control the transparency by rendering each skin once,...
.png images wont show the transparent area. But you will have to make sure that the "white" area is transparent and not white.
If its not a .png image just go in to photoshop or any other image editor, cut out (magic wand) the white area and save it as a .png
Alpha channels were actually invented by George Lucas's company Industrial Light & Magic (actually Alvy Ray Smith did most of the work while working there, who was previously employed by Xerox PARC - who we can thank for almost everything in modern computing!).
Alpha channels, in addition to doing cool effects like transparent window, transparent ...
Making an object 'transparent' so it cannot be seen is not the most efficient way to do things. What you rather want to do is make the renderer inactive when you don't want to see it, and active when you do.
If you click on your gameObject in the editor, there should be a Mesh Renderer as one of the components.
To set it to inactive from a script attached ...
You should perform the depth test in the fragment shader "manually". OpenGL doesn't support multiple depth tests, and that its just what you need to render the second nearest pixels, because:
You need the second front pixels (GL_LESS over the actual depth buffer)
You need the second front pixels (GL_GREATER over the depth buffer of the first framebuffer).
One way to do this is with the clip function in a shader, which aborts rendering of a pixel if it fails a particular condition.
This lets you create custom-shaped clipping regions, but it has a downside: by the time you reach the clip test, most of the work of rasterizing the object is already done, so you end up paying a significant amount for the ...
Changing the colours of a vertex buffer is relatively expensive. You'd have to use something like VertexPositionColor and then modify every vertex every time you want to change transparency!
It would be much easier, and faster, to add transparency using a shader (pixel or vertex). Fortunately BasicEffect does exactly what you need - it even has an ...