Table of contents
- Do that thing again!
- All sorts of pass properties
- Here it comes
- Color channels
- Depth buffer
Other than defining a vertex and pixel program, your passes have all sorts of other functions they can perform. These properties are also called ”render states” or “pass attributes”. While each of these properties is potentially its own subject, they are hard to separate to individual chapters, and are better left tide to each other. Other than that, you can create multiple passes in each technique, allowing you to achieve more complex results.
In this chapter, we will overview some of the most commonly used properties and see how we can use them to enhance our rendering output.
- Color channels (color buffer)
- Blending (alpha and color)
- Z buffer (depth buffer)
- Multi-pass techniques and example usage (next chapter)
Most of the example usage is in the next chapter, so don’t be alarmed if you get confused; you might as well open the next chapter and read them simultaneously so you wont fall asleep while reading all the technical stuff.
Culling is the process of determining whether or not a polygon is visible or not when projected onto the screen before drawing it. In doing so, you can save GPU work and filter unwanted results while rendering.
When culling, you define which direction is “front” facing: clock-wise or counter clock-wise.
Whichever you choose, the other will be defined as the facing backwards. All polygons with that winding will fail the culling test, and thus will not be drawn.
We’ll take a sphere affected by Phong. If we choose that our cull mode is clock-wise, we will see what we usually would:
What you can’t see, is that the polygons in the other side of the sphere were not drawn, since they have a counter clock-wise winding.
If we define cull mode as counter clock-wise, the result will be:
Notice we can see the grid? This means that we are actually looking inside the sphere.
As default culling is deactivated (By default cullMode = NONE)
If you want to activate it, add one of the following to your pass:
cullMode = cw; //Or cullMode = ccw;
Within your OGRE material script, you can set both hardware and software culling, read about them in the OGRE manual:
cull_hardware <clockwise | anticlockwise | none> cull_software <clockwise | anticlockwise | none>
This is an easy to understand, short and unsigned int... Wait no…Subject.
During a pass, we can control whether or not to write into the color buffer, and in which channel. Disabling color writing is usually not an operation you will do on regular basic, but at times, it can be of great use.
To control what channel we wish to write in, we call
colorWriteEnable = [value];
The values follow the color circle:
Did you notice some of the diameters in the picture are not actually strait? I forgot I can draw the lines from side to side, and drew each radius alone. Looking at the bigger picture has never been my best quality.
Get it? Picture?
|7||All on (white)|
In an OGRE script, you can only command the colour_write on or off.
In fact, these are the only two values that you’ll ever use, but have a laugh, render a demon in pink in FXC.
And that’s it…
Usually, you will use this when you need to place things in the depth buffer but don’t wish to render at that particular pass.
Blending allows you to control how your pixel renders to the screen, in relation to pixels positioned behind it. As default, your pixel will overwrite the pixel behind it, which means it is completely opaque.
When blending, we use the following equation:
Color = sourcePixelColor x srcBlend + destPixelColor x DestBlend
The source is the pixel in the object we are blending with the scene (the one using this material)
The destination is the background it is blending with.
Both srcBlend and destBlend range from 1 (opaque) to 0 (transparent), normally, you will want the sum of srcBlend and destBlend to be 1 (each one will have a certain weight in the final color)
While in order to activate blending you use the “AlphaBlendEnable = true;” directive, you can blend either alpha channel or color channel.
So what is the difference between blending alpha and blending color? When you blend using alpha, the result will keep the original colors, but give each one a certain weight – effectively, mimicking transparency with different strengths. When you blend color, the result will be a different color.
If one of your pixels is green, and other is red, the resulting pixel will be yellow when color blending.
Both source and destination can accept any of the following values:
|ZERO||Value of 0 – no weight in blending|
|ONE||Value of 1 – the src/dest will be given full weight|
|SRCCOLOR||The color channel of the source pixel|
|INVSRCCOLOR||(1 – srcColor)|
|SRCALPHA||Alpha channel of the source pixel|
|INVSRCALPHA||Use ( 1 – srcAlpha)|
|DESTALPHA||Alpha channel of the destination pixel|
|INVDESTALPHA||( 1 – destAlpha )|
|DESTCOLOR||Color channel of the destination pixel|
|INVDESTCOLOR||( 1 – destColor)|
To use blending in a pass, we need to add these 3 properties:
AlphaBlendEnable = true; srcBlend = one; destBlend = zero;
By default, the above example is how your pixel is rendered to the screen (in ‘as if’, not literal; by default no blending check occurs). When the source pixel receives 1 and the destination receives 0, the source pixel is completely opaque.
Let’s use these values in the equation and see why:
Color = sourcePixelColor x srcBlend + destPixelColor x DestBlend Red = Red x 1 + White X 0
Say our current pixel is red, and the destination pixel is white;
As you can see, white color from the destination pixel has no weight in the final output.
Let’s see other simple examples:
If you swap the values of the default, your source will disappear completely from the scene, because it has no blending weight:
srcBlend = zero; destBlend = one;
It’s there, I swear it.
If you give both src and dest zero value, the result will be a black silhouette of the src object, since if none of the two receive weight; the result will be 0, and 0 means black.
srcBlend = zero; destBlend = zero;
I can swallow your sun. Seriously
If you give both src and dest value of one, the result will be an additive blend.
srcBlend = one; destBlend = one;
By the way, I culled. If I hadn’t, I would have got:
See the ugly Artifact in the bottom? Culling has a practical use you can actually see!
Now that we played a little with the values to get a better sense of what they mean, let’s blend like adults.
In order to create an alpha blending we will give the source pixel its own alpha weight, and give the destination pixel the inverse of the source alpha.
srcBlend = srcAlpha; destBlend = invSrcAlpha;
In this example, my diffuse and specular both have alpha of one, making them opaque, while the ambient has an alpha of 0.5, making it half transparent in regions effected by ambient alone.
Why not give each one its own alpha value? Because we want the destination pixel to be obscured by the source pixel. If we were to give it its own weight, we would end up with a sort of multiplicative blend.
If we use this:
srcBlend = srcAlpha; destBlend = destAlpha;
The result will be:
By giving the destination pixel the opposite value of the source alpha, we make the two “complete” each other (unlike the second example), allowing us to control how opaque or transparent the source pixel is by changing its alpha. The more we lower the source’s alpha, the higher the destination’s become, and vice versa.
Pure color blending works the same as alpha blending, but uses the color channels instead.
srcBlend = srcColor; destBlend = invSrcColor;
Pure color blend when ambient is complete black.
…Same but with red ambient color. Notice how the color turns yellow in blended part.
One way multiplicative is defined as either:
srcBlend = zero; destBlend = srcColor;
srcBlend = destColor; destBlend = zero;
The second one is the proper one, but the first one gives the same result.
In this method we use the ‘intensity’ of the source pixel, modulated by the destination pixel’s color.
2X multiplicative is defined as:
srcBlend = destColor; destBlend = srcColor;
In 2X we combine the intensity and the color of both source and destination.
Of course, there are all sorts of different combinations, some completely illogical, others just not very useful. Play with the values; see what you can come up with.
If you use
srcblend = destalpha; destblend = srcalpha;
The result will be one of my favorite stupidities:
In OGRE, blend is also part of your pass. It works somewhat the same, but a few differences.
First thing: it’s called “Scene Blend”.
Your first options are the automated values:
These 4 options have an automated behavior for source and destination. 3 of them you already know (add, alpha_blend and colour_blend).
The fourth – modulate – is setup as follows:
srcblend = destColor; destblend = zero;
And gives the following result:
Generally colours and darkens the scene,
good for smoked glass,
Your second option is setting the equation manually, like we did in FXC:
scene_blend <src_factor> <dest_factor>
The values are spelled differently, but shouldn’t be foreign to you:
If your logic organ is not operational, ‘one minus’ means inverse.
The depth buffer is, in a simplified description, is where all pixels in the same spot in the view queue in line, for the renderer to pick the closest one to it. By default, all pixels both write themselves to the buffer, and test themselves against the rest of the queue when the frame is being prepared or rendered.
The depth buffer has four control methods:
ZEnable = (true/false);
Whether or not the current pass will ignore the depth buffer or not, by default true. If false the pixel will always be rendered on top of all others (used in unit icons placed on billboards in many games). None of the other methods will take effect unless this method’s value is true.
ZWriteEnable = (true/false);
Whether or not the pixel will be written to the depth buffer for other pixels to test against
The result will usually not defer from ’ZEnable = false’ in first glance, but don’t be fooled, it’s very different.
DepthBias = (number);
This method provides the means to prevent Z fighting. Pixels affected by bias will “make way”. Used in most cases to ensure proper rendering of things such as shadows, projective decals or particle systems.
ZFunc = (options);
This method allows you to control in what manner the Z testing will behave. You can command it to which condition is the “win”: farther from the one you are testing, closer, or equal.
|Less||means closer to you|
|NotEqual||either less or greater…|
|Always||I’m not answering you|
|Never||the last statement did not change|
It’s hard to explain their effect without examples, try each value, and see how it affects the scene. In multi-pass techniques (in the next chapter) we will see a practical implementation.
The difference is almost negligible, text from the OGRE manual:
The ZEnable of OGRE. Actually, in most cases it is called z test or check.
depth_bias <constant_bias> <slopescale_bias>
The second one is optional. I’m not getting farther in for now, read about it in the manual if you like.
depth_func values, shouldn’t be foreign to you: