[HN Gopher] Physically Based Rendering: From Theory to Implement...
___________________________________________________________________
Physically Based Rendering: From Theory to Implementation
Author : ahamez
Score : 206 points
Date : 2025-01-13 14:28 UTC (4 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
| mattpharr wrote:
| How would one link to a physical object?
|
| If this is what you're asking: there are (perhaps too discreet)
| links at the bottom of each page to Amazon and MIT Press to
| purchase the physical book.
| timeforcomputer wrote:
| I think the geo URI scheme might work if you have an exact
| location for the book.
| 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.
| granter wrote:
| There is of course Bob Nystrom's
| https://craftinginterpreters.com
| WillAdams wrote:
| Thanks! Added it, and put a copy in my Amazon cart...
| taeric wrote:
| Great list! Sibling addition of Nostrom's book is a great
| addition. Not exactly the same, but close enough that I think
| it makes sense on the list.
| 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.
| phkahler wrote:
| >> 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.
|
| That is some excellent feedback. I like that our current
| simple Snells law shader doesn't add specular highlights and
| can do flat shading by turning off all but the ambient light.
| I had never heard of "Gooch" and I don't recommend searching
| for it without "Gooch in the context of rendering". That
| looks interesting and we already have code to draw the
| silhouette edges.
|
| I do think adding a PBR based Fresnel component with a
| backlight gives a similar but less sharp delineation of edges
| of objects, but it tends toward white right on the edge.
|
| While people like a good PBR render, I agree that in CAD the
| objective of the rendering is to clearly convey the geometry
| AND the sketching tools and entities the user is
| manipulating.
| TinkersW wrote:
| Even if you have a standard specular & diffuse model, indirect
| lighting is really important and you can't really just drop
| that into a shader.
|
| If you want a standard I've go with OpenPBR, it is well
| documented and looks nice. Just skip the extra layers to begin
| with(fuzz/coat etc).
| jayd16 wrote:
| There's no standard and even moving things from one 3D program
| to another can be a painful process if someone else didn't
| already build in some sort of conversation.
| 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/
| bradrn wrote:
| > I am hoping to be able to get some projects going in this
| direction (feel free to reach out if anyone are interested).
|
| This does sound interesting! I've just finished a Masters
| degree, also in non-imaging optics (in my case oceanographic
| lidar systems). I have experience in raytracing for optical
| simulation, though not quite in the same sense as optical
| design software. How should I contact you to learn more?
| hakonjdjohnsen wrote:
| Interesting! I added an email address to my profile now
| bradrn wrote:
| Great! I'll send you an email now.
| accurrent wrote:
| Sounds a bit like https://github.com/mitsuba-
| renderer/mitsuba2
| hakonjdjohnsen wrote:
| Yes, exactly. I have not looked at Mitsuba 2, but Mitsuba 3
| is absolutely along these lines. It is just starting to be
| picked up by some of the nonimaging/illumination community,
| e.g. there was a paper last year from Aurele Adam's group
| at TU Delft where they used it for optimizing a "magic
| window" [1]. Some tradeoffs and constraints are a bit
| different when doing optical design versus doing (inverse)
| rendering, but it definitely shows what is possible.
|
| [1] https://doi.org/10.1364/OE.515422
| accurrent wrote:
| I dont know much about Optical engineering, but this
| sounds super exciting. I think I meant to point to
| mitsuba 3, not 2.
| roflmaostc wrote:
| Shameless plug, we use Mitsuba 3/Dr.JIT for image
| optimization around volumetric 3D printing
| https://github.com/rgl-epfl/drtvam
| hakonjdjohnsen wrote:
| Looks really cool! I look forward to reading your paper.
| Do you know if a recording of the talk is/will be posted
| somewhere?
| roflmaostc wrote:
| We presented this work at SIGGRAPH ASIA 2024. But I think
| they do not record it?
|
| Maybe in some time we also do an online workshop about
| it.
| pjmlp wrote:
| It looks quite interesting, especially the part of
| scripting everything in Python with a JIT, instead of the
| traditional having to do everything in either C or C++.
|
| Looking forward to some weekend paper reading.
| 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.
| fooker wrote:
| You're missing the point. The difficulty is not in the ray
| tracing, etc. It is in understanding the domain of the
| software and what needs to be done to make it useful.
|
| I completely agree that whatever simulation they have can
| be easily done better with modern GPUs.
| 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...
| echelon wrote:
| I predict PBR is going to fall to neural rendering. Diffusion
| models have been shown to learn all of the rules of optics and
| shaders, and they're instructable and generalizable. It's god
| mode for physics and is intuitive for laypersons to manipulate.
|
| We're only at the leading edge of this, too.
| CyberDildonics wrote:
| Can you link the neural rendering animation you're talking
| about with some info on the total rendering times without any
| precomputation?
| lightedman wrote:
| " I wonder how much work would be involved for someone to make
| optical design software that blows away the old tools"
|
| Depending on use case, it already exists for gem cutters. We
| can simulate everything from RI to fluorescence excitation.
| liontwist wrote:
| > eye-wateringly expensive
|
| For you. Anyone doing design and manufacturing of optics will
| not blink at paying for software.
| ska wrote:
| This is one example of an area where economic incentives make
| it difficult to shift. - There aren't that many
| people willing to pay for such software, but those that do
| *really* need it, and will pay quite a bit (passing that cost
| on of course). - The technical domain knowledge
| needed to do it properly is a barrier to many - It
| needs to be pretty robust
|
| As a result, you end up with a small handful of players who
| provide it. They have little incentive to modernize, and the
| opportunity cost for a new player high enough to chase most of
| them off to other avenues.
|
| I think the main way this changes is when someone has already
| spend the money in an adjacent area, and realized "huh, with a
| little effort here we could probably eat X's lunch"
|
| Beyond that you at most get toy systems from enthusiasts and
| grad students (same group?) ...
| 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?
| losvedir wrote:
| All right, off topic but I've seen this a bunch lately and the
| term just really irritates my brain for some reason. What's its
| origin? "[adverb] based" just feels so wrong to me. Shouldn't
| that be a noun: "Evidence-based medicine", "values-based",
| "faith-based", etc. Does "physically based" bother anyone else?
| msk-lywenn wrote:
| It bothers me too, but I'm French. I always assumed it was some
| corner of the language I don't know
| curiousObject wrote:
| But what alternative can you suggest which doesn't break
| grammar or usage precedents like "physically based"?
|
| Physics-based? Reality-based? Physically-derived?
| roelschroeven wrote:
| Physics-based sounds perfectly fine to me.
|
| "X-based" to me is equivalent with "based on X". Physics-
| based = based on physics, evidence-based = based on evidence,
| values-based = based on values; all perfectly fine.
|
| Physically based feels correct in a sentence like "Our
| company is physically based in New York but we operate world-
| wide". But what does the "physically based" in "physically
| based rendering" mean?
|
| But I'm not a native speaker, what do I know.
| corysama wrote:
| It is a bit of a silly term. It was made mostly to contrast
| against the somewhat more adhoc methods that preceded it. The
| new technique was parameterized more around physical properties
| where the older ones were more about visual descriptions.
|
| This paper from Disney is what kicked off the movement
| https://disneyanimation.com/publications/physically-based-sh...
| nxobject wrote:
| Note that the book is even older than that - I remember first
| reading it in 2009; apparently the 1st edition was in 2004!
| keyle wrote:
| off topic: I live in this strange world where I can read the code
| and understand what it does, regardless of the language(!)
|
| but the algorithm for the theory looks approximately like this to
| me (ijfio) $@ * foiew(qwdrg) awep2-2lahl [1]
|
| Is there a good book that goes FROM programmer TO math-wizardry
| that you would recommend, without falling into the textbooks?
| Ideally I'd like to be able to read them and turn them into
| pseudocode, or I can't follow.
|
| [1]: e.g. https://pbr-
| book.org/4ed/Introduction/Photorealistic_Renderi...
| jahewson wrote:
| Screenshot and ask ChatGPT. Works pretty well.
| keyle wrote:
| Neat idea, thanks!
| nxobject wrote:
| +1 - often, for me, since a lot of the computations are
| estimated anyway, the biggest thing I need to do is ask
| ChatGPT to break down the notation and give me the precise
| terminology.
| gspr wrote:
| As a mathematician by training who does a lot of programming
| for a living: This is the biggest misconception about math I
| see coming from programmers. There's frequently a complaint
| about notation (be it that it is too compact, too obscure, too
| gatekept, whatever) and the difficulty in picking out what a
| given "line" (meaning equation or diagram or theorem, or
| whatever) means without context.
|
| Here's the thing though: _Mathematics isn 't code!_ The symbols
| we use to form, say, equations, are not the "code" of a paper
| or a proof. Unless you yourself are an expert at the domain
| covered by the paper, you're unlikely to be able to piece
| together what the paper wants to convey from the equations
| alone. That's because mathematics is written down by humans
| _for humans_ , and is almost always conveyed as prose, and the
| equations (or diagrams or whatever) are merely _part of that
| text_. It is way easier to read source code for a computer
| program because, by definition, that is all the computer has to
| work with. The recipient of a mathematical text is a human with
| mathematical training and experience.
|
| Don't interpret this as gatekeeping. Just as a hint that math
| isn't code, and is not intended to be code (barring math
| written as actual code for proof assistants, of course, but
| that's a tiny minority).
| jayd16 wrote:
| Maybe you're right and maybe that's the culture in
| mathematics but we don't have to like it.
| stonemetal12 wrote:
| The text seemed to describe it quite well. They just use a
| bunch of physics jargon because the book approaches rendering
| from the physics side of things.
|
| Light leaving a point in a direction = light emitted from that
| point in that direction (zero if we aren't talking about a
| light bulb or something) plus all light reflected by that point
| in that direction.
| timeforcomputer wrote:
| I love this book so much. The literate programming style I think
| inspired from Knuth's cweb, great writing, beautiful high-quality
| physical book worth buying but also free access to knowledge. The
| literate-programming style means you are almost immediately
| applying theory to a practical system, I keep having to take
| breaks to learn outside math/physics though, but it is self-
| contained in principle I think.
___________________________________________________________________
(page generated 2025-01-17 23:01 UTC)