Raytracer development working through the book The Ray Tracer Challenge
- Implement scene management
- Procedurally generate some shapes
- Refactor shape and intersection files
- Improve gradient to transition smoothly after x=1
- Nested patterns - Patterns should be provided other patterns. Only solid color pattern takes a color.
- Refactor color to be simple struct ?
- resolution as commandline params
- Implement cones
- Improve float_equals to handle zero ?
- Rewrite gethit using lower_bound ?
- Add doxygen comments
- Refactor cmake and folders to be cleaner ?
- Implment other point/vector functions/tests. Try and tidy up operators again (VECTOR-VECTOR) ?
- Rework using slices....
- Canvas as a template
- Provide pattern copy template to refactor away clone member function
- Refactor tuples/vectors/points.
The project uses cmake Basic build would look like
mkdir build
cd build
cmake <path to source>
make
If you have downloaded gtest then you can point cmake at it so that you do not need to redownloade/build it using
mkdir build
cd build
cmake -DGTEST_ROOT=<path to gtest install> <path to source>
make
Currently the lighting calculation is a stand alone function in the light module. Perhaps will need to be turned into class or similar?
So now that we have triangles we can handle more arbitraty shapes, but these are also more complex using many triangles which can really hit performance. Next step it likely to do some optimisations of the algorithm to improve this. Most common seems to be k-d tree bounding box. Basic concept is that we have a binary tree of bounding boxes, which can be searched. To traverse the tree we recurse into it by calling a hit function for that node. This will check if the bounding box has been hit, if not then that search path is terminated. If it is hit then it checks the left and right paths and returns the closest of these. Primatives (triangles etc), are terminal nodes.
The trick to this working well is how the tree is constructed. Figuring out the optimum method is an area of ongoing research. One relatively simply technique is to pick an axis in a round robin fashion and create the split at the median position along that axis.
Fixed and issue where we were recomputing the world-transform for each object, which meant that the cached inverse wasn't being used. This in combination with the kd-trees gives pretty good performance. The updated reflective teapot render takes ~16s to render with 4.1 seconds to create the kd-trees structure
Init world
Init World took 4.132751s
Begin Rendering
Pixels done: 781497 99%
Rendering took 16.341550s
real 0m20.644s
user 2m8.072s
sys 0m0.877s