Nick's Design Study

Revision as of 03:20, 30 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 3D Studio Max. These suites are freely available; Blender and TrueSpace. In a rendering system the virtual representations of objects in a scene are stored in memory. A ray tracer can generate an image by 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. If the ray doesn't collide with any object, it is set as the background colour.

Ray Tracer Project

Last year in Cosc 363 (computer graphics) the first assignment was to program a ray tracer in python. 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. Allthough I got it to work, it wasn't pretty. The OO's structures were 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

In this diagram links from many classes to utility classes (Point3, Vector3, Ray and Color) have been omited to highlight the key relationships.

There are a number of aspects of this that seems to just plain smell bad. Also the use of Interfaces is not coherent. Here Material class is not an Interface, but a concrete class that is extended. RayCaster doesn't use the Light interface, instead linking to the concrete classes that implement light.

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). This is a violation of the maxium Behavioral completeness since the classes do not contain their complete behaviour. An example in the code can be seen in the "RayCaster" class in the method "getColourForRay()":

'surface' is an instance of Material

surface = getSurface(obj.material,hitPoint)

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)

...

res = surface.litColour(obj.normal(hitPoint), AMBIENT, ray.dir,

pointLights, reflectionPixel =reflexPix,refractionPixel = refractPix)

(the different RGB values are finally combined in the materials litColour method)

This is essentially a switch statement that largely varies the behavior based on the materials properties (such as transparency reflection and refraction), this behavior belongs in different concrete implementations of material. The methods called are all part of the same class, RayCaster. They should be part of the material class. There is an issue that arises from putting this functionality in the material class, 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. So there is a trade-off here, between not having cyclic dependency and supporting operations involved in ray casting events like reflection and refraction. Since these two are available in even the most basic ray tracer, and produce some of the ray tracers best effects , they can't be left out.

Keep related data and behavior in one place

This design doesnt subscribe to Riel's Heuristic Keep related data and behavior in one place, since behaviour that should be in the meterial class is in the rayCaster class.

Feature Envy smell

The rayCaster is doing work that should be in other classes. For example the method getReflectionColour(object, ray, point, depth), should be in material since the Reflection is a property of the meterial. this is an example of feature envy.

Tell Don't Ask

A related issue the RayCaster is asking details of the meterial and then preforming work and passing using the result in another call to material ( res = surface.litColour(..., reflexPix, refractPix ) ). RayCaster should tell the material to render a surface point, then retreive the result. Operations like reflection and refraction should be done inside the material classes methods. this is an example of violating the maxum tell, don't ask.

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' prnicple 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. This is knowen as switch statement smell.

Law of Demeter

The law of demeter says that you shouldn't be getting objects from other objects and calling their methods. From within method M object O you should only be calling the methods of O, methods of objects created within M, and all the objects that are components of O directly. In the getColourFor Ray() method for example the RayCaster object is getting the surface (surface = getSurface(obj.material,hitPoint)) and then calling methods on this. This is an example of a violation of the law of demeter in the code.

God Object

There is a God class (RayCaster). This class organizes all the scene elements, and controls the ray casting and writing to screen/ files. The class has far to much functionality for a single class, some of this should be delegated to other classes.

Program to the interface not the implementation

Perhaps the bigest problem this design has is that it breaks the program to the interface not the implementation prinicple. The RayCaster has be dasigned to cope with specific concrete class implementations and not stable abstractions.

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. 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 Stable Abstractions, 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

again the links between the complex classes and This shows the relationship between the scene object and the various different interfaces, implementations, 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 (35, 1,0,0)"

or:

"Disable light1"

"Enable light1"

"Toggle light1"

Information Flow of System

This describes the information exchange required for a single ray tracing event within the system.

Issues

In this design several of the interfaces are redundant, namely Surface and Light. There is no need for both the Light and the Illuinator classes only one high level abstraction should be provided. Similarly there is no need for both the Surface and the Rendering classes. This is a violation of riel's huristic Minimal Public Interface. In the system there is no specific depiction of the ray tracing program, I.e Raycaster disappeared. There should be some example of the central application, even if it is intended to be overwritten.

System Proposal 2

Once again the links between low level classes (Point, Vector, Ray, RGB and HTransformationMatrix) and higher level classes have been omitted in the interest of clarity. It should be sufficient to say that most classes have dependency on at least one of these primitive classes.

Here is another iteration of the design. Some of the issues have been addressed are:

* The unessicary interfaces (Light and Surface) were removed.
* A class was added that actually created a scene and rendered it.
* The interface for transformations was beter defined.
* The interactions and relationships of the low-level classes (Point, Vector and, Ray) are more well defined.
* Scene is still abstraced from any concrete implementations.

Have I fixed all of the problems that I identified in the orginal design?

It could be argued that the scene object has replaced rayCaster as the new God object, But I do not agree. Although scene has more methods than most of the other classes, most of these are getters and setters, a large part of the workload has been delegated to other classes. There are now a set of stable abstractions that makes the system open for extension but closed for modification. This adresses the majority of issues described above.

Have other issues been introduced?

There is some concern over the coupling between Material and Scene, but this is a nessicary trade-off to achive refective and other effects.

-Nick Molhoek