Remove vec3::write_color as member function, change to helper function

[lgritz]

I think there is merit in making vec3 be a strict subset of functionality provided by nearly every other linear algebra package and the analogous classes built into various graphics languages and toolkits. This would allow users to easily substitute an alternate implementation that they might prefer -- one they are already using in other projects, or one in common use at their company, or one they previously wrote themselves.

There are currently a few minor impediments to this in the class as presented: the write_color(std::ostream &out) method, and later the vec3::random() methods. Those can perhaps be moved out of the vec3 class and into standalone functions.

[hollasch]

We've strayed a bit from Peter's original intent of providing code only as a supplement to teaching the material. Eventually we caved in and added a general build setup and fleshed out the code. It helps as a proof that the code is consistently error-free and hangs together. It also provides an example implementation with results that are likely good.

Still, the intent of the books is to get readers to write their own ray tracer from scratch, rather than building on the book's implementation. We've made improvements as we've gone, but usually only where they simplify or help understanding. It's a fine line — the more work we put into the code, the more tempted readers are to actually use it, counter to the original goals of the series. Past writers have taken to intentionally leaving out chunks of code to force readers to start bending things to their own purposes, but in many cases, code is a more eloquent algorithmic language than English.

I'm rambling, but thought the background helpful. In this instance, the vec3 class is really a 3-tuple class, which is used variously throughout the codebase to represent vectors, points, colors, or anything else that needs three real values. One could imagine additional methods like transformAsPoint, transformAsVector, applySaturation(), or even computePlaneDistance(). We're also walking a tight line when it comes to C++ variant (we've only dipped our toes into C++11, and after much debate), cognizant of many readers who are not as conversant with C++. It's not how I'd write my own actual ray tracer, but it certainly keeps the examples simple and the code base small.

[lgritz]

I like that the book's vec3 is a minimal 3-tuple utility class. I'm just suggesting to stick to that by moving a couple odd things out of the class definition. That has the added benefit of making it easy to substitute any of a wide range of other vec3 implementations, which can be desirable for some people.

Also, I like very much that the examples use very few C++ features, nothing fancy. It's a big aid to people who are simultaneously dipping their toes into ray tracing and also C++ for the the first time. C++11 is probably the right place to aim.

[hollasch]

Admit it, you have ulterior motives for this. :) I'm guessing you have a library you want to use that you have in mind. write_color() doesn't strike me as that much out of place than length(), or the lack of a tuple-like operator*. But still, I can't put up much fight against the fact that write_color() is an odd duck in the current set of methods. Worse, it has the side effect of mutating out NaN's to 0.0 (which was a mistake in retrospect). Finally, I can't mount much of a defense that there's some great benefit to making this a member function.

Changing the code isn't much work, but I'll need to make sure the text is updated properly. Don't know if I can get this in by tomorrow's release, but I'll take a look at it.

[lgritz]

Oh sheesh, it's just a long-term suggestion. No need to jump.

[hollasch]

:D I'm just pulling your leg. Working on it next...