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.