What's the usecase for Google building a PBR? Is it just a "we're huge so let's have a foot in everything" deal? Or do they have some novel insight that could put it above and beyond the status quo?
Having worked at Google myself, quite honestly, I don't think there is a use case. Romain and Mathias are both very senior engineers. They get a lot of freedom to to work on whatever they desire.
> This is not an officially supported Google product.
Basically when Google employees ask permission to work on a side project, Google asks them to release it open source under Google's GitHub but mark it as not an official Google product. This is probably something the authors work on nights/weekends and not anything to do with their work.
You can also request that you obtain total control over the project (not hosted by google, not copyrighted by google) but those requests are hard to get approved.
It makes sense when you want to use your open source project at work, rather than having it completely separate from work. It might be possible to work on it as 20% time if it’s plausible that projects at Google might use it. You could talk about it at promotion time. And at the same time, you’ll still be able to use it if you leave the company.
This is a way to have your cake and eat it too. Most code you work on at work isn’t open source at all.
Alternatively, you could have a side project that’s completely separate from your job.
The GP made it sound like you can't just have a side project that's completely separate from your job; that side projects are Google's by default unless you go out of your way to get permission to separate it out
In most jurisdictions that wouldn't even be allowed by the country law.
Google or any other company would have very hard time forbidding what employees do on their free time outside work, regardless of what they feel like putting on the work contract.
The Status Quo in 3d is always moving ahead. Having another good open source PBR Renderer available can be hugely beneficial. Game engines with non-state-of-the-art renderers coudl try to integrate it - or more general: any app that wants to display realtime 3d content in a convincing way could benefit from it - most 3d content creation pipelines nowadays are tailored towards PBR (f.e. Metal/Roughness Workflow). If it focuses on mobile then it probably also perform well on desktops. Sadly, no DX support.
I tried to use it since I desperately needed a standalone renderer in C++ that is better than my hand-rolled one.
Turns out that it only supports Clang and not GCC (it depends on libc++ instead of libstdc++, which generates tons of ABI issues when integrating with existing projects and libraries).
In short, if you need to use other libraries (such as libtorch) that don’t support libc++, then don’t use it, it’s going to be a big waste of time.
That subsurface scattering model is not what you would use for skin, etc. It's a fairly simple approximation similar to what Unreal and Frostbite have used (use?) in the past to cheaply approximate somewhat translucent materials. It's mostly still a TODO because it's not that interesting.
Without looking at the code, I doubt it. Real-time reflections are generally done with offscreen rendering and cube maps. The objects being reflected are still rendered, you just can't see them because they aren't in the projection/view space.
You can tell it's not raytracing because you can't see the ear of the head reflected into the head. That's the tell-tale sign of raytracing, when an object reflects into itself.
To nitpick the other answers its actually called Image-Based Lighting (IBL), which is a fancier PBR technique compared to traditional environment-mapping
> Figure 44: The Planckian locus visualized on a CIE 1931 chromaticity diagram
Visualized... using broken code. Note the Planck curve isn't going through white. Imagine your surprise at setting your monitor to a 6500K or 5000K white point, and finding it green or yellow.
> (source: Wikipedia)
Sigh. WP has Article and Talk, but neither has served as a "writer's notebook" for long-term memory. So when there's lots of brokenness out in the world, and there's been lots of broken color code over the years, WP has difficulty remembering to avoid it.
Isn’t it a consequence of a post rendering creative editing, e.g. blurring of the generated chromaticities colours, rather than the code itself being broken. No display can reproduce the entirety of the chromaticity diagram, thus there will always be some form of “cheating” required to try to picture it. I do agree with you that burring is not great though and does not really serve anything but aesthetics.
Gamut limitations mostly affect the periphery, rather than the center. Three arms of lightness converge on a white point, here near the bottom of the line marked 6000. Incorrectly far below the Planck curve, pulling bogus colors down over the curve. The curve should go from red to white to blue. Very not orange yellow green cyan. Figure 45 just below looks more plausible. Earlier versions of the wikicommons diagram[1] seem less blurred, making it easier to see its error.
For extra fun, this[2] illustrates both gamut position, and the recurring brokenness of a white point label indicating where white was expected, and the rendered white point being elsewhere.
It’s impossible to plot colors on a chromaticity diagram in a way that isn’t grossly misleading. This particular picture is one attempt at a compromise that will give readers the right conceptual impression, not “broken” accidentally.
The best compromise if you want color might instead be to only color a narrow strip around the triangle forming the gamut of your trichromatic additive display (or, say, sRGB), with intensity of the 2-primary mixture at each point adjusted so that lightness doesn’t vary too sharply.
A large portion of the horseshoe is outside your display’s gamut; common pictures either color the outside of the gamut gray, or try to clip out-of-gamut chromaticities to the nearest in-gamut chromaticity. The former is confusing for viewers who don’t already know what they are looking at; the latter gives a false impression. For the colors that are shown, one typical way to plot a 2-dimensional picture of the gamut is “top down” with the most intense available color for each chromaticity, but this introduces substantially misleading lightness artifacts based on the display not based on chromaticities per se.
Beyond that, the xy chromaticity diagram should not be used. Stick to the u'v' chromaticity diagram.
> It’s impossible to plot colors on a chromaticity diagram in a way that isn’t grossly misleading
Ok, but...
> This particular picture is one attempt at a compromise that will give readers the right conceptual impression, not “broken” accidentally.
No, the white point calculations used to make that wikipedia diagram are simply wrong. It's a recurring problem. Not a question of handling out-of-gamut colors, but of mislocating colors within it.
For instance, this fourmilab page[1] and associated specrend code, had incorrect white-point-related math for many years (the code was fixed, the page I don't recall), which IIRC, caused 'front page of the New York Times' "Universe is green"-level professional embarrassment.[2]
Here's a less bogus diagram.[3] Note the white point being close to the Planck curve, in contrast to the wikicommons diagram.
Some of the conceptual impressions seem quite unfortunate, reinforcing common misconceptions. That blackbodies (the Planck curve) can be colorful (other than red white and blue). The associated misconception that visible candle light is blackbody radiation. The extremely common astronomy education misconception that the Sun and many stars are yellow (for white points more perceptually relevant than blue Vega). A challenge in shifting science education towards more integrated and operational understanding, is so much content being variously incorrect, and thus not fitting together.
> Stick to the u'v' chromaticity diagram.
Yes, perceptually uniform color spaces are nice. Hmm, and that raises an interesting question: might incorrect diagrams be less common there? Being younger, and perhaps with open source libraries and eyeballs, replacing coding things yourself from a book, and simply copying diagrams stumbled on somewhere without checking them. A question for google image search...
The u'v' chromaticity diagram has been the recommended tool since 1976, 45 years ago, long before any diagram you will see on the web was created.
The “color of the universe” brouhaha is amusing, but trying to assign a color to the universe is somewhat nonsensical, and the result is not really meaningful to laypeople.
You are absolutely right, this diagram is misleading and I've been meaning to replace it with one of my own since forever but it has fallen deep at the bottom of long list of things to do (including many, many things I would like to describe in that document, like our approach to transmission/absorption/refraction, our post-processing pipeline, etc.).
Oh, no worries. Lists of doables are infinite, and life is very not. It's merely something I reflexively note out of long habit.
Fwiw, one remediation which appeals to me, when using flawed content, is adding a "bogus" tag. As in "Figure N Mumble (source WP) Somewhat flawed." Or sometimes "Bogus <attribute or issue>". So the reader maybe gets a heads-up that there's a known issue - a "first, do no harm" thing. Modulo esthetic constraints, and I've no idea if it actually helps. And it might be phrased more accessibly. I dont know of any associated education research.
Big picture, societal-level impacts of commonly flawed content seem unlikely to improve without being addressed systemically, and so don't seem a priority focus when pursuing local excellence. For example, students are told the Sun is yellow in Kindergarten, and repeatedly thereafter, with only a few later getting an "oops, nope, our bad" in astronomy grad school discussion of common misconceptions in astronomy education content... and careful avoidance of yellow Suns in say one weather app seems unlikely to move that needle much.
41 comments
[ 3.2 ms ] story [ 107 ms ] threadBasically when Google employees ask permission to work on a side project, Google asks them to release it open source under Google's GitHub but mark it as not an official Google product. This is probably something the authors work on nights/weekends and not anything to do with their work.
I had no problems getting approval for a tiny 2D home-trainer game I worked on this winter..
I suppose it varies depending on what you do. But if you work on part of it during 20% time, you probably can't do this.
disclaimer: I work at Google.
This is a way to have your cake and eat it too. Most code you work on at work isn’t open source at all.
Alternatively, you could have a side project that’s completely separate from your job.
Google or any other company would have very hard time forbidding what employees do on their free time outside work, regardless of what they feel like putting on the work contract.
https://developers.google.com/sceneform/develop
But like all big plans presented at Google IO it eventually joined Google graveyard, and apparently they kept on working on Filament alone.
What is it being used for?
i.e. the material compiler targeting desktop/vulkan https://google.github.io/filament/Materials.html#compilingma...
https://developers.google.com/sceneform/develop
I doubt anyone beyond the authors is using it in any form.
Turns out that it only supports Clang and not GCC (it depends on libc++ instead of libstdc++, which generates tons of ABI issues when integrating with existing projects and libraries).
In short, if you need to use other libraries (such as libtorch) that don’t support libc++, then don’t use it, it’s going to be a big waste of time.
Which is really saying something, there is an incredible wealth of information in here.
https://en.wikipedia.org/wiki/Cornell_box
No raytracing there, just plain old cube-mapped reflections.
Visualized... using broken code. Note the Planck curve isn't going through white. Imagine your surprise at setting your monitor to a 6500K or 5000K white point, and finding it green or yellow.
> (source: Wikipedia)
Sigh. WP has Article and Talk, but neither has served as a "writer's notebook" for long-term memory. So when there's lots of brokenness out in the world, and there's been lots of broken color code over the years, WP has difficulty remembering to avoid it.
For extra fun, this[2] illustrates both gamut position, and the recurring brokenness of a white point label indicating where white was expected, and the rendered white point being elsewhere.
[1] https://commons.wikimedia.org/wiki/File:PlanckianLocus.png [2] https://www.fourmilab.ch/documents/specrend/figures/ciegamut...
The best compromise if you want color might instead be to only color a narrow strip around the triangle forming the gamut of your trichromatic additive display (or, say, sRGB), with intensity of the 2-primary mixture at each point adjusted so that lightness doesn’t vary too sharply.
A large portion of the horseshoe is outside your display’s gamut; common pictures either color the outside of the gamut gray, or try to clip out-of-gamut chromaticities to the nearest in-gamut chromaticity. The former is confusing for viewers who don’t already know what they are looking at; the latter gives a false impression. For the colors that are shown, one typical way to plot a 2-dimensional picture of the gamut is “top down” with the most intense available color for each chromaticity, but this introduces substantially misleading lightness artifacts based on the display not based on chromaticities per se.
Beyond that, the xy chromaticity diagram should not be used. Stick to the u'v' chromaticity diagram.
Ok, but...
> This particular picture is one attempt at a compromise that will give readers the right conceptual impression, not “broken” accidentally.
No, the white point calculations used to make that wikipedia diagram are simply wrong. It's a recurring problem. Not a question of handling out-of-gamut colors, but of mislocating colors within it.
For instance, this fourmilab page[1] and associated specrend code, had incorrect white-point-related math for many years (the code was fixed, the page I don't recall), which IIRC, caused 'front page of the New York Times' "Universe is green"-level professional embarrassment.[2]
Here's a less bogus diagram.[3] Note the white point being close to the Planck curve, in contrast to the wikicommons diagram.
Some of the conceptual impressions seem quite unfortunate, reinforcing common misconceptions. That blackbodies (the Planck curve) can be colorful (other than red white and blue). The associated misconception that visible candle light is blackbody radiation. The extremely common astronomy education misconception that the Sun and many stars are yellow (for white points more perceptually relevant than blue Vega). A challenge in shifting science education towards more integrated and operational understanding, is so much content being variously incorrect, and thus not fitting together.
> Stick to the u'v' chromaticity diagram.
Yes, perceptually uniform color spaces are nice. Hmm, and that raises an interesting question: might incorrect diagrams be less common there? Being younger, and perhaps with open source libraries and eyeballs, replacing coding things yourself from a book, and simply copying diagrams stumbled on somewhere without checking them. A question for google image search...
[1] https://www.fourmilab.ch/documents/specrend/ [2] https://pages.jh.edu/news_info/news/home02/jan02/color.html https://www.nytimes.com/2002/01/11/us/scientists-paint-unive... https://pages.jh.edu/news_info/news/home02/mar02/color.html [3] https://tex.stackexchange.com/questions/422862/fill-area-of-...
The “color of the universe” brouhaha is amusing, but trying to assign a color to the universe is somewhat nonsensical, and the result is not really meaningful to laypeople.
I don't understand that - could you elaborate? Thanks.
Fwiw, one remediation which appeals to me, when using flawed content, is adding a "bogus" tag. As in "Figure N Mumble (source WP) Somewhat flawed." Or sometimes "Bogus <attribute or issue>". So the reader maybe gets a heads-up that there's a known issue - a "first, do no harm" thing. Modulo esthetic constraints, and I've no idea if it actually helps. And it might be phrased more accessibly. I dont know of any associated education research.
Big picture, societal-level impacts of commonly flawed content seem unlikely to improve without being addressed systemically, and so don't seem a priority focus when pursuing local excellence. For example, students are told the Sun is yellow in Kindergarten, and repeatedly thereafter, with only a few later getting an "oops, nope, our bad" in astronomy grad school discussion of common misconceptions in astronomy education content... and careful avoidance of yellow Suns in say one weather app seems unlikely to move that needle much.
Thanks for your nifty work.