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

A single colour definition, consisting of individual ambient, diffuse, emissive, and specular components.

Generally speaking, to determine the colour of an object illuminated by a light source X, combine

add any intensity due to the <Emissive Colour> (which isn't affected by X.)

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> of a computer monitor, placed on top of a <Geometry Model Instance> of a desk. A <Positional Light> 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> within the desk <Model> has an <Inline Colour> component, which in turn has a < Primitive Colour> with both an <Ambient Colour> and a <Diffuse Colour> component. Due to the <Diffuse Colour> component, the area of the desk under the monitor that's visible to the observer appears to be in shadow. However, the shadowy area is not totally blacked out, because the <Ambient Colour> simulates the effect due to light reflected from the walls, ceiling, and so on that would reach that area.

  2. Consider a <Line> used to simulate a line of runway lights. The <Line>'s <Colour> would resolve to a <Primitive Colour> consisting primarily (possibly completely) of an <Emissive Colour>, since the <Line> is pretending to emit light.

  3. Consider a collection of <Polygons> used to represent the surface of a sunlit lake. These <Polygons>' <Colours> resolve to <Primitive Colours> consisting of <Ambient Colour>, <Diffuse Colour>, and <Specular Colour> components.
    The <Ambient Colour> prevents any <Polygons> in shadow from appearing black, while the <Diffuse Colour> 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 SEDRIS use the OpenGL lighting model?

No, although the terminology is similar. SEDRIS 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 in SEDRIS?

The question has eliminated any concerns about <Emissive Colour> and <Specular Colour> components -- the <Primitive Colours> won't have them. Having said that, the data provider is down to 2 choices -- <Ambient Colour> and <Diffuse Colour>. Here is a simplified description of the effects each will provide (i.e., considering only 1 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> can have both an <Ambient Colour> and a <Diffuse Colour> component. This indicates that even if part of the object is in shadow, it is still somewhat visible. See example #1.


Where are the RGB values in all this?!?
Each of the components of <Primitive Colour> has, in turn, a <Colour Data> component, which is either an <RGB Colour>, an <HSV Colour>, or a <CMY Colour>, depending on which colour model is being used.

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

Constraints

None.

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.

Last updated: October 1, 2002 Copyright © 2002 SEDRIS™