OGRE Manual v1.6 ('Shoggoth'): Script Inheritence

[ < ] | [ Up ] | [ > ] |  |  |  |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### 3.1.11 Script Inheritence

When creating new script objects that are only slight variations of another object, it's good to avoid copying and pasting between scripts. Script inheritence lets you do this; in this section we'll use material scripts as an example, but this applies to all scripts parsed with the script compilers in Ogre 1.6 onwards.

For example, to make a new material that is based on one previously defined, add a colon : after the new material name followed by the name of the material that is to be copied.

Format: material <NewUniqueChildName> : <ReferanceParentMaterial>

The only caveat is that a parent material must have been defined/parsed prior to the child material script being parsed. The easiest way to achieve this is to either place parents at the begining of the material script file, or to use the 'import' directive (See section 3.1.14 Script Import Directive). Note that inheritence is actually a copy - after scripts are loaded into Ogre, objects no longer maintain their copy inheritance structure. If a parent material is modified through code at runtime, the changes have no effect on child materials that were copied from it in the script.

Material copying within the script alleviates some drudgery from copy/paste but having the ability to identify specific techniques, passes, and texture units to modify makes material copying easier. Techniques, passes, texture units can be identified directly in the child material without having to layout previous techniques, passes, texture units by associating a name with them, Techniques and passes can take a name and texture units can be numbered within the material script. You can also use variables, See section 3.1.13 Script Variables.

Names become very useful in materials that copy from other materials. In order to overide values they must be in the correct technique, pass, texture unit etc. The script could be layed out using the sequence of techniques, passes, texture units in the child material but if only one paramter needs to change in say the 5th pass then the first four passes prior to the fith would have to be placed in the script:

Here is an example:

    material test2 : test1
    {
      technique
      {
        pass
        {
        }

        pass
        {
        }

        pass
        {
        }

        pass
        {
        }

        pass
        {
    	  ambient 0.5 0.7 0.3 1.0
        }
      }
    }

This method is tedious for materials that only have slight variations to their parent. An easier way is to name the pass directly without listing the previous passes:

    material test2 : test1
    {
      technique 0
      {
        pass 4
        {
    	  ambient 0.5 0.7 0.3 1.0
        }
      }
    }

The parent pass name must be known and the pass must be in the correct technique in order for this to work correctly. Specifying the technique name and the pass name is the best method. If the parent technique/pass are not named then use their index values for their name as done in the example.

### Adding new Techniques, Passes, to copied materials:

If a new technique or pass needs to be added to a copied material then use a unique name for the technique or pass that does not exist in the parent material. Using an index for the name that is one greater than the last index in the parent will do the same thing. The new technique/pass will be added to the end of the techniques/passes copied from the parent material.

Note: if passes or techniques aren't given a name, they will take on a default name based on their index. For example the first pass has index 0 so its name will be 0.

### Identifying Texture Units to overide values

A specific texture unit state (TUS) can be given a unique name within a pass of a material so that it can be identified later in cloned materials that need to override specified texture unit states in the pass without declaring previous texture units. Using a unique name for a Texture unit in a pass of a cloned material adds a new texture unit at the end of the texture unit list for the pass.

    material BumpMap2 : BumpMap1
    {
      technique ati8500
      {
        pass 0
        {
          texture_unit NormalMap
          {
            texture BumpyMetalNM.png
          }
        }
      }
    }

### Advanced Script Inheritence

Starting with Ogre 1.6, script objects can now inherit from each other more generally. The previous concept of inheritance, material copying, was restricted only to the top-level material objects. Now, any level of object can take advantage of inheritance (for instance, techniques, passes, and compositor targets).

    material Test
    {
        technique
        {
            pass : ParentPass
            {
            }
        }
    }

Notice that the pass inherits from ParentPass. This allows for the creation of more fine-grained inheritance hierarchies.

Along with the more generalized inheritance system comes an important new keyword: "abstract." This keyword is used at a top-level object declaration (not inside any other object) to denote that it is not something that the compiler should actually attempt to compile, but rather that it is only for the purpose of inheritance. For example, a material declared with the abstract keyword will never be turned into an actual usable material in the material framework. Objects which cannot be at a top-level in the document (like a pass) but that you would like to declare as such for inheriting purpose must be declared with the abstract keyword.

    abstract pass ParentPass
    {
        diffuse 1 0 0 1
    }

That declares the ParentPass object which was inherited from in the above example. Notice the abstract keyword which informs the compiler that it should not attempt to actually turn this object into any sort of Ogre resource. If it did attempt to do so, then it would obviously fail, since a pass all on its own like that is not valid.

The final matching option is based on wildcards. Using the '*' character, you can make a powerful matching scheme and override multiple objects at once, even if you don't know exact names or positions of those objects in the inherited object.

    abstract technique Overrider
    {
       pass *color*
       {
          diffuse 0 0 0 0
       }
    }

This technique, when included in a material, will override all passes matching the wildcard "*color*" (color has to appear in the name somewhere) and turn their diffuse properties black. It does not matter their position or exact name in the inherited technique, this will match them.

[ < ] | [ Up ] | [ > ] |  |  |  |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

This document was generated by Steve Streeting on July 26 2009 using texi2html