I’ve been having some very bad back pain today, and so today took some time off from work and class (it was the first day today!) to lay in bed and work on finishing up version 0.8 of BRayTracer.
I’m very proud of the improvements I’ve made to the latest version. Usability has been increased significantly and there are probably over a hundred bug fixes.
As always, feedback is appreciated. Check out the BRayTracer page to learn more and download a copy.
I’d been hearing about this thing called NUnit for the past 6 months, and finally two months or so ago I decided to see what all the hoopla is about.
NUnit is a .Net version of the original JUnit unit-testing package for Java. The newest version has a very strong .Net feel with its use of attributes to control testing.
I decided to start using NUnit in my BRayTracer project. Immediately, I was faced with some issues (not problems, just things I needed to decide).
The first is that NUnit works by creating classes that contain methods which have the TestAttribute applied to them. This allows NUnit to find all of the testing code given a module or project.
I could either put this testing code into the same module as the existing code, or I could break my ray tracing code into a separate module. I didn’t want the testing code to bulk up my executable size (which can in some instances translate to slower code due to paging and locality issues). I decided to break my ray tracing code out into a separate module (I was planning on doing this eventually anyway).
Done with the housekeeping, I began setting up my tests.
So far, I’ve implemented about 150 unit tests covering a few my objects. It’s not totally comprehensive yet, but it’s a good start. Effectively testing the entire rendering process will require thousands of tests.
So far, the tests have helped me fix about 10 serious bugs that I had otherwise missed. The regressions testing is helping a lot, since the code is still in a lot of flux.
I’ve been making a strong effort to write all (most) the tests before I write the code they’re supposed to verify. This definitely makes testing more enjoyable, and more likely to get done.
I’ve been thinking about how to use inheritance and polymorphism to my advantage in these unit tests. I have a Shape object and numerous subclasses (Box, Sphere, etc.). I initially had a few abstract functions in Shape to test basic functionality of all shapes, but I found that this isn’t really buying me
much. So much code has to be taylored to the individual classes that inheritance is helping in that way. More analysis will be needed.
Another aspect of using NUnit is that I’m finding myself needing the debugger less and less. It’s now possible to narrow down problems very quickly with such focused tests. This translates to quicker development.
So far, so good… I’m converted.
I’ve almost finished version 0.7 of my ray tracer. Here’s the (mostly complete) list of things I’ve worked on. Only two more to go!Version: 0.7
Todo:
DONE get rid of Clone()
DONE fix cone inversion bug
DONE rendering changes property selection
Bugs:
DONE polygons should be double-sided if wanted, to stop light
DONE make RayTraceSettings static, and accessible all over–update objects to use epsilons
DONE cone doesn’t work appropriately for non-zero top radius
DONE something wrong with cone/cyl.
DONE backside normals of discs/polygons wrong?
DONE polygon meshes need to be completely refactored.
Features:
DONE add matrix
DONE add transformation base
DONE add transformation stack functionality
DONE cone
* let camera look at a specific point
* translucent materials
Enhancements:
DONE custom type converters to edit vertices, colors as strings