Nick's Design Study

Revision as of 02:11, 15 September 2010

What is A Ray Tracer

A ray tracer is a program the produces pre-rendered CGI. This type of program is used by movie studios to create the effects in a large number of movies. Some examples are Autodesk's Maya and 3ds Max. These suits are available for free; Blender and TrueSpace. In a rendering system the virtual representation of objects in a scene are stored in memory. A ray tracer can generate an image creating a 'ray' for each pixel (for anti-aliasing more than one ray is sent per pixel). The ray is tested to see if it intersects with any scene object, if it does then the color of the pixel becomes the color of the objects surface. The color is modified by lighting and other scene effects.

Ray Tracer Project

Last year in Cosc 363 the first assignment was a ray tracer. I fairly enjoyed this project, despite some of the hair-ripping hurdles involved. It was also a very good introduction into the use of vector maths for me. Although I had some problems that I couldn't fix, I did get some very neat features to work. Such as reflection and refraction. It was a good feeling to build something, basically from the ground, that had been a marvel and a mystery to me for so long. I got it to work but it wasn't pretty. The OO's structures are not very nice, and there is a high chance that I committed a litany of bad design offences. Also Python is not the most efficient of platforms for something this computationally dependent.

Original Python Design

There are a number of aspects of this that seems to just plain smell bad. There is a God class (RayCaster). This class organizes all the scene elements, and controls the ray casting and writing to screen/ files. Also the use of Interfaces is bad/broken. I feel the material part could be much better, more in-depth and flexible. Surfaces such as Sphere and Plane should have their own interface, and perhaps there should be an interface for scene objects.

Here are some specific maxims that are violated:

Maxims

Behavioral completeness

The primary violation that jumps at me is that a large portion of behavior that should be done by the Material interface (as it is directly related to the properties of the specific material).

An example in the code can be seen in the "RayCaster" class in the method "getColourForRay()":

if surface.transperency < 1:

pointLights = lightsAt(ray,hitPoint)

if surface.reflection > 0 and surface.reflection is not None:

reflexPix = getReflectionColour(obj, ray, hitPoint,depth)

else: reflexPix = Colour(0,0,0)

if surface.refraction > 0 and surface.refraction is not None:

refractPix = getRefractionColour(obj, ray, hitPoint,depth)

else: refractPix = Colour(0,0,0)

(the different RGB values are then combined)

This is essentially a switch statement that largely varies the behavior biased on the materials properties (such as transparency reflection and refraction) instead these should be properties addressed in different concrete implementations of material. The methods called are all part of the same class, RayCaster. They should be more connected to material. This is one major issue with the structure, for recursive ray events, such as reflection, the material must be combined with that of new rays cast back into the scene. In this way if the majoryity of operations ascosated with material was within the class it would still have to know about the scene, and be able to cast new rays into it. Since lighting is also used in material colouring materials in this model must also know about lights. This would probably be incorpirated into the interface of the scene class, since lights are part of the scene.

I feel this is somehow malodorous, but it dose seem that to some degree in the real world surfaces can 'see' the scene and the lights around them.

Open closed principle

This design is very difficult to extend, since the structure of the ray casting method is intrinsically linked to the behavior of each supported material. Surfaces in this design suffer from this less, but since all surfaces have materials, in fact need them to become visible, thus these two structures are both equally required. RayCaster (and also scene) should not need to be modified to add new types of material, lights and surfaces. This is also a violation of 'Program to the interface not the implementation' maxim since RayCaster is not aptly set up to deal only with the material and surface interfaces.

Switch Statement Smell

Because the most of the functionality of materials lights and ray functions were all dealt with inside the class RayCaster, the code inside contained several switches biased on type alone. I.e if a materiel was a reflective one, a different part of the code is executed in RayCaster.

Anti-patterns

God Object

In this case the RayCaster class has far to much functionality for a single class, some of this should be delegated to other classes.

Issue summary

It suffices to say that this design has a certain inelegance that is reflected by the above problems. There is a wide area for improvement and I'm going to attempt to design a system that is easy to use and extend by programmers. To do this I need to make a system that is programmed to a set of central interfaces, ones that represent the various different components of the ray casting model. I'm going to keep this ideal at the forefront as I develop my system.

System Proposal 1

Overall System outline

This shows the relationship between the scene object and the various different interfaces and primitive types. For each of the packages intended for extension there is a central class interface and a factory interface. This is to simplify and unify the way in which the scene class creates and maintains collections of scene objects. The scene object will have collections both of each type of object and of each factory type. In this way the library can be extended to include new objects. Also developers can write their own implementation of the factory and their own custom objects, and pass an instance of the factory to the scene. Then objects of any type can be created using a control string such as:

"Material Phong phongmat1 (255,0,0) (25,0,0) (255,255,255)"

or:

"Surface Plane plane1 (0,0,0) (0,1,0)"

This can also be used to deliver instuctions to the scene such as;

"Transform Rotate plane1 (1,0,0)"

or:

"Disable light1"

"Enable light1"

"Toggle light1"

Illuminator

this describes the Illuminator and the IlluminatorFactory interfaces.

Renderable

this describes the Renderable and the RenderableFactory interfaces.

Material

this describes the Material and the MaterialFactory interface.

Basic Data Structures

this describes the Basic Data Structures, and the Transformable and the Transformation interfaces.

Information Flow of System

this describes the information flow within the system.

System UML

Here is A UML showing the interaction between the Scene class and the various extendable interfaces and the core classes (on the left) such as point and vector.

-Nick Molhoek