The SEDRIS Data Representation Model
APPENDIX A - Classes
Primitive Colour

Class Name: Primitive Colour

Superclass - <SEDRIS Abstract Base>

Subclasses

This DRM class is concrete and has no subclasses.

Definition

An instance of this DRM class specifies a single colour, consisting of individual ambient, diffuse, emissive, and specular components. See 4.15.3 Colours and lighting of ISO/IEC 18023-1.

Primary Page in DRM Diagram:

Secondary Pages in DRM Diagram:

This class appears on only one page of the DRM class diagram.

Example

  1. Consider a <Geometry Model Instance> instance of a computer monitor, placed on top of a <Geometry Model Instance> instance of a desk. A <Positional Light> instance affecting the two objects is located so that the illumination is directed from above. Assume that these instances are present within an environment simulating an ordinary room.

    Each <Polygon> instance within the desk <Model> instance has an <Inline Colour> component, which in turn has a <Primitive Colour> component with both an <Ambient Colour> component and a <Diffuse Colour> component. Due to the <Diffuse Colour> component, the area of the desk under the monitor that is visible to the observer appears to be in shadow. However, the shadowy area is not totally blacked out because the <Ambient Colour> instance simulates the effect due to light reflected from the other parts of the environment (e.g., walls, ceiling, and other objects) that reach that area.

  2. Consider a <Line> instance used to simulate a line of runway lights. The <Colour> component of the <Line> instance resolves to a <Primitive Colour> instance consisting primarily (possibly completely) of an <Emissive Colour> instance since the <Line> instance is pretending to emit light.

  3. Consider a collection of <Polygon> instances used to represent the surface of a sunlit lake. The <Colour> components of these <Polygon> instances resolve to <Primitive Colour> instances, each of which consists of an <Ambient Colour> component, a <Diffuse Colour> component, and a <Specular Colour> component.

    The <Ambient Colour> component prevents any <Polygon> instances in shadow from appearing black, while the <Diffuse Colour> component provides most of the normal appearance of a lit object. However, since water is a reflective substance, its colour requires a <Specular Colour> component to simulate light reflected from the water.

FAQs

Does the DRM use the OpenGL lighting model?

No, although the terminology is similar. The DRM handles transparency somewhat differently than OpenGL does, among other things. For a description of the OpenGL lighting model, see [OPENGL], Chapter 5 "Lighting".

Consider a data provider with a very simple illumination model, with no objects that glow in the dark or otherwise emit light, and no reflections. How is this represented using the DRM?

The question has eliminated any concerns about <Emissive Colour> components and <Specular Colour> components -- the <Primitive Colour> instances will not have them. Having said that, the data provider is down to two choices -- <Ambient Colour> and <Diffuse Colour>. Here is a simplified description of the effects each will provide (i.e., considering only one light source).

<Ambient Colour> is independent of the positions of either the light source or the observer. That is, an object with only <Ambient Colour> appears uniformly lit across its surface, regardless of where the light source is or where the observer is. (This can create a very artificial-looking effect, since it distorts some of the visual cues that provide depth perception.)

<Diffuse Colour>, on the other hand, depends on the angle of the lit object to the light source (although not on the observer's position). An object with only <Diffuse Colour> will appear to be lighted on the side facing the light source, while the opposite side will be in shadow. The effect is consistent with the visual cues used to determine shape-from-shading in various image analysis methods.

Note that a <Primitive Colour> instance can have both an <Ambient Colour> component and a <Diffuse Colour> component. This indicates that even if part of the environmental object being represented is in shadow, it is still somewhat visible. See example #1.

Where are the RGB values in all this?!?

Each of the components of a <Primitive Colour> instance has, in turn, a <Colour Data> component, which is either an <RGB Colour> instance, an <HSV Colour> instance, or a <CMY Colour> instance, depending on which colour model is being used.

Why do <Colour Table> instances have <Primitive Colour> components instead of <Inline Colour> components?

<Colour Table> instances used to be composed of <Inline Colour> instances, but problems arose since both <Colour Index> and <Inline Colour> instances can have <Translucency> components. When a <Colour Index> instance that has a <Translucency> component refers to an entry in a <Colour Table> instance, the interpretation is clearer if the <Colour Table> instance's entry cannot specify any additional <Translucency> instances. Consequently, <Primitive Colour> exists so that "just the colour" can be put into a <Colour Table> instance.

Constraints

Composed of (two-way)

Component of (two-way)

Inherited Field Elements

This class has no inherited field elements.
Prev: Presentation Domain. Next: Primitive Feature. Up:Index.