[HN Gopher] Physically Based Rendering: From Theory to Implement...
       ___________________________________________________________________
        
       Physically Based Rendering: From Theory to Implementation
        
       Author : ahamez
       Score  : 95 points
       Date   : 2025-01-13 14:28 UTC (3 days ago)
        
 (HTM) web link (pbr-book.org)
 (TXT) w3m dump (pbr-book.org)
        
       | amelius wrote:
       | Why don't they link to the physical book?
        
         | jsheard wrote:
         | They do, on the main site: https://www.pbrt.org
        
         | rezmason wrote:
         | Physically Based Reading
        
       | taeric wrote:
       | This and https://hint.userweb.mwn.de/understanding_mp3/index.html
       | are both amazingly fun examples of literate programming that I
       | recommend all of the time.
        
         | WillAdams wrote:
         | I've been keeping a list of Literate Programs published as
         | books, as well as supporting texts:
         | 
         | https://www.goodreads.com/review/list/21394355-william-adams...
         | 
         | I'd be glad to know of any I missed, or of a similar resource
         | for websites.
        
       | phkahler wrote:
       | Is there a standard OpenGL (ES3) shader I can drop in a GPLed
       | application that uses a decent (is there a standard?) BRDF
       | similar to Schlick with red,green,blue, and roughness?
       | 
       | I've wanted to add this capability to Solvespace for a while. I
       | did my own implementation with the Fresnel term and it looked OK,
       | but I want something "standard" and correct.
        
         | jms55 wrote:
         | There is no standard.
         | 
         | Filament is extremely well documented:
         | https://google.github.io/filament/Filament.html
         | 
         | glTF's PBR stuff is also very well documented and aimed at
         | realtime usage: https://www.khronos.org/gltf/pbr/
         | 
         | OpenPBR is a newer, much more expensive BRDF with a reference
         | implementation written in MaterialX that iirc can compile to
         | glsl https://academysoftwarefoundation.github.io/OpenPBR
         | 
         | Pick one of the BRDFs, add IBL https://bruop.github.io/ibl, and
         | you'll get decent results for visualization applications.
        
         | Pathogen-David wrote:
         | You might find value in the glTF sample renderer
         | https://github.com/KhronosGroup/glTF-Sample-Renderer
         | 
         | It won't be plug and play since you'd have to pull out the
         | shaders and make them work in your app, but the implementation
         | supports quite a few material variants. The PBR shader
         | implementation starts in source/Renderer/shaders/pbr.frag
        
         | fsloth wrote:
         | I think most realtime production uses something similar to
         | Disney BRDF when they refer to PBR.
         | 
         | https://media.disneyanimation.com/uploads/production/publica...
         | 
         | I don't think there is a standard as such that would dominate
         | the industry. It's all approximations to give artists
         | parameters to tweak.
         | 
         | IMHO - Being an ex professional CAD person I think PBR is the
         | wrong visual style for most cad though. The main point of
         | shading is to improve the perception of shape and part
         | isolation there. Traditional airbrush based engineering
         | illustration styles are much better reference. So something
         | like Gooch with depth buffer unsharp masking IMHO would be much
         | much more appropriate.
        
       | crispyambulance wrote:
       | Every time I see stuff like this it makes me think about optical
       | design software.
       | 
       | There are applications (Zemax, for example) that are used to
       | design optical systems (lens arrangements for cameras, etc).
       | These applications are eye-wateringly expensive-- like similar in
       | pricing to top-class EDA software licenses.
       | 
       | With the abundance GPU's and modern UI's, I wonder how much work
       | would be involved for someone to make optical design software
       | that blows away the old tools. It would be ray-tracing, but with
       | interesting complications like accounting for polarization,
       | diffraction, scattering, fluorescence, media effects beyond
       | refraction like like birefringence and stuff like Kerr and
       | Pockels, etc.
        
         | amelius wrote:
         | I once saw a youtube video of a guy who first modeled a pinhole
         | camera in something like Blender3D and then went on to design
         | and simulate an entire SLR camera.
        
           | Tomte wrote:
           | https://youtu.be/YE9rEQAGpLw
        
             | amelius wrote:
             | Thanks, but it was a different video.
             | 
             | I remember he had a lot of problems with the pinhole camera
             | because the small size of the pinhole meant that rays had
             | trouble going into the box, so to speak, and thus he needed
             | an insane amount of rays.
        
         | hakonjdjohnsen wrote:
         | This, very much this!
         | 
         | I do research in a subfield of optics called nonimaging optics
         | (optics for energy transfer, e.g. solar concentrators or
         | lighting systems). We typically use these optical design
         | applications, and your observations are absolutely correct.
         | Make some optical design software that uses GPUs for
         | raytracing, reverse-mode autodiff for optimization, sprinkle in
         | some other modern techniques you may blow these older tools out
         | of the water.
         | 
         | I am hoping to be able to get some projects going in this
         | direction (feel free to reach out if anyone are interested).
         | 
         | PS: I help organize an academic conference my subfield of
         | optics. We run a design competition this year [1,2]. Would be
         | super cool if someone submits a design that they made by
         | drawing inspiration from modern computer graphics tools (maybe
         | using Mitsuba 3, by one of the authors of this book?), instead
         | of using our classical applications in the field.
         | 
         | [1] https://news.ycombinator.com/item?id=42609892
         | 
         | [2] https://nonimaging-conference.org/competition-2025/upload/
        
         | zokier wrote:
         | I'd imagine there is fairly wide gap between having a
         | simulation engine core and an useful engineering application
         | 
         | From academic side, I've found the work of Steinberg in this
         | area extremely impressive. They are pushing the frontier to
         | include more wave-optical phenomenon in the rendering. E.g.
         | https://ssteinberg.xyz/2023/03/27/rtplt/
        
         | fooker wrote:
         | Well, everyone who can build this niche software is already
         | employed to build it.
        
           | Q6T46nT668w6i3m wrote:
           | I think you're overthinking this, e.g., Zemax's optimization
           | isn't that different than the ray-tracing presented in this
           | book. The sophistication truly comes from the users.
        
           | crispyambulance wrote:
           | Yeah, perhaps.
           | 
           | But the heavy-hitters in this field all seem to have very
           | old-timey UI's and out-of-this-world pricing.
           | 
           | Meanwhile, raytracing for computer graphics on GPU's is soooo
           | performant-- it makes me wonder how much work needs to be
           | done to make the equivalent of KiCAD for optical design.
        
         | Q6T46nT668w6i3m wrote:
         | You'd be surprised! Everywhere I've worked, academic or
         | industry, typically writes their own simulation software.
         | Sometimes it's entirely handwritten (i.e., end-to-end,
         | preprocessing to simulation to evaluation), sometimes it'll
         | leverage a pre-existing open source package. I imagine this
         | will become more and more common if, for no other reason, you
         | can't back-propagate an OpticStudio project and open source
         | automatic differentiation packages are unbeatable.
        
           | lcrs wrote:
           | If you're interested in the equivalent of "backprop through
           | zemax" there are a few projects going on to jointly optimize
           | optical designs with the image processing, e.g. check out:
           | https://vccimaging.org/Publications/Wang2022DiffOptics/
        
         | lcrs wrote:
         | I've been working on something similar, although I'm more
         | interested in replicating the effects of existing lenses than
         | designing new ones:
         | https://x.com/dearlensform/status/1858229457430962318
         | 
         | PBRT 3rd edition actually has a great section on the topic but
         | it's one of the parts that wasn't implemented for the GPU (by
         | the authors, anyway): https://pbr-
         | book.org/3ed-2018/Camera_Models/Realistic_Camera...
        
       | magicalhippo wrote:
       | I've mentioned it before, but this book is amazing in the way it
       | covers both the theory in detail, as well as the implementation.
       | 
       | There's often a lot of details that matter when implementing
       | something efficiently and well which the theory either hides or
       | is a result of our hardware limitations like floating point
       | numbers.
       | 
       | Almost all other programming books I've read cover either the
       | theory in detail and gloss over the implementation details, or
       | goes into a lot of implementation stuff but only cover the easy
       | parts and doesn't give you a good indication of how to deal with
       | the advanced stuff.
       | 
       | So, any other books out there that you've read that is like PBR?
        
       ___________________________________________________________________
       (page generated 2025-01-16 23:00 UTC)