OGRE Wiki
Support and community documentation for Ogre3D
Ogre Forums
ogre3d.org
Log in
Username:
Password:
CapsLock is on.
Remember me (for 1 year)
Log in
Home
Tutorials
Tutorials Home
Basic Tutorials
Intermediate Tutorials
Mad Marx Tutorials
In Depth Tutorials
Older Tutorials
External Tutorials
Cookbook
Cookbook Home
CodeBank
Snippets
Experiences
Ogre Articles
Libraries
Libraries Home
Alternative Languages
Assembling A Toolset
Development Tools
OGRE Libraries
List of Libraries
Tools
Tools Home
DCC Tools
DCC Tutorials
DCC Articles
DCC Resources
Assembling a production pipeline
Development
Development Home
Roadmap
Building Ogre
Installing the Ogre SDK
Setting Up An Application
Ogre Wiki Tutorial Framework
Frequently Asked Questions
Google Summer Of Code
Help Requested
Ogre Core Articles
Community
Community Home
Projects Using Ogre
Recommended Reading
Contractors
Wiki
Immediate Wiki Tasklist
Wiki Ideas
Wiki Guidelines
Article Writing Guidelines
Wiki Styles
Wiki Page Tracker
Ogre Wiki Help
Ogre Wiki Help Overview
Help - Basic Syntax
Help - Images
Help - Pages and Structures
Help - Wiki Plugins
Toolbox
Freetags
Categories
List Pages
Structures
Trackers
Statistics
Rankings
List Galleries
Ogre Lexicon
Comments
History: Brain Damage part 1 - JaJDoo Shader Guide - Basics
View page
Source of version: 2
(current)
!:::Do that thing again!::: !:::Or::: !:::All sorts of pass properties::: {maketoc} !Here it comes 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. !!The subjects # Culling # 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 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: {IMG(src="display1878", width="230",height="215")}{IMG} 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: {IMG(src="display1879", width="230",height="190")}{IMG} Notice we can see the grid? This means that we are actually looking inside the sphere. !!Code As default culling is deactivated (By default cullMode = NONE) If you want to activate it, add one of the following to your pass: {CODE(wrap="1", colors="c++")} cullMode = cw; //Or cullMode = ccw; {CODE} !!In OGRE Within your OGRE material script, you can set both hardware and software culling, read about them in the OGRE manual: {CODE(wrap="1", colors="c++")}cull_hardware <clockwise | anticlockwise | none> cull_software <clockwise | anticlockwise | none>{CODE} !Color channels 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 {CODE(wrap="1", colors="c++")}colorWriteEnable = [value];{CODE} The values follow the color circle: {IMG(src="display1883")}{IMG} 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? {FANCYTABLE(sortable="n")}0 | Off 1 | Red 2 | Green 3 | Yellow 4 | Blue 5 | Purple 6 | Light Blue 7 | All on (white){FANCYTABLE} !!In OGRE 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. {CODE(wrap="1", colors="c++")}colour_write <on|off>{CODE} 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 !!What is? 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: {CODE(wrap="1", colors="c++")}Color = sourcePixelColor x srcBlend + destPixelColor x DestBlend{CODE} 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. !!!Alpha blend vs color blend 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. !!!Values Both source and destination can accept any of the following values: {FANCYTABLE(sortable="n")}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){FANCYTABLE} To use blending in a pass, we need to add these 3 properties: {CODE(wrap="1", colors="c++")}AlphaBlendEnable = true; srcBlend = one; destBlend = zero;{CODE} 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. {IMG(src="display1881", width="230",height="240")}{IMG} Let’s use these values in the equation and see why: {CODE(wrap="1", colors="c++")}Color = sourcePixelColor x srcBlend + destPixelColor x DestBlend Red = Red x 1 + White X 0{CODE} 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: !!!Completely transparent If you swap the values of the default, your source will disappear completely from the scene, because it has no blending weight: {CODE(wrap="1", colors="c++")} srcBlend = zero; destBlend = one;{CODE} {IMG(src="display1882", width="230",height="230")}{IMG} It’s there, I swear it. !!!Blackness 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. {CODE(wrap="1", colors="c++")}srcBlend = zero; destBlend = zero;{CODE} {IMG(src="display1880", width="230",height="215")}{IMG} I can swallow your sun. Seriously !!!I want it all! If you give both src and dest value of one, the result will be an additive blend. {CODE(wrap="1", colors="c++")}srcBlend = one; destBlend = one; {CODE} {IMG(src="display1885", width="230",height="210")}{IMG} By the way, I culled. If I hadn’t, I would have got: {IMG(src="display1884", width="230",height="230")}{IMG} See the ugly Artifact in the bottom? Culling has a practical use you can actually see! !!Common blending techniques Now that we played a little with the values to get a better sense of what they mean, let’s blend like adults. !!!Pure alpha blending 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. {CODE(wrap="1", colors="c++")}srcBlend = srcAlpha; destBlend = invSrcAlpha; {CODE} {IMG(src="display1887", width="230",height="230")}{IMG} 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: {CODE(wrap="1", colors="c++")}srcBlend = srcAlpha; destBlend = destAlpha;{CODE} The result will be: {IMG(src="display1888", width="230",height="240")}{IMG} 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 Pure color blending works the same as alpha blending, but uses the color channels instead. {CODE(wrap="1", colors="c++")}srcBlend = srcColor; destBlend = invSrcColor;{CODE} {IMG(src="display1889", width="230",height="200")}{IMG} Pure color blend when ambient is complete black. {IMG(src="display1891", width="230",height="170")}{IMG} …Same but with red ambient color. Notice how the color turns yellow in blended part. !!!Multiplicative and 2X multiplicative blending One way multiplicative is defined as either: {CODE(wrap="1", colors="c++")}srcBlend = zero; destBlend = srcColor; {CODE} Or {CODE(wrap="1", colors="c++")}srcBlend = destColor; destBlend = zero; {CODE} 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. {IMG(src="display1890", width="230",height="180")}{IMG} 2X multiplicative is defined as: {CODE(wrap="1", colors="c++")}srcBlend = destColor; destBlend = srcColor;{CODE} In 2X we combine the intensity and the color of both source and destination. {IMG(src="display1892", width="230",height="230")}{IMG} 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 {CODE(wrap="1", colors="c++")} srcblend = destalpha; destblend = srcalpha;{CODE} The result will be one of my favorite stupidities: {IMG(src="display1894", width="230",height="200")}{IMG} !!Blend in OGRE scripts 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: {CODE(wrap="1", colors="c++")}scene_blend <add|modulate|alpha_blend|colour_blend>{CODE} 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: {CODE(wrap="1", colors="c++")} srcblend = destColor; destblend = zero; {CODE} And gives the following result: {IMG(src="display1893", width="230",height="170")}{IMG} {QUOTE(replyto="the OGRE manual")}Generally colours and darkens the scene, good for smoked glass, semi-transparent objects etc{QUOTE} 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: {FANCYTABLE(sortable="n")}one zero dest_colour src_colour one_minus_dest_colour one_minus_src_colour dest_alpha src_alpha one_minus_dest_alpha one_minus_src_alpha{FANCYTABLE} If your logic organ is not operational, ‘one minus’ means inverse. !Depth buffer !!What is? 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. !!Control 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. {FANCYTABLE(sortable="n")}Less |means closer to you Greater| farther away Equal | guess NotEqual | either less or greater… Always | I’m not answering you Never | the last statement did not change LessEqual | GreaterEqual | {FANCYTABLE} 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. !!Depth in OGRE The difference is almost negligible, text from the OGRE manual: !!!Methods __depth_check (on|off) __ The ZEnable of OGRE. Actually, in most cases it is called z test or check. __depth_write (on|off)__ __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 (func)__ depth_func values, shouldn’t be foreign to you: {FANCYTABLE(sortable="n")}always_fail always_pass less less_equal equal not_equal greater_equal greater{FANCYTABLE}
Search by Tags
Search Wiki by Freetags
Latest Changes
IDE Eclipse
FMOD SoundManager
HDRlib
Building Ogre V2 with CMake
Ogre 2.1 FAQ
Minimal Ogre Collision
Artifex Terra
OpenMB
Advanced Mogre Framework
MogreSocks
...more
Search
Find
Advanced
Search Help
Online Users
147 online users