pbrt-v3 source code now available back

(L) [2015/06/30] [mattpharr] [pbrt-v3 source code now available] Wayback!

In case anyone didn't see it on twitter or on the pbrt mailing lists, I've posted the pbrt-v3 source code: [LINK https://github.com/mmp/pbrt-v3].  This is the source code that corresponds to the (coming out in Spring 2016) third edition of the book.
There are many improvements and new features in this version; the readme file has all the details: [LINK https://github.com/mmp/pbrt-v3/blob/master/README.md].
We'd definitely be happy to hear feedback from the experts here about anything and everything.  (But with the caveat that we only have ~2 months before the manuscript goes off to the publisher and thence no significant changes to the implementation are possible any more.)
Thanks,
Matt

(L) [2015/07/01] [dr_eck] [pbrt-v3 source code now available] Wayback!

I took a quick run through the comments in the BDPT integrator but couldn't determine if you have implemented Georgiev's VCM or Hachisuka's near-equivalent.  I'm under the impression that these are really important contributions.  Are they included?  Will they be?
How about Markov Chain Monte Carlo?
Will you discuss Kelemen-style MLT versus Veach-style?  (Or did I miss that because I'm still at v1.0 of your book?)
How about Adaptive Progressive Photon Mapping?  (I only see SPPM in the code comments.)
PBRT is a great book.  I'd love to have a copy that include all of the best available algorithms.

(L) [2015/07/02] [koiava] [pbrt-v3 source code now available] Wayback!

Hello Matt,
Really good news! As I see, there is great major features and improvements, congrats! I'll definitely buy a new book!
I have a question about code, there you have sampling function for shape(sphere), and in addition you have function for Pdf? What is the reason to separate those two. Practically In every case when we sample something we also need to know pdf and in external function you need to calculate already calculated thinks again. I guess this is for readability and stylezation of code but I don't think that returning pdf from sampling functions somehow worsens readability.

(L) [2015/07/02] [bachi] [pbrt-v3 source code now available] Wayback!

>> koiava wrote:Hello Matt,
Really good news! As I see, there is great major features and improvements, congrats! I'll definitely buy a new book!
I have a question about code, there you have sampling function for shape(sphere), and in addition you have function for Pdf? What is the reason to separate those two. Practically In every case when we sample something we also need to know pdf and in external function you need to calculate already calculated thinks again. I guess this is for readability and stylezation of code but I don't think that returning pdf from sampling functions somehow worsens readability.
I think we will eventually need a separated Pdf function for MIS calculation anyway?

(L) [2015/07/02] [koiava] [pbrt-v3 source code now available] Wayback!

We might have separate Pdf functions but returning sample and sampling Pdf from sampling function I think is more clear. Is there any case when you are sampling something and you doesn't need to know pdf?

(L) [2015/07/02] [papaboo] [pbrt-v3 source code now available] Wayback!

I'm with Koiava on this. Generally I find it much easier to return both sample and pdf as a single entity. It just makes it clear that you need to take the pdf into account.
The only exception is when we can sample something uniformly and the pdf is the same for all samples. In some of those cases we can just average by the number of samples taken and pdf be damned. However, even in those cases I would still implement both sample methods, just to make it clear that there is still a pdf involved.

(L) [2015/07/03] [stefan] [pbrt-v3 source code now available] Wayback!

Spring 2016? I guess I have the code as bedtime reading material until then.  [SMILEY ;)]

(L) [2015/07/06] [shiqiu1105] [pbrt-v3 source code now available] Wayback!

Hi Matt,
Really looking forward to the book!
I took a brief at what you updated in v3, and it looks like some of the recent advances in gradient domain integrators have not been included.
Such as gradient path tracing and bidirectional path tracing. I personally feel like these are really impactful algorithms that many will use in the future.
Son't know if it's too late to suggest you to add it at this point.

(L) [2015/07/07] [ypoissant] [pbrt-v3 source code now available] Wayback!

I'm reading the chapter on floating point precision.
I was surprised to read that one can use an "enum" for casting between two different representations. I did not try that but I used to use a "union" for that.
Edit: I see that the "union" is later mentioned. So I say that the two use of "enum" are errors. Page 209.

(L) [2015/07/08] [ypoissant] [pbrt-v3 source code now available] Wayback!

On page 214, I don't understand the sentence "When working with these error intervals, it’s important to remember that because
(1 ± em) terms represent intervals, canceling them incorrect:"
On page 219 "then it’s impossible to tell whether it is exactly zero or whether a small positive negative value has rounded to zero."
Page 229 "guaranteed to be on the right side of the surface so that they ray doesn’t incorrectly intersect the surface it’s leaving." and "a second source of rounding error most also be addressed"