Alpha blending w/o color loss

Finally got my 2D system working inside of Direct3D. I'm ready to implement my heads up display for my space ships, but I have one problem.

It seems that my alpha blending technique is causing the original color of the bitmap to be altered somewhat. I want the image color to stay intact, yet still be blended into the background.

Here is what I'm using:

1. Create image.
2. Grey scale and use as alpha texture.
3. Use DirectX texture tool to load image.
4. Convert image to A8R8G8B8 format.
5. Load alpha texture onto surface.
6. Save as DDS file.
7. Load into game engine.

Here are the device states:

Device->SetRenderState(D3DRS_ALPHABLENDENABLE,true);
Device->SetRenderState(D3DRS_SRCBLEND,D3DBLEND_SRCALPHA );
Device->SetRenderState(D3DRS_DESTBLEND,D3DBLEND_INVSRCALP HA);

Here is the result. My blue targeting cursor has turned a sky blue color. I know why its that color, but I'm not sure how to prevent it from changing colors.

Mr. Wizard???

Are you after Alpha Transparency? Do you have your alpha texture stage set to:

Code:

---

SetTextureStageState(0,D3DTSS_ALPHAARG1,D3DTA_TEXTURE);

---

Your SetRenderStates are correct.

Yes I get the same thing.
Let me enlarge the TLVertex object and show you.

Don't worry about the frame rates. I wondered why they were not faster myself until I remembered that I have it vsynced instead of D3DPRESENT_IMMEDIATE. Without vsync this thing tears really bad so I had to enable it until I begin to tax D3D somewhat.

Too many FPS. It's a good problem.

Seems like your alpha might be backwards, the way I do alpha blending in GL is like so:
GL_DST_ALPHA,GL_ONE_MINUS_SRC_ALPHA

with the destination alpha being normal, and the source alpha inverted to make it fade to black, instead of what yours seems to be doing and fading to white.

I fixed it.

I was using a specular component as well and this caused D3D to change the color of my texels. I'm not sure why since lighting is turned off for the heads up display textures. However, I've got it working now.

Code:

---

struct HUDTLVertex
{
D3DXVECTOR3 Pos;
D3DCOLOR Diffuse;
float u,v;
static const DWORD FVF;
};
 
const DWORD HUDTLVertex::FVF=(D3DFVF_XYZRHW | D3DFVF_DIFFUSE | D3DFVF_TEX1);

---

This works very well.

I've looked into ID3DXSprite and it is not that complicated but I haven't used any of it yet. Not sure if I will or not.

Thanks all for the help.

Incidentally, D3DBLEND_INVSRCALPHA is 1-SrcAlpha.

Quote:

---

Incidentally, D3DBLEND_INVSRCALPHA is 1-SrcAlpha.

---

oh, duh, I misread your original code and thought it was placed in there backwards for some reason :o

The engine's looking really awesome so far btw.

Are you still working on lighting? I do think that this is some excellent work but for some reason that atmospere seems to create too much of a milkyness over the planet. It would loog soooooo good if the planets color was more defined.

I'm working on doing some bump mapping and texture blending and/or detail texturing. However nothing is working.

Device->SetTexture(0,Texture);
Device->SetTexture(1,DetailTexture);

Device->SetTextureStageState(0,D3DTSS_COLORARG1,D3DTA_TEX TURE);
Device->SetTextureStageState(0,D3DTSS_COLOROP,D3DTOP_SELE CTARG1);

Device->SetTextureStageState(1,D3DTSS_COLORARG1,D3DTA_CUR RENT);
Device->SetTextureStageState(1,D3DTSS_COLORARG2,D3DTA_TEX TURE);
Device->SetTextureStageState(1,D3DTSS_COLOROP,D3DTOP_ADDS MOOTH);

Device->SetTextureStageState(2,D3DTSS_COLOROP,D3DTOP_DISA BLE);

Planet.GetMesh()->DrawSubset(0);


It is as if texture stage 1 has no texture in it at all. Perhaps my card does not support multiple texture blending in one pass. This should blend texture 1 with texture 2 using the ADDSMOOTH operation. Again, its not working. Guess I'll check the device caps. I'd hate to have to re-render the whole planet just to get detail mapping done.

This is a nasty way to detail map my planets. I'm not happy about the re-render but so far its all I can do till I get my pixel and vertex shaders up and running.

Quote:

---

Originally Posted by Vicious

Are you still working on lighting? I do think that this is some excellent work but for some reason that atmospere seems to create too much of a milkyness over the planet. It would loog soooooo good if the planets color was more defined.

---

Yes, the earths perimeter is 40,000 kilometers. However, the space begins at mere 100 km from the surface.

Here's a nice picture
http://grin.hq.nasa.gov/IMAGES/SMALL...000-001437.jpg

Here is another shot with some different color settings.

There are so many variations, I'm lost as to which one's to use.

Here is a blue atmosphere surrounding a detail mapped earth.

It almost looks like bump mapping but its not. It's fake bump mapping.

Well my texture looks like that pic with no atmosphere and nothing extra.

the above pic looks best imo

Quote:

---

Originally Posted by Bubba

Well my texture looks like that pic with no atmosphere and nothing extra.

---

Of those you've shown here, I like that picture best.

It looks to concrete for my tastes but I guess I will stick with it.

Adding a sun glare quad to the screen tonight. I will simply alter the alpha value of the quad based on the normalized dot product of the camera lookVector and the incoming light vector. When the value is 1, the quad will be rendered at near opaqueness and when it is 0 it will not be rendered at all. If it is <0 it also will not be rendered since the angle would be obtuse and the sun rays would be behind the camera.

This will work for just a camera but when I add in 3D cockpits I will need to cast several rays towards the sun and see if they hit.

I'm looking heavily into stencil buffer shadow volumes for my engine but I'm not sure that it would really add much to a space genre game. Problem is that there really isn't a lot of occluders and shadows in space. You might have a moon shadow onto a planet, but any render of that would look superficial at best. I do want my ships to shadow onto surfaces, however if they shadow onto a planet it is possible that their actual size in comparison to the planet's may stick out like a sore thumb. Also in pictures from the shuttle it appears that the shuttle is so far away from the earth that it does not cast a shadow onto it.

What I might do is create small shadow volumes for self-occluders, that is, elements of a ship that self shadow onto the ship. This would be pretty simply since the shadow volume would not need to extend to infinity. If the ship was very far away from the camera shadowing would not be rendered since you would probably never see it. So the shadow volume should never be clipped by the far clip plane. The near clip plane however would be a problem and I'll probably have to hack it since there is no known good algorithm for perfect near plane shadow volume clipping issues.

Anyways I really need more help on this engine. The whole rendering code needs to be revamped to handle vectors of objects that need to be rendered. The setup code needs to be altered to read the info from a file for the current system and then setup the appropriate variables based on the file contents. Right now a lot of this is hard-coded simpy for testing purposes but the quicker I move away from that mentality and setup, the quicker I can insert new objects into my game to be used by the engine.

Animation classes, timers, and functionality is already in the engine but has not been tested or used yet. I'm not sure how to implement moving parts on ships and objects and I probably need to develop some type of small scripting language for events, ship patrols/movements, AI, etc.

Individual targeting of ships systems will not be implemented since that would require a significant more amount of ray to triangle intersection test code, or at the very least ray to bounding volume or cube tests. If I could get it to run at an acceptable frame rate I might consider it.

If you wish to help in any way please PM me. You can see that this engine is for real and so far has progressed quite nicely. I'm fairly sure my class setup has not coded me into any dark corners and adding classes to the engine is a snap. I'm developing an editor in Visual Basic that will create a type of binary ini file that will describe systems, patrol paths, asteroid/debris fields, suns/stars, rotations, commodities, ambient/specular/diffuse colors, planets (along with their associated colors, materials, shaders, rotational info, etc.), etc., etc.

Several new screenshots with sun glare (not lense flares) added to the camera.

Here is a pic about 5000 from the sun at a range of 10000 for the light.

This is very close to the light source or in this case the sun.

This is a screenie to prove that even though the light source is not in the frustrum, it's rays can still fall within it.

And here is a test of a new 20 planet render. So far everything shuts down perfectly...after a bit of debugging. All colors, positions, etc, are randomized.

Sorry here is the colored planet demo.

And a very nice render from one planet looking toward another.

And a more recent shot. Need more textures.

Nice work. Althought in some shots the targeting reticule is hard to see.
I think a small red circle would be good.

I only wish I had the time, patience, mental capacity, etc.. to learn this stuff.

Yeah that reticle will probably be changed about 50 times before I decide what to use.

You do have the mental capacity to learn this stuff. I flunked my high school algebra class and yet I taught myself all this. Don't underestimate yourself - just dive in head first. It's really sink or swim and you'll do a lot of sinking before you do some swimming, but the end result is worth it.

Quote:

---

Originally Posted by Bubba

Several new screenshots with sun glare (not lense flares) added to the camera.

---

Streaks like those in the image are generated in the camera/eye and should be rendered last, along with the corona -- which also is 99+% generated within the camera/eye.

Such small planets would be completly invisible in front of the sun without really strong sun glasses -- like the Venus passage in front of the sun this summer.

By definition, what exactly is a corona?

Quote:

---

Originally Posted by Vicious

By definition, what exactly is a corona?

---

http://fusedweb.pppl.gov/CPEP/Chart_...SunLayers.html

the corona-ish part.

So basically, in programming terms... A texture or effect to create a glowing around an object?

The order in which they are rendered has little to do with how the phenomena works in real life. The alpha blended images must be drawn after all other images or the alpha blending fails. As well I would have to create a light-based clipping volume to cause the planets to disappear and or include another lighting variable that the planets would test against to see if they would in fact be visible. This is not a 3D sun. All of my sun's and light sources are accomplished using 2D billboards with a technique that although criticized on this board is used quite often and I've found it in several books as well.

There is not any depth sorting going on yet in this engine which cause the alpha blended billboards to incorrectly be drawn on top of by the planets. The billboards do not write to the zbuffer and as such do not exist according to the buffer. But this has to be done so that my billboards can be transparent in places which is necessary for a sun. I've seen other sun corona effects with pixel shaders in Shader X2: Tips and Tricks but I've not been impressed with them.

I am frustrum culling simply based on the camera look vector right now which is not totally perfect since the dot product will produce values that pass the test, yet should not be drawn because they do not lie in the frustrum. The next phase is to test against the cube generated by the frustrum and then clip against the six sides of the volume. However, I'm not sure this is worth the extra cycles at this point. At the very least, the only objects affected by my not so perfect cull algo are those that lie between 0 and about .30 on either side of the camera. This, of course, also depends on the actual position of the object. I'm only culling based on the planet position vector, not based on the actual vertices of the planet which would be a very costly cull.

I'm going to do sun coronas by additive alpha blending another texture onto the billboard. I'm not sure yet if I'm going to generate this procedurally inside of a pixel shader or if I'm going to use a static one. Although it would be cool to see the sun actually surge and change shape, I'm not so sure it would look right at great distances.

I'm also going to change all planets to progressive meshes and perhaps add 3 materials and textures per planet.

The next step right now is to implement my pixel shader. I'm not so sure I'm going to include specular calculations because planets by their very nature are not shiny. So I'll probably leave the specular calculation for another shader that could be applied to more metallic surfaces. I'd like to do some bump mapping as well but I need to be careful about the level of detail on the planets or the illusion of distance and vastness of space will be lost.

The sun glare quad is rendered last and it has to be. The sun, since it is a billboard, is rendered after the non-alpha blended polies in the same manner as the explosions, nebulas, lasers, etc.

If you have any further suggestions on the engine I'm all ears.

Quote:

---

Originally Posted by Perspective

http://fusedweb.pppl.gov/CPEP/Chart_...SunLayers.html

the corona-ish part.

---

From that site:

Quote:

---

The outermost layer of the sun is the corona. Only visible during eclipses,

---

So, the "corona" you actually see is a phenomenon in your eye.

I'm not criticizing the particlar mehtod you've chosen to implement stars Bubba, I'm just saying that planets aren't visible in front of a sun and that planets don't hide the corona or the streaks when they are "in front" of them.

I've come up with some possible answers to the problem. The reason you cannot see the corona normally is because you are being bombarded with light rays coming directly at you this obscuring the corona. While I cannot simulate all the light rays I can 'fake it'.

Here is a possible setup. I will borrow from DOOM 3's stencil shadow volumes method.

First image: this shows the typical stencil shadow volume setup.

Here is the vector workup for the above image. I rotated it 90 degrees to show the vectors better.

And here are some possible solutions to the corona issue.

straight over my head :)

Perhaps I didn't do a good job of explaining it.

Here is the method I will probably use. It is the third method in my last illustration.

Here is the concept behind it:

Since we know from geometry that if the dot product of the normal to the plane in question and the light source is >0 the plane is receiving light, we can deduce that the plane as well must be facing the light. Not exactly rocket science. Since I'm already going to be computing the dot product at the vertices and interpolating in my pixel shader I can use this information to produce my sun corona effect around the planet.

Essentially if the surface being lit is being lit by a sun or a bright object then I must create the billboard corona around the planet or object in question. This will be a very very bright billboard that is alpha blended and additive blended with the background and with the object. I will also be able to limit the billboard being drawn to certain angles like dot>.70. This would equate to about -45 to +45 degrees. This means that the corona effect will only be drawn if the object in question is within -45 to +45 degrees of the light source. This will prevent corona's from being drawn outside of the actual sun billboard which would look very strange.

But to do this I need a couple more pieces of information in my class. Each light source that is extremely bright must have a smaller sampling of a very bright corona-like texture that will be then passed to the object(s) that fall within the correct range for the effect. I also will probably need to maintain the normalized vector for the light source so that I do not have to normalize it later thus wasting processor cycles.

I will attempt to implement this very soon because I like the idea of objects being obscured by extremely bright light sources.

And there are some errors in my picture.
It was very hard to get the text to look right since it was so lengthy.

Here is the vector workup.

The first thing that must be done is find the vertexes that are silhouette edges - or vertexes that lie at the edge of the occluder object. This is a time consuming process and is far beyond the scope of this post so I will skip it for now.

Let's just say we already know the edge vertexes and they are stored in EdgeVertex[].

The variables
Our light source position is Light.Pos and is a Vector3 or D3DXVECTOR3 - 3 floats.

Known values/equations
We know where the occluder is in world space. We know where the light is in world space.
We also know the parametric equation for a line.

Code:

---

newPoint=Origin+(Vector*Distance);

---

For example if we want to extend point A at an angle of 30 degrees and a distance of 100 units in 2D:

Code:

---

ExtendedA.x=A.x+(cos(DEGTORAD(30))*100);
ExtendedA.y=A.y+(sin(DEGTORAD(30))*100);

---

To extend a 3D line from VertexA in the direction of 3D vector V for a known distance D to create VertexB we do this:

Code:

---

VertexB.x=VertexA.x+(V.x*D);
VertexB.y=VertexA.y+(V.y*D);
VertexB.z=VertexA.z+(V.z*D);

---

or in Vector notation:

Code:

---

VertexB=VertexA+(V*d);

---

This is just a simple displacement.

Back to the shadow volumes
Ok so we know the light source position and the vertex edge in question.

The vector from the occluder vertex edge to the light is:

Code:

---

Vector3 LightVector(EdgeVertex[i].Pos-Light.Pos);

---

This must be normalized so we can work with unit vectors. Otherwise we will get some very large values and it will complicate the math.

Code:

---

nrmLightVector=Normalize(LightVector);

---

This is just a simple:

Code:

---


...
float length=sqrt((LightVector.x*LightVector.x)+(LightVector.y*LightVector.y)+(LightVector.z*LightVector.z));
 
float oneOverLength=1.0f/length;
 
nrmLightVector3.x=LightVector.x*oneOverLength;
nrmLightVector3.y=LightVector.y*oneOverLength;
nrmLightVector3.z=LightVector.z*oneOverLength;
...

---

Ok so now we have a normalized light vector called nrmLightVector. Let's say we want to extend our shadow for our object for 100 units. In actuality you would either compute the angle of the light source in relation to the actual height/width of the object. After all shadow lengths are proportional to the width/height of an object and the angle of the incoming light rays. But we are just going to use 100. Our shadow is going to be 100 units long.

Our new shadow vertex is:

Code:

---

ShadowVertex=EdgeVertex[i]+(nrmLightVector*100.0f);

---

We do this for both sides of the object and for all corner edge vertexes. We don't want to do this for every edge vertex because every edge does not contribute directly to the shadow. For instance in a very tall building that has uniform width all the way to the top. To compute a shadow volume for this we would simply use the top two vertexes that formed the roof and were facing AWAY from the light source. They must be facing away from the light source because if we selected those facing it, the shadow would actually pierce our object. Not what we want.

Again this is not totally correct because of our 'fake' shadow distance but it is close enough for simplicity's sake.

So now we have created two new vertexes from two edge vertexes on our object. The only thing we do now is cap them with a line at the far end and near end (draw a horizontal line between the two new vertexes and draw a line between the two known vertexes). These act as our shadow volume 'caps'. Note that I'm only using two vertexes to explain this, but in actual practice you would probably have more. Now triangulate the shadow volume. You are done with the shadow volume.

After this comes the important part of figuring out what lies in shadow and what does not based on depth-fail or depth-pass methods so we can paint the stencil buffer correctly. After we figure this out we then render the shadow volume into the stencil buffer. Pixels that fail the stencil buffer test get 'darkened'. How dark is up to you. Pixels that pass the test are simply rendered as is.

There is a lot more to the technique - far more than I can explain here. But that is the general idea of it.