raytracer implementation: object hierarchy?

raytracer implementation: object hierarchy?

Post by Michaelang » Wed, 21 Jul 2004 07:09:28


Hello

I've finally gotten around to writing a working basic ray tracer, and
finding it's turning out to be a fun little project!
(Especially when you need to debug why your test scene isn't matching
up with what you expect, or why it differs from what POV-Ray spits out
based on the same scene description. :)

Anyways, I have a question about the design of the raytracer object
heirarchy.

Currently, I have these types (classes):
- Vector, Matrix, Ray, Color
- Material
- Lights
- Base Object (BoundingVolume is by composition, but currently
unused), Sphere, etc.
- RasterImage
- Camera

The base object, does double duty:

1. It serves as the scene graph's root node (has a linked list of all
the child objects)

2. All the native primitive objects (sphere, trianble, box, etc)
derive and over-ride the behaviour of the base object (they are
virtual C++ member functions.)
i.e. CheckIntersection(), GetColor(), etc


I'd like to implement a "real" heirarchy (bounding spheres, or
octrees), and support CSG, but I am not sure of the relationship of
the whole object heirarchy that I need, or if the one I have will do
the job.

Q. How should the class relationship be structed?
Do I want:
Scene.Trace( Camera, Ray, Raster )
or
Camera.Trace( Ray, Scene, Raster )


Q. How should I handle CSG? Would each object have a list of CSG
objects, along with the type of operation (union, merge, intersection,
difference)? What classes need are to be inheritied, composition, and
as passed as paramters?

I don't want to look at the POV-Ray source yet, until I had seen/read
about a few different approaches, to see the pros/cons of each layout,
before getting locked into an implementation.

TIA & Cheers