pi is available as M_PI in <cmath>

[f35f22fan]

Hi, In "Ray tracing in one weekend" you defined pi: const double pi = 3.1415926535897932385; but it's available in as M_PI on both windows and Linux:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/math-constants?view=msvc-160

[hollasch]

M_PI is not part of the C/C++ standard. Some compilers provide it under some conditions, but they vary from compiler to compiler. For example, when using GCC, you must define STRICT_ANSI in some situations. With glibc on Red Hat, you have to define USE_GNU and cannot use std=c99. Another value is guarded by `defined USE_BSD || defined __USE_XOPEN`.

Anyway, defining it clearly in one line above is much simpler for all implementations and all languages. In your own implementation, use whichever approach suits you best.

[f35f22fan]

Thanks, I don't use Red Hat or older compilers so I didn't know, sorry about that.

Since you replied I'd like to quickly share my opinion. TL;DR: I think 99.9% of the attention should be paid to explaining the math as if the reader was a total newbie, rather than explaining the programming as if the reader was a total newbie.

I think there are (far) more programmers who wanna program ray tracing than mathematicians who wanna learn programming to program ray tracing. I'm saying this cause I was surprised that such an advanced (to me) math topic is written in C++ as if it was written by a newbie - no namespaces used, class names all lower case.. stuffing as much as possible into headers.. while certain math steps are skipped expecting that the reader knows enough math to know what's in between, while explaining what a C++ vector is which one learns almost on day one of C++ programming. Last time I learned math was 20 years ago in school.

[trevordblack]

Can you point to specific math examples that are skipped in a way that you think is problematic? We skip over a lot of math because this isn't a math textbook. The people who understand the math are going to get bored by reading through stuff they already know. And the people who don't quite understand the math aren't going to grok it in a weekend.

The codebase is designed to be rewritten in whatever language or shader you want to use. We try to avoid using c++-isms.

In truth, we treat the reader as both a newbie to programming and a newbie to math.

[hollasch]

Yes, we're acutely aware of this. For v4 we're hoping to write more of an explanation behind the philosophy, as a lot of folks come into this not realizing the spectrum of the target audience.

Basically, consider the fact that many reading this material are not C/C++ programmers, but instead Java programmers, JavaScript programmers, or programmers in some other language. Given this, we try to use as few constructs specific to C++ as possible, so the reader doesn't have to learn raytracing and C++ at the same time.

When we picked up from v1, there was the book only, and the code was incomplete (by design). As a bonus, the first thing we did was type up all of the code snippets so the reader could modify and organize these as they wished. We explicitly left the code incomplete. Eventually, we did flesh out the example code to include a whole program, but avoided any sort of build system, because we didn't want readers to learn raytracing and C++ and some arbitrary build system.

Then we yielded on that, because it was just too easy for us to modify code and screw things up if we never even compiled and ran it. Eventually we released it with CMake, because that's at least kind of cross system, and because it's useful. We still get complaints about the program design or the language choice or idiom or the program features, because it's so easy to see this as a proper program. But it's not. After all this, the original intent is still the same: you should write your ray tracer in your language for your system in your build environment to run on your machine. If I was writing this for myself, I'd start with useful command-line arguments, definitions would go in .cpp files, declarations in headers, namespaces galore, better use of standard iterators and containers. Heck, right now I'd be playing with the new ranges, modules, string formatters and so forth (very excited to play with this in my other projects). Yet in this project, all of that would be noise, and drag for the person just trying to understand how ray tracers works and how data flows through the system.

Regarding math concepts, I'd echo @trevordblack above — it's so easy to lightly toss out a concept you've had ground into your neurons, without realizing that it's not trivially obvious to those who haven't seen it before. I'm talking about simple things like vectors, cross products, dot products, how you can use these, as well as advanced concepts. Specific examples of mathematical concepts that you feel deserve more explanation — we'd love to hear about it. Right now Trevor is doing a massive overhaul of book 3 precisely for this reason. I'm tackling assorted programming constructs to try to make things more modular and caveman simple. Your feedback is definitely appreciated.

[f35f22fan]

Reply to trevorblack:

It makes sense but IMHO bored mathematicians should be the least of worries/priorities as opposed to "normal" people who only remember a few things about math and need a few days to figure out e.g. the following - how the math expression before the following quote (from the tutorial - Ray Tracing In One Weekend):

"The rules of vector algebra are all that we would want here. If we expand that equation and move all the terms to the left hand side we get:"

came to be to the one after this quote (I can't paste them). I know it's probably simple to you but not to "normal" people, I had to start a forum topic on a math website and ask this question. And yeah, it took me like 4 days to get to half of that tutorial because it's so hard if you're not a math student or something - usually programming is deemed fun while math is scary and extremely boring, that's why IMHO there are far more programmers than mathematicians.

[hollasch]

I hear you on the math part. It's a common experience (at least for me) to pick up a graphics paper and get broadsided by the wall of math. Another discussion we always seem to be having is how to expand the book in various directions. Imagining a new book 4 is simple, but how about a side trip from book 2? How would we wire in an appendix or a math digression? You wouldn't believe how frustrating it is to keep all downstream code listings aligned after making a change -- I refer to the problem as multi-dimensional version control (and would love to dig into this problem space sometime).

Concepts that you're talking about, though, should be relatively simple. For example, when we first use a cross product to get a surface normal. I could imagine providing a side-trip explanation of cross products without disturbing the downstream flow. That said, Trevor's concern still stands -- there's a lot of math we don't teach to understand the book. Wherever we stop that explanation, there will be those for whom that termination was too early. In the end, we're writing a linear algebra book. Not a bad thing, but definitely a large thing, and we're already overwhelmed with writing, re-writing and expanding the books as they are.

Still, I would love to see some sort of metric on how many readers are tripped up or challenged by which parts of the text. I wouldn't be surprised that many of these places could be significantly improved with a couple of additional sentences, or an appendix that's just a page or two long.

I imagine that this discussion is somewhat unsatisfying to you, and I think that it's a worthwhile discussion. I'm very intrigued with GitHub's new discussions feature, and this topic would be perfect for that, instead of just between the three of us. If you wouldn't mind, may I suggest that you voice your concerns there? It would be helpful to have more voices weigh in on these matters.

Finally, to echo again Trevor's reply, it would help us tremendously if you would create specific issues for sections of the text that you feel warrant further expansion. We're just two guys with many other side projects trying to juggle patch, minor and major releases, and this project is a monster that just keeps on growing. Tightly-described issues help us manage the load.

[f35f22fan]

Thanks, the discussion isn't unsatisfying, what you're saying is common sense and I also totally understand the frustration of having to keep your various works coherent and synchronized once something was updated and if you're doing it for free then it's even more frustrating.

I might start a discussion once I finish at least the first tutorial since after finishing it I might change my mind on things or have something more to add, so for now I'm done, thanks for your feedback, I understand it's not a forum just an issue tracker. Cheers!