Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm making an effect system right now (I think, because it may be a material system... or both!). The effects system follows the common (e.g. COLLADA, DirectX) effect framework abstraction of Effects have Techniques, Techniques have Passes, Passes have States & Shader Programs.

An effect, according to COLLADA, defines the equations necessary for the visual appearance of geometry and screen-space image processing. Keeping with the abstraction, effects contain techniques.

Each effect can contain one or many techniques (i.e. ways to generate the effect), each of which describes a different method for rendering that effect. The technique could be relate to quality (e.g. high precision, high LOD, etc.), or in-game-situation (e.g. night/day, power-up-mode, etc.). Techniques hold a description of the textures, samplers, shaders, parameters, & passes necessary for rendering this effect using one method.

Some algorithms require several passes to render the effect. Pipeline descriptions are broken into an ordered collection of Pass objects. A pass provides a static declaration of all the render states, shaders, & settings for "one rendering pipeline" (i.e. one pass).

Meshes usually contain a series of materials that define the model. According to the COLLADA spec (again), a material instantiates an effect, fills its parameters with values, & selects a technique. But I see material defined differently in other places, such as just the Lambert, Blinn, Phong "material types/shaded surfaces", or as Metal, Plastic, Wood, etc.

In game dev forums, people often talk about implementing a "material/effect system". Is the material not an instance of an effect? Ergo, if I had effect objects, stored in a collection, & each effect instance object with there own parameter setting, then there is no need for the concept of a material... Or am I interpreting it wrong?

Please help by contributing your interpretations as I want to be clear on a distinction (if any), & don't want to miss out on the concept of a material if it should be implemented to follow the abstraction of the DirectX FX framework & COLLADA definitions closely.

share|improve this question

These terms are not set in stone and every company and every piece of software may use them slightly differently. However, I believe that the most common meaning of "material" is just what you mentioned, i.e. an effect together with specific parameter values and textures to be bound to that effect, and applied to specific triangles or meshes of objects.

For example, Blinn-Phong shading could be an effect and various metals, plastics, woods, and many other materials could be made using Blinn-Phong shading with different textures, different specular values, etc. However, skin would require a different effect because it needs subsurface scattering features that the basic Blinn-Phong effect doesn't provide.

In a game engine, effects and materials would typically be two separate classes. An effect class would hold the compiled GPU code for the shaders, some information about the parameters and textures it supports/requires, and some logic that is common to all materials using that effect - for instance, technique selection logic (e.g. use the shadow map technique when drawing in the shadow map, select a quality level based on the object's distance to the camera, etc.), and logic for setting parameters that don't depend on the material (e.g. transformation matrices, global lighting parameters, etc.)

The material class would typically contain a reference to an effect, references to any relevant texture images, and a list of parameter values.

It wouldn't be good to have an effect instance for every material because then you'd be duplicating all the information (particularly the shader GPU code) unnecessarily. Moreover, you might want to have different lifetimes and loading models for the effects vs the materials. For example, you might load all the effects when your game starts up, but load materials for each level only when you load the level.

share|improve this answer
To add one idea: materials usually refer to values like friction in game engines too, not only visual effect values. – kaoD Apr 9 '12 at 3:36
The difference in usage does obfuscate. Different Digital Content Creation apps using different terminology means parsing of effect files such as the COLLADA FX could cause a mini-migrane. I'm currently working with OpenGL, so looking for COLLADA compatibility, but have an eye on Microsoft platforms (hence also tagging this question with DirectX) & am working towards a system capable of integrating both with little or no changes to my codebase. From your answer; params should be split between materials & effects, & that a material has a (i.e. containment) effect & any textures... – codey Apr 9 '12 at 11:40
...(material has-a shared/shareable effect & shared/shareable textures) – codey Apr 9 '12 at 12:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.