Material Design

From K-3D

Overview

This article provides technical details on working with materials ... see Render Models for important background.

• Materials can be assigned to geometric primitives on a per-curve-group, per-patch, per-face, etc. basis.
• Each geometric primitive container provides a dedicated array of imaterial pointers for this purpose.
• Thus, each curve-group, patch, face, etc. can have exactly zero-or-one material assigned.
• To allow for assignment of multiple materials in scenes that support more-than-one render model, a MultiMaterial object can be assigned in-lieu-of a "normal" material. A MultiMaterial can contain zero-to-many user properties of type "imaterial*", allowing the MultiMaterial to act as the "root" of a "tree" of material objects.
• Note: the limitation of one-material-per-gprim is mainly historical, and could be eliminated in the future.
• The k3d::imaterial interface is implemented by all material nodes, see Material Plugins for a list.
• Because there is virtually no overlap in material features among different Render Models, k3d::imaterial is an intentionally empty "placeholder".
• There are render-model-specific material interfaces, including k3d::gl::imaterial, k3d::ri::imaterial, and k3d::yafray::imaterial. These are called by their respective render engines at render-time, and should be considered internal implementation details. Note: these interfaces might be eliminated entirely in the future, or they might be expanded to access properties of their respective materials.
• To extract information about a geometric primitive's material you would:
  • Retrieve the imaterial* for that primitive. Handle a possible NULL pointer.
  • Use dynamic_cast to convert the material to an inode*. Handle a possible NULL pointer.
  • Test the node's factory name or id to see if it is a MultiMaterial.
    • If it is, iterate over the node's user properties to and recursively repeat this process.
  • If the node is some other known material type, read/write its material properties using the property API.
    • Note that a material node may reference other nodes to implement its behavior. For example, a RenderManMaterial will contain properties that link to shader nodes such as RenderManSurfaceShader. In-turn, those shader nodes may have properties that link to texture nodes such as RenderManTextureMap.