|
|
Of Cameras And Scenes |
Good software engineering requires definition of scope. Object-oriented design introduces object abstraction to assist in clarifying that scope. When defining an abstract object, the software engineer can assign a name to the software module, which represents a definition found in a dictionary. This moves the software module from being a nebuluos set of keystrokes written by a programmer to a concrete piece of information that communicates its specific role in the software through clear language. Language is the best form of communication between humans who must learn about the software.
The name of the software module may be either arrived at inductively, if the engineer is already aware of the type of operation it will perform and has a name already in mind, or deductively if the object's role must first be described before a suitable name can be assigned.
Regardless of the method, attributes and behavior must be clearly defined to limit the software module's scope. Why is it important to limit scope? Because its purpose in the software must be communicated between humans who will use language to describe it. When the module violates scope its purpose becomes, once again nebulous, hard to document, hard to communicate about.
Object oriented design provides us with two simple questions to ask when describing attributes and behavior of a software module:
If the name has been arrived at inductively, we can use the dictionary to describe What is it?. We then add the common experience associated with the real-world object to describe What does it << the software>> do?
Does this seem like child's play? Good. Because I don't like complicated forms of communication. And now, what does this have to do with the title Of Cameras and Scenes? I'm glad you asked. Read on.
One of the more misunderstood terms in 3D graphics programming is the term Scene Graph. This is unfortunate, because the composite of the two words Scene and Graph describe quite well What it is. Merriam-Webster on-line defines Graph as follows:
Main Entry:
Pronunciation: 'graf
Function: noun
Etymology: short for graphic formula
- : the collection of all points whose coordinates satisfy a given relation (as a function)
- : a diagram (as a series of one or more points, lines, line segments, curves, or areas) that represents the variation of a variable in comparison with that of one or more other variables
It is really the second entry that we are interested in here. More specifically the graph is a tree structure that can be traversed in a Directed, acyclic manner. Actually, this part of the definition is fairly well accepted.
The term Scene, however is used as an adjective (by method of order and grammer), that describes more that this graph has the specific role of describing and behaving like a scene.
Good. So, what is a Scene? and what does a Scene do?. Dictionary.com this time:
scene Audio pronunciation of "scene" ( P ) Pronunciation Key (sn)
- Something seen by a viewer; a view or prospect.
- The place where an action or event occurs: the scene of the crime.
- The place in which the action of a play, movie, novel, or other narrative occurs; a setting.
- A subdivision of an act in a dramatic presentation in which the setting is fixed and the time continuous.
- A shot or series of shots in a movie constituting a unit of continuous related action.
- The scenery and properties for a dramatic presentation.
- A theater stage.
- A real or fictitious episode, especially when described.
- A public display of passion or temper: tried not to make a scene.
- A sphere of activity: observers of the political scene.
- Slang. A situation or set of circumstances: a bad scene; a wild scene.
By context, our usage does not really include things to do with theatrics, but this is a good one to base our software abstract object on: Something seen by a viewer; a view or prospect. (Although it is a little general). Some specific attributes could be ascribed:
What does a Scene do?. Here's a probable list based on common experience:
Now, it should be noted that object oriented design allows for software modules to be composites of other software modules. In fact, it is this heirarchy of composite objects that allows us to encapsulate and hide complexity therefore simplifying usage.
But the rule of supporting the parent object in its scope limitations must be followed, or the parent object's role becomes nebulous. In the case of the Scene Graph, those modules that make up the parts of the whole must support the purpose of Something to be seen by a viewer both in attribute and behavior. If it helps the scene move, the lights and colors change, it is part of the scene. If it doesn't it is not.
The second, often misunderstood software module, commonly used in 3D graphics is the Camera. The concept was possibly introduced by the OpenGL text book under a section titled The Camera Analogy. This section describes OpenGL viewing transforms, model transforms, projection transforms, and viewport projections. These concepts are beautifully and clearly explained by use of a real-world object, a camera, which the reader can relate to, using language to describe the process. Each step in preparing to render a scene in a computer program, is described as an operation with the camera or the scene:
| OpenGL term | OpenGL operation | Analogous camera operation |
| Viewing Transform | Position the viewing volume in the virtual world | Place the camera on a tripod, or hold it at a position and attitude in the world |
| Model Transform | Position models in the virtual world | Move the models to be included in the picture to their respective positions in the scene |
| Projection Transform | Determine the shape of the viewing volume | Adjust the lens to determine the amount of the scene you want to capture in the picture |
| Viewport | Determine the rectangular size on the computer screen of the final projected image | Film cameras: Adjust the dark-room enlarger to project the size of the image on the exposure paper Digital Cameras: Adjust the size of the rectangular image on the monitor. |
Naturally, the object oriented designer will immediately identify an object that can be named. The object has attributes and behavior:
What is it?
From dictionary.com:
An apparatus for taking photographs, generally consisting of a lightproof enclosure having an aperture with a shuttered lens through which the image of an object is focused and recorded on a photosensitive film or plate.
A Camera's attributes include:
What does it do?
Intersetingly, camera objects are quite commonly used for most 3D graphics rendering packages. Also, interesting, however, is the fact that most common definitions of camera do not include its ability to take the picture, nor provide the camera with film, a plate, or framebuffer to record the image. This author would ascribe the term Scope to these types of "cameras". A Scope by definition is "A viewing instrument such as a periscope, microscope, or telescope." (dictionary.com).
This article may have well been entitled Why Cameras don't belong in the Scene Graph, because, that is the real point being made. Many (most) scene graph implementations include some kind of Camera that is placed as node on the graph. The common reason for this is the temptation to be able to ascribe motion to the camera, in the same way that motion is ascribed to models in the 3D view.
But note that the definition for Scene above: "Something seen by a viewer, includes the user of a viewer to assist in the definition. Our camera fits well the role of the viewer as it is exactly what its role is: to view the scene. But it is not part of the scene. A scene describes a virtual world, the camera captures it. Both objects have distinct and separate roles in the real world, and so, must also have distinct and seperate roles in object oriented design and ensuing implementation.
By definition, the camera cannot be in the scene. It does not contribute to the attributes or the behavior of the scene, so it cannot, therefore be in part of the Scene Graph object definition.
It could be argued that having the camera in the scene graph, while breaking scope, provides enough useful functionality so as to deem it a worthwhile exception to scope limitation. But, this approach places software implementation priorities before software design priorities. When this occurs, design becomes obfuscated, and when this occurs, communication about the software module becomes nebulous.
As a programmer, ask yourself how many ways you could implement any given task. If you are worth your salt, you should be able to arrive at multiple methods. This concept alone is enough to demonstrate that implementation follows design. One must design, define, limit scope, then implement according to those guidelines. Design, which somehow "emerges" from implementation is limited to that implementation. Well designed software with limited scope is easy to explain, to learn, to document.
The software project Producer attempts to define Cameras and Scenes as described here. Producer does not include any facility for rendering scenes, but provides for Camera management and is specifically designed for real-time applications. It further treats the abstract concept of the camera as a computational unit that can run as an independent thread. This fits the What is it?/What does it do? approach for defining an software module, in that multiple real-world cameras can run in parallel, either indepenently, or synchronized together. As an independent computational unit a Camera becomes a much more powerful tool than as a passive, misplaced node on a Scene Graph.
And that's all I have to say about that. - Forrest Gump -
