pbrt-v3 source code has been released

[Matt Pharr]

We've posted a drop of the source code that corresponds to the version of pbrt that will be described in the forthcoming(*) third edition of Physically Based Rendering; it's up at https://github.com/mmp/pbrt-v3.

There are quite a few improvements: a bidirectional path tracer with proper multiple importance sampling, multiplexed MLT, stochastic progressive photon mapping, lots of new quasi-random samplers, Heitz's new microfacet sampling scheme, an all new subsurface scattering implementation directly in the path tracer, and much more.

There's not much documentation beyond a README, the code, and some example scenes, but we're making the code available so that people can check it out and hopefully help us improve it before the book's contents are finalized; see https://github.com/mmp/pbrt-v3#how-you-can-help for some ways you can help us out.

The system also has a new approach to managing floating-point error in ray-intersection calculations that we think is interesting and useful; a draft of the section of the book that describes it is also available (http://pbrt.org/fp-error-section.pdf); we're happy to hear any comments from anyone who has time to review that.

Thanks!

Matt (and Wenzel and Greg)

(*) The third edition book should be out in Spring 2016.

[Guillaume Bouchard]

Hello,

On Wed, Jun 17, 2015 at 2:23 AM, Matt Pharr <matt....@gmail.com> wrote:
> There are quite a few improvements: a bidirectional path tracer with proper
> multiple importance sampling, multiplexed MLT, stochastic progressive photon
> mapping, lots of new quasi-random samplers, Heitz's new microfacet sampling
> scheme, an all new subsurface scattering implementation directly in the path
> tracer, and much more.

Could you give a bit of details regarding the SSS implementation ? Is
this something new to the literature ?

> The system also has a new approach to managing floating-point error in
> ray-intersection calculations that we think is interesting and useful; a
> draft of the section of the book that describes it is also available
> (http://pbrt.org/fp-error-section.pdf); we're happy to hear any comments
> from anyone who has time to review that.

In page 209, did you mean Union in place of Enum ?

(I'll have a more focused read later, but this pops to my eyes during
a diagonal read).

Good luck with the release.

--
G

[mike artixels]

Thanks a lot for early posting v3 and I really can't wait to order the 3rd ed.

I quickly made a CMake port to windows today and it looks like v3 has quite a bit C+11 (e.g. constexpr) and some gcc specifics (e.g. __thread) there and VS2013 really can't handle them well, hope to spend more time later to port.

Best,

Mike 

[Ali]

Thanks a lot!

[Anass Lasram]

Thanks for sharing this new version.

In the floating point error analysis draft there's a repeated "the" in  "computers can only represent finite quantities and therefore can’t actually represent all of the the real numbers"

In section "Utility Routines" there's the mention: "it’s unclear whether the float or double isnan() variant should be used". The C++ standard [c.math] paragraph 11 states that any integral type will be cast to double (hence isnan of integral types will always return false)

--
You received this message because you are subscribed to the Google Groups "pbrt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pbrt+uns...@googlegroups.com.
To post to this group, send email to pb...@googlegroups.com.
Visit this group at http://groups.google.com/group/pbrt.
For more options, visit https://groups.google.com/d/optout.

[Matt Pharr]

I just checked and saw how limited c++11 support is in MSVC 2013 :-(. We had unfortunately assumed it would be safe to use c++11 fairly liberally (though we tried not to go overboard with it).

It's definitely important to us that pbrt-v3 be easy to use on Windows systems; if you have a chance to dig into how much surgery needs to be done to get it to build in Windows, we'd really appreciate the insight. (This is particularly useful in the next month or two, when changes we make can still be reflected in the book's text.)

Thanks,

Matt

[Wenzel Jakob]

Hi Mike,

are you using the patch release 5 (https://www.visualstudio.com/en-us/news/vs2013-update5-vs.aspx)?

This is needed to get reasonable C++11 support in VS2013. 

If there are still problems with that, then we'd appreciate a pointer to offending files.

Thanks,
Wenzel

[Mike Wong | ax.gmail]

Hi Matt,

no problem, will report more next week, hopefully.  btw, I like the idea of minimizing dependencies, esp. the tinyexr :)

Best,

Mike

[Matt Pharr]

Thanks for the "the the" catch! (And then I thought to grep for more, and found a number more of those.)

Thanks also for the isnan() correction; I replaced all IsNan() calls with std::isnan(). I *swear*  gave compile errors before, which led to a that horrible work around, but I'm really happy to get rid of that.

(Updated code push to come in a bit.)

Thanks,

Matt

[Matt Pharr]

Great, thanks! FWIW one of the motivations to getting tinyexr to work was to make the Windows build less tortuous.  (Though it makes all of them that much easier, I think.)

Thanks,

Matt

[Mike Wong | ax.gmail]

Hi Wenzel,

Thanks a lot for the update 5 pointer !  I was only using VS2013 update 1 on a production machine.  okay, will try again with update 5 and report.

Best,

Mike

--
You received this message because you are subscribed to a topic in the Google Groups "pbrt" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pbrt/xrJO0mM6sLY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pbrt+uns...@googlegroups.com.

[Mike Wong | ax.gmail]

quick report: vs2013.5, still not a good fan of constexpr (used in around 13 files) or binary literals (bvh.cpp only).

I tested quickly the code below on MS online compiler (it's a vs2015 RTM I guess) - http://webcompiler.cloudapp.net/ and compiled well.

will port on VS2015 and report later.

----- CUT HERE -----

#include <iostream>

using namespace std;

int main()

{

    typedef float Float;

    static constexpr Float MaxFloat = std::numeric_limits<Float>::max();

    static constexpr Float Infinity = std::numeric_limits<Float>::infinity();

    static constexpr Float MachineEpsilon = std::numeric_limits<Float>::epsilon() * 0.5f;

    int x = 100;

    x = (x | (x << 16)) & 0b00000011000000000000000011111111;

    // x = ---- --98 ---- ---- ---- ---- 7654 3210

}

[Artem Kharitonyuk]

Hi Mike,

Visual Studio 2015 will be released this year, and it will have full-featured free version and I expect that even project files will be the same for all editions (in contrast to current express version).

So on windows we might consider an option to generate VS 2015 project files.

At the moment VS 2015 RC version is available, I did not check but maybe it has better support for c++ 11/14.

Thanks,

Artem.

[Mike Wong | ax.gmail]

Yes, installed the VS2015 community RC today (with CMake 3.2 generated sln) but the compiler is not as good as the RTM one, worked okay though.  

I agree the final VS2015 should be good enough and no big fix needed to make a dirty running port so far, the fixes applied:

1. use of ParallelFor() needs cast as the compiler failed to resolve

2. VS has no support of hex floating point constants, you are aware of it according to the comments ;-)

3. __builtin_clz(), __builtin_ctz() subsitutions

4. #define __thread thread_local

5. std::min, std::max from <algorithm> now

I only manage to render with sppm integrator at the moment, well, never mind :)

Love this v3 and I heard a mitsuba update is also coming soon, Wenzel ?

Thanks + Bon weekend,

Mike

[Matt Pharr]

Ok, great; thanks for digging into this!

I've just merged Aaron Karp's pull request, which included a bunch of Windows fixes, and have tried to fix #4 by hand (and cleaned up some other stuff); all is pushed to github now.

Can you give me more context about #1 and #5? #1 sounds similar to https://github.com/mmp/pbrt-v3/issues/6, which was on linux, so I'm wondering if we're actually doing something bogus in the code.

I'm surprised that floating point constants still aren't available in VC 2015. :-(

We'll get there eventually!

Thanks,

Matt

[Wenzel Jakob]

Hi Guillaume,

the SSS implementation is a combination of Habel et al.’s Photon Beam Diffusion and King et al.’s MIS-based ray tracing approach.

Cheers,
Wenzel

[Mike Wong]

I completed a working Windows port with VS2015 RC today, now on my 'appVeyor' branch:

https://github.com/mwkm/pbrt-v3

bunny, dragons, veach and head scenes all rendered fine.  I have included CI links on the readme.md, so the build and test logs for both VS2015 and OSX can be checked quickly.

I can make some pictures now !

thanks,

Mike

[Matt Pharr]

Great!  We will get it all merged; the process takes a bit longer than it would normally in that we also need to back-port all of these changes into the book text (and then make sure we got it all right). So, please forgive slowness on this end in getting it all in there!

Thanks,

Matt

[Mike Wong]

I think the pace is just right and please take your time :)

Best,

Mike

[Adrien Lamarque]

Hello,

There's a fairly obvious typo in the floating point document P209:
it's written that you can use an enum, but obviously you meant a
union.

The discussion on type punning is interesting though. I didn't know
that it's illegal in C++. I did a bit of further research afterwards
and it seems like it's legal in C11 (although it's not clear, because
I've read contradictory answers on that) but not in C++11 (that one is
pretty clear though); though it's so common that most compilers should
do the right thing (in particular GCC does support it as a special
case even with -fstrict-aliasing, and I'd be surprised if MSVC didn't
do as well).
(See http://stackoverflow.com/questions/25664848/unions-and-type-punning
and http://stackoverflow.com/questions/11373203/accessing-inactive-union-member-undefined
for discussion)

In any case, I didn't know about the memcpy trick either. Did you do
any real-world test on the compilers used? Is it confirmed to be a
noop?

Thanks!

Adrien

On Wed, Jun 17, 2015 at 2:23 AM, Matt Pharr <matt....@gmail.com> wrote:

[Marshall Ross]

Just curious if PBRT 3 will include some sort of displacement mapping, and support for Open Shading Language? I think a Blender exporter would be awesome too. Thx!

[megavoxel]

Hi, some questions regarding the new realistic camera implementation.

Is it based on the paper “A Realistic Camera Model for Computer Graphics” ? Is it capable of rendering bokeh effect? What's the use of those DrawXX function like DrawLensSystem?

Thanks for any explanation in advance.

 

 

[Matt Pharr]

On Wed, Jul 29, 2015 at 2:37 PM, Adrien Lamarque <a...@lamarque.fr> wrote:

In any case, I didn't know about the memcpy trick either. Did you do
any real-world test on the compilers used? Is it confirmed to be a
noop?

Yep!

% echo "#include <memory.h>\n unsigned int foo(float f) { unsigned int i; memcpy(&i, &f, 4); return i; }" | g++ -Wall -O3 -S -o - -x c++ -

.section __TEXT,__text,regular,pure_instructions

.macosx_version_min 10, 10

.globl __Z3foof

.align 4, 0x90

__Z3foof:                               ## @_Z3foof

.cfi_startproc

## BB#0:

pushq %rbp

Ltmp0:

.cfi_def_cfa_offset 16

Ltmp1:

.cfi_offset %rbp, -16

movq %rsp, %rbp

Ltmp2:

.cfi_def_cfa_register %rbp

movd %xmm0, %eax

popq %rbp

retq

.cfi_endproc

 Thanks,

Matt

[Matt Pharr]

We left both displacement mapping and OSL support for exercises at the end of chapters.

Agreed that a blender exporter would be awesome. (cough) :-).

I've had pretty good luck using the LuxBlend exporter and/or the blender OBJ export and then obj2pbrt to convert scenes, but there's still a lot of manual work to do converting materials, lights, etc, which would be nice to have more automated...

Thanks,

Matt

[Matt Pharr]

It is largely based on that paper (with a few differences, like how it computes the exit pupil.)

Those Draw*() methods emit Mathematica code, which in turn we used to generate figures of lens systems for the book. It's unclear if it's really worthwhile to include them in the source code distribution, but OTOH it doesn't really hurt.

Thanks,

Matt