Tag Info

Hot answers tagged

13

I admit I'm not aware of any ideal solution to this problem, so I'll describe a workaround that you may or may not be comfortable with: Render all of the particles using additive blending to a separate texture (or render target) with its background cleared to transparent. Render that texture (or render target) on top of your scene using alpha blending. I ...


10

Short Answer Look into depth peeling. From my research it seems to be the best alternative, although computationally expensive because it requires multiple rendering passes. Here's another more recent and faster implementation, also by NVIDIA. Long Answer That is a tough question. Most books I've read skim over the subject and leave it at: Start by ...


8

The correct answer is #1: sort all of your things by depth and render them (obviously turn off depth writing, but not testing). What is a "thing"? Each "thing" must be a convex object; it cannot self-overlap. If you have an object that is concave, it must therefore be broken up into convex pieces. This is the standard way of rendering a transparent scene. ...


7

Have a look at premultiplied alpha. http://blogs.msdn.com/b/shawnhar/archive/2009/11/07/premultiplied-alpha-and-image-composition.aspx


6

OK, so here's my solution (please comment if it can be done better)... Turns out that I should in fact be using alpha testing (though, I discovered this by accident, so I'm not entirely sure why it works). create() { // ... // some other code here // ... Gdx.gl.glEnable(GL10.GL_DEPTH_TEST); Gdx.gl.glEnable(GL10.GL_ALPHA_TEST); } ...


5

case GL_FUNC_ADD: output = add( source_colour, destination_colour ) This is where you've gone wrong. The source and destination factors are multiplied into the source and destination colors, then added together. The OpenGL Wiki article on blending goes into greater detail on this matter.


5

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


5

You have to stop thinking of blend equations (and any graphics mechanism or tool) as "what it looks like." Blend equations are not "additive", "multiplicative" or anything of the sort. The blend equations do math; that's all they do. The question is how you use that math to achieve a desired visual effect. The limits are your imagination. If you can't see ...


5

With the introduction of programmable blending units, the intuitive meaning of alpha being a measure of opaqueness doesn't always hold. In the two-operand blend you have two contributing fragments: the source (what you're blending, the new fragment), the destination (what already exists in the spot you're blending to). You have two independent blending ...


4

Bad news is that you can't implement all of photoshop's blend modes with glBlendFunc, even though there are a bazillion of combinations that you can use. Good news is, when you move to shaders, the orange book (OpenGL Shading Language, http://www.amazon.com/exec/obidos/ASIN/0321637631/khongrou-20 ) contains a chapter with shaders to emulate the photoshop's ...


4

This is called inverse kinematics. Google is probably your best friend on this one as it can get complex.


4

Your problem lies in the Z-Buffer. When you draw transparent polygons, depth writing must be disabled to achieve correct transparency, or the polygons must be ordered back-to-front so they correctly overlap. But, since you are drawing a concave object (one plane intersects the other) and it has transparent and opaque sections, both of these methods can't be ...


4

It looks to me like depth write is enabled when you draw the trees. The problem is that whichever quad draws first lays down depth as if the whole quad was opaque, when it's not, due to the alpha-blended texture. When the second quad draws, parts of it are culled away that should be visible. There are a few possible approaches to fix this, each with its ...


4

As David Gouveia pointed out, there's no satisfying replacement for additive blending on bright backgrounds. The best effect I found (that doesn't require something like rendering to a backbuffer) is to use the following GL blendmode: SRC: GL_ONE DST: GL_ONE_MINUS_SRC_ALPHA It's not as nice as additive blending, but way better than GL_SRC_ALPHA, ...


4

You can use geometry instancing to draw a large number of trees in one draw call. (That article is written about Direct3D 9, but the same feature should be available in any 3D graphics API.) That should improve CPU performance, if that's indeed the bottleneck. If the trees are alpha-blended you still have to sort them back-to-front yourself, though, which ...


4

Edit: I missed that these aren't sprites, but actually polys. You want multitexturing. Keeping the content here, hopefully off use to someone looking for something similar. You want to create a series of "Fringe" tiles and layer those where you need them. You will need to create corner and edge pieces for each of the tiles you intend to use, and it would be ...


4

It is called a barycentre. Here your point is: P = (A * A_ratio + B * B_ratio + C * C_ratio) / (A_ratio + B_ratio + C_ratio) Badly, Wikipedia have no dedicaced page for this, so you'll have to understand the explanation of center of mass, which is just a generalization of barycentres applied to physics. EDIT: your second method is equal to: P - default ...


4

The problem is caused by the SpriteBatch.Begin() changing some of the rendering states. This problem is solved in XNA 3.1 and earlier by using the SaveState flag (see this answer). However in XNA 4.0+ you need to restore the state yourself. Insert the following code after your sprite drawing but before your model drawing (or 3D primitive drawing) ...


4

Missed mentioning that my intention is for clusters of point sprites with the same pigment (red) to additive blend to yellow and white. That right there is indicative of your problem. You cannot take a color value of (0.25, 0, 0), and add it to itself and get anything besides more red. It will not magically become yellow, then white. It will always be ...


4

You can achieve the effect you are looking for by setting the color value to non-pure red. In the picture below I have drawn a circle with additive blending multiple times with small offsets. On the left the color is pure red (255, 0, 0) and on the right it is (255, 20, 5). From these you can calculate that to get full yellow, you need 255/20=13 overlapping ...


3

I think it has something to do with the z sorting. Try not writing to the z-buffer when rendering your particles using : glDepthMask(GL_FALSE); And don't forget to reset it to GL_TRUE after that.


3

Have you tried using both? Layer on some particles with alpha blending, which should get your colors the way you want, then come back with some additive blending to get the nice highlight that you're looking for.


3

Well first off, the particle images you're using appear to have a black background, resulting in the dark fringes in that second image. Don't do that; that is, don't draw the shape of the particle on the color channels. Instead, the image should be solidly colored and only define the shape in the alpha channel. Doing that will improve the look of alpha ...


3

Turning Sam's comment into an answer, you need to do all your rending in two passes. For your first pass, draw only the foreground objects into an off-screen buffer/FBO. If you're using multiplicative blending you might get your desired effect with a white background; with additive blending, you may want a black background. Remember to clear to and update ...


3

To build upon Sean's answer, you don't need to make a separate FBO in order to render the effect you're looking for. Unfortunately, you cannot do it in a single pass because you're asking for two different blending operations for the pixels depending on whether or not your orange triangle is overlapping the light blue one. Fortunately, this is an excellent ...


3

Lets look at what your blend setup is actually doing: PDevice->SetRenderState(D3DRS_SRCBLEND,D3DBLEND_SRCALPHA); PDevice->SetRenderState(D3DRS_DESTBLEND,D3DBLEND_ONE); This means that your colors are calculated by: ScreenPixel = OldPixel + NewPixel * NewPixel.a So expanding your blend sequence gives you: color += texture1 * texture1.a; color += ...


3

In your first example (glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)), you're telling it to blend colors based on the alpha of the image which gets drawn on top (the "Foreground" one). So when you're blending 50% between the foreground color (38,50,168) and the background color (38,50,168) in the bottom left corner of the image, you unsurprisingly get ...


2

Here's a custom BlendState that should do the same as Game Maker's bm_subtract does, based on the post found here. Here's a complete example with combining two RenderTarget2Ds, so you also see how they work in practice. private GraphicsDeviceManager graphics; private SpriteBatch spriteBatch; private RenderTarget2D sprites; private RenderTarget2D shadows; ...


2

Are you just trying to scale the value of the alpha coming out of the texture? If so you can just supply a floating point value between 0 and 1 as a scaling value in the part "vec4(colour,1)" instead of the 1.


2

Alpha testing is used to stop the renderer drawing pixels to any buffer, including the z buffer. Alpha blending is just a visual thing - values are still written to the zbuffer, which can result in problems like this - invisible pixels are infront of subsequently rendered pixels which means they'll fail the ztest when you draw the new pixels. This is what ...



Only top voted, non community-wiki answers of a minimum length are eligible