Nick's Design Study
Contents |
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:
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.
