Which PBR is really physically based?

gnoop

Does anyone know why   it's so different  openGL vs iRay   in both supposing to do same physically based rendering and energy conservation.   Same  Evee vs Cycles  or Octane or Arnold etc.    And only Unreal does it  more or less close to  what all offline renders do.  Mostly in its architectural  visualization template although? 

 That thing puzzles me for decade  already.     That difference mostly occurs when roughness values are around 0.7- 0.9  . In most  typical range of  outdoor materials.

poopipe

energy conservation is only a tiny part of it - all that does is ensure that you don't get physically inaccurate amounts of light bouncing back.

gnoop

It might be a tiny part but IMO it's most  visually important  part  together with a shape of highlight spot   and it's so different  in typical game render vs  every offline one.   The difference  usually just invisible on typical  shader spheres everyone  tests and demonstrates their materials on for some uncertain reason .  Imo they  are the worst  objects for that purpose.   But it's instantly  eye catchy on  every ground/terrain surfaces.     

 In that cube it's exactly how much light it's bouncing with the same roughness.    That amount of  highlight spot  spread thin on everything matte toward the sun  is  what makes a nice illumination impression  in both real life  and  every offline render.    

  I am trying to persuade our shader programmer  to tweak it to that look for years and  his reply typically  it would be not by books. physically incorrect.   

okidoki

Well.. in the end it's just a mathematical model of the real thing.. just as the older ones two.. and not every PBR is the same just by using those letters..
Finally there is also spectral renderers.. maybe even computing spectral ares you may not even see (visual perception).. and then there are color management and even color gradient..
So the question would be which combination of all those technics are used.. and don't forget the cailibration of your monitor and the luminance of the room you are watching it.. or if you are just out of bed or almost at sleep...

The question is: which "look" is the actual project following.. 

gnoop

It's not just "look"    It's what you really see midday  with a sun  50-70   degree high and  everything on the ground shows  you very subtle but still  pretty  noticeable shine  toward the sun even being spread  wide evenly  .   I tested it many times by this service https://www.suncalc.org/#/40.1789,-3.5156,3/2023.08.11/15:01/1/3

just by a photo time stamp and gps .     You always see some highlight  on asphalt for example.   Toward the sun vs opposite direction.  Under those sun angles.    It inputs a lot to  general  shadow vs light contrast  and to illumination impression. 

In a game render  it's usually  nothing at those angles already.   Perfectly flat.         IMO  typical model of game PBR  needs some curve adjusting.   Ironically you could do it in old shaders   but now it's  a holy dogma  nobody  dare to  reconsider.

 

Brandon.LaFrance

I am not an engineer, so take the following with a hefty dose of salt.

As I understand it, your typical PBR shader is made of a collection of functions/algorithms that define the way light is reflected from the surface. These functions are commonly referred to as a BRDFs. Typically, a PBR shader will consist of a separate BRDF to define diffuse and specular reflections, and a an additional Fresnel component can be used to blend between them based on certain properties such as viewing angle, IOR, etc. A shader is not limited to just these components, and it can be expanded with additional BRDFs for other material types (anisotropy, fuzz, clear coat, etc.).

Unfortunately, in order to be physically accurate, these functions can get very complex, which means they are slow to compute. Tradeoffs have to be made in order to render in real time. Typically, this means using a simpler function that is faster to compute at the expense of physical accuracy.

Its seems like its the Fresnel component that is bugging you. The simple answer is, all of these shaders are using different math as an optimization. And one of those optimizations is likely causing the differing behavior at extreme angles. A truly accurate Fresnel is expensive, so its one of the areas that gets simplified.

Some good reads if you want to learn about whats going on under the hood of these things:
https://boksajak.github.io/files/CrashCourseBRDF.pdf

https://www.jordanstevenstechart.com/physically-based-rendering

https://google.github.io/filament/Filament.md#materialsystem/diffusebrdf

gnoop

Thanks  Brandon.LaFrance   for the interesting links.   

While I do think  typical  metallic-roughness  PBR  Fresnel component doesn't work right for things like grass, asphalt , velvet etc.  Materials  made of many small particles as a whole.   In this  exact issue I believe it's GGX  component issue.   Looks like  just some power node  over  highlight spot   is on on iray side .     But I am not sure. Maybe Fresnel too.   As a start  it's also just a dot product of two vectors as far as I know.

 

poopipe

I've not poked around in the designer viewport for a while so I have to work on base principles ... 

The 'fresnel' is a function of the specular reflectance and is equivalent to IOR - it's not just an arbitrary value  and optimisations in the openGL shader could easily make it look a bit different from the much fancier Iray version. 

GGX is bad at rough surfaces - its basically designed to represent acrylic and the further from that you get, the less comfortable it is. 


With all that said, if you're trying to represent a simple surface like acrylic you shouldn't generally see a significant difference between the openGL version and iray. It wouldn't surprise me if the difference increased at very high or low roughness values and I certainly wouldn't be surprised to see a difference in the rate of change against view angle. its as brandon says - optimisations stack up 

gnoop

poopipe    it's not in designer viewport only.   Same in Painter viewport

 or Evee vs Cycles in Blender

or any random  game engine, Unity  etc .   When you try to test something having 0,7-0,8 roughness and the sun  higher than 40 degree.    Most  common range of roughness for nature produced non-metal outdoor materials and a big chunk  of dawn - dusk time interval  in games using dynamic sky /time of day.   

IMO that's why probably you see  games doing their promotional videos  with the sun around 30 degree . It just  after that  time you scene starts too look perfectly flat and matte  whatever  "physical" shaders you have.   Or you just have to fudge roughness values for a sort of compromise look.

    My guess the words  "physically based"   makes people  a bit blind  and not seeing how wrong the things are.  Not believing their own eyes .  It's a wrong  name for  game shaders imo.  

 And perhaps game shaders in general  need  some highlight  intensity  curve  tweak.   A new model  maybe.

ZacD

It kinda amazes me that at the introduction of PBR, we knew there are a lot of specular problems, but quickly fell back to eh, it's good enough.
Things like like apparent roughness getting mipped away when normal maps mip down to blurrier and smoothed over approximations of surfaces. Really apparent on landscapes, where they look way too shiny even when completely rough. The lots of directional normal details on a surface can cause anisotropic effects that also get mipped away.

pior

"My guess the words  "physically based"   makes people  a bit blind  and not seeing how wrong the things are.  Not believing their own eyes .  It's a wrong  name for  game shaders imo."

Well, while I would 100% agree that many *do* take words for granted, nothing about the term "physically based" makes any claim about the result being 100% a replication of nature. It simply means that the calculation is based on physical properties - which themselves are only an approximation of the real thing.

I actually believe that your observations would be a bit easier to follow (and could even garner some interest) if presented as well-documented and well-worded panels, as opposed to something sounding more like a rant at the clouds
After all if this is so important and noticeable to you ... why not put a bit more time and effort into it ?

gnoop

pior said:

"My guess the words  "physically based"   makes people  a bit blind  and not seeing how wrong the things are.  Not believing their own eyes .  It's a wrong  name for  game shaders imo."

Well, while I would 100% agree that many *do* take words for granted, nothing about the term "physically based" makes any claim about the result being 100% a replication of nature. It simply means that the calculation is based on physical properties - which themselves are only an approximation of the real thing.

I actually believe that your observations would be a bit easier to follow (and could even garner some interest) if presented as well-documented and well-worded panels, as opposed to something sounding more like a rant at the clouds
After all if this is so important and noticeable to you ... why not put some time and effort into it ?

Yeah, perhaps you are right .  I just have no time to  turn it into special research project.   Rather wondering if  someone might  share  same  opinion.    Or  perhaps  just to  understand a reason for  such  apparent mismatch  with what  offline  renders do and what could be a proper workaround to solve this.      

  I  am not ready to  hit my head against a brick wall  if nobody really  cares.     I just do  a sort of  compromise in roughness  values.  A bit more polished asphalt surfaces  for an expense of being too shiny at low sun.      

poopipe

its not really a matter of opinion - it's an absolute fact that these are approximations and it's openly acknowledged by the people who come up with the fast algorithms that they aren't perfect. 

Whether it's worth doing anything about is a question you have to answer yourself.

Personally, I don't think it's worth the arseache trying to perfectly match a DCC to the target renderer - primarily because even if you do have the knowledge/resources necessary you never have enough control over the DCC itself to cover all the bases. Its worth putting some effort in to get them to behave similarly but while you might be able to match the lighting model with a custom shader you're not going to be able to put your final lighting solution in there so it won't match anyway (I know because I have done exactly this more than once).
Effort is far better spent on developing ways to accelerate getting resources into the render engine so you can iterate quickly . 

gnoop

poopipe said:

its not really a matter of opinion - it's an absolute fact that these are approximations and it's openly acknowledged by the people who come up with the fast algorithms that they aren't perfect. 

Whether it's worth doing anything about is a question you have to answer yourself.

Personally, I don't think it's worth the arseache trying to perfectly match a DCC to the target renderer - primarily because even if you do have the knowledge/resources necessary you never have enough control over the DCC itself to cover all the bases. Its worth putting some effort in to get them to behave similarly but while you might be able to match the lighting model with a custom shader you're not going to be able to put your final lighting solution in there so it won't match anyway (I know because I have done exactly this more than once).
Effort is far better spent on developing ways to accelerate getting resources into the render engine so you can iterate quickly.

It's not to match  some target offline render  , rather  do what you see in reality.    It's just offline renders do it much better.   The main issue with typical  PBR workflow,   metal-roughness  at least   is that it's usually totally locked   and inflexible.    Serving the idea   of being  fool proof  so   silly low IQ artists wouldn't do anything stupid.       While in fact it's a compromise anyway . A trade off  and some materials never look quite right  with it.   An asphalt or  any 2d grass material on the ground  , anything porous  or grainy..         It's too matte  with steep sun angle and too shiny at sharp one.     Shadows   reflecting cube map  out of context  and thus often  not  contrast  enough and weird. 

I agree it never going to be perfect at all light angles  but this  locked nature deprive us of any  artistic  choice, any useful tricks  we could use . Just to follow priorities we may consider more important.       Instead what I see is a sort of mental brick wall . If PBR by books  is  not showing  something   it's the nature fault   or non existing and what you ask to tweak  is evil  hack.     While the fix is often is just one more dot product of sun and view or normal vector. A subtle correction in a word.   

I see same kind of issues with sky models.   Preetham, Hosek, Nishita   ets. They all look good in offline renders where you typically have lots of tweaks over  final result .   In games  no way , all locked  because "physically accurate"   and you see something  cyan  green  and overexposed  next to horizon   instead of gray, earthly and toned down . 

Neox

maybe one day we can free ourselves from the shackles that metal roughness workflow brings to us and can return to the glory days of specular glossiness

ZacD

Neox said:

maybe one day we can free ourselves from the shackles that metal roughness workflow brings to us and can return to the glory days of specular glossiness

We do have Substrate coming along within UE5 that seems to do a good job addressing the metalness issues, but not sure if it does anything to addresses the specular/roughness/glossiness problems. 

Alex_J

the idea of a universal standard for materials makes sense at a certain scope, I suppose.

Like you have a game like grand theft auto where one tiny artist makes an asset that has to fit into more situations than they'll be able to know. So you need to have a standard that ensures what they add conforms to the broadest possible range of circumstances.

And of course a billion people are fighting for this prestigious job and how will they stand out? Try to out-conform each other.

For a lot of games you only have a couple of situations that an asset has to exist in, so who gives a shit if material works in one area but not the other? It doesn't matter. It's still helpful to have a general standard to start from though, and tweak from there.

Neox

Alex_J said:

For a lot of games you only have a couple of situations that an asset has to exist in, so who gives a shit if material works in one area but not the other? It doesn't matter. It's still helpful to have a general standard to start from though, and tweak from there.

and this is where this entire mindset usually falls apart! because then you have artists, artdirectors, producers, marketing etc asking for all kinds of rule breaking values, to make a statement with a piece.

gnoop

Neox said:

maybe one day we can free ourselves from the shackles that metal roughness workflow brings to us and can return to the glory days of specular glossiness

While spec glossiness  could be looking  perfectly same as  metal-rough  ( if using same GGX highlight spot instead of Blin -Phong) when you add environment cube map with Fresnel    and choose  physically sound   diffuse  ,spec color  and gloss values .     Even if  the energy  conservation would be a bit off.   It's off  in modern  metal_rough too as my comparison examples show.    You could use a simple calculating table   to find proper values  and   free video-cards from lots of redundant  atmosphere heating.

     Still why return  back  when  we could do  current PBR  materials in games  just a little bit more flexible  on a scale offline renderers  do.

Neox

why? because we can't do many materials with this, and stylized stuff become even more complicated. colored highlights? mix some metal in, make it brighter to compensate! xD

gnoop

Neox said:

why? because we can't do many materials with this, and stylized stuff become even more complicated. colored highlights? mix some metal in, make it brighter to compensate! xD

That's why I do not suggest to go back to spec/glos. I just suggest to make current  PBR a bit  more flexible.  

 As of billion people fighting  , how they survived in  VFX using those unlocked  shaders before.  Looked perfectly realistic too?   Just asking.  I never had my own experience there.

Alex_J

Neox said:

Alex_J said:

For a lot of games you only have a couple of situations that an asset has to exist in, so who gives a shit if material works in one area but not the other? It doesn't matter. It's still helpful to have a general standard to start from though, and tweak from there.

and this is where this entire mindset usually falls apart! because then you have artists, artdirectors, producers, marketing etc asking for all kinds of rule breaking values, to make a statement with a piece.

well yeah i mean if one person making their own decision makes a problem for the project thats where the scope of the project necessitates standardization. I wasn't making a statement against PBR just trying to describe the need for it. but of course with standardization does come a need for discipline and conformity so people who want more creative freedom have to deal with that.

Brandon.LaFrance

I think we might be missing the forest for the trees here. The purpose of "physically based" wasn't really to create a 100% physically accurate shading model - although in that regard, it is certainly miles better than the model it replaced. 

Before we had PBR materials, we were working with diffuse color and specular intensity/gloss/color. This model had couple of huge problems beyond just physical accuracy. 

First, the specular and gloss values we were working with back then were completely abstract, and divorced from anything we were experienced with from day-to-day life. Often, you had pretty limited control over the specular color of a material. This made working with them quite obtuse. What do those values actually mean when talking about leather, or iron, or skin? And how does an artist use them to represent a given material? Additionally, these shaders were highly dependent on the lighting environment in which they were displayed. A material that looked correct in a well-lit, outdoor scene, could look completely wrong in dimly lit interior.

These two issues could make it difficult to wrap your head around which values were actually appropriate for a given material, necessitating a lot of trial, error, and frustration. These are the two major problems that PBR solves. The fact that these shaders also more accurately reflect reality is really just the icing on the cake.

The variables that are exposed in a PBR shader are based on real-life properties, and as a consequence are much more intuitive to work with. Whereas before, we were juggling abstract values with each material to try to get something that worked, PBR lets us ask a few basic questions about the material we're trying to represent (What color is it? How smooth is it? Is it a metal?), and get to a reasonable result very quickly. Add the fact that it'll work in any given lighting situation, and you've got a system that is on order of magnitude easier to work with.

And again, at the end of the day, these shaders are necessarily all just approximations. Tradeoffs have to be made to render 60+ frames per second. Hopefully, as compute resources improve, we'll see even more accurate BRDFs employed in these shaders, but you have to draw the line somewhere. If a particular shader is not meeting your needs, custom shaders are always an option, but this usually involves convincing an engineer that the performance impact and time investment are worth the result.

gnoop

Brandon.LaFrance said:

First, the specular and gloss values we were working with back then were completely abstract, and divorced from anything we were experienced with from day-to-day life. Often, you had pretty limited control over the specular color of a material

Isn't gloss a same thing as roughness?  And specular level  is an energy conservation thing .    You can    write a simple calculator for that in something like Libre office Calc to do it.  Together with diffuse color intensity.     Why at all  do it in real time?          It's beside the fact that  you just need 2-3 HDRI  emulating different lighting  conditions to find  pretty same not especially precise   values ( as my comparison shots show)  typical PBR  material does for games.

I just recollect  my  old 3d max Standard (Legacy) materials.     Have anyone ever really had issues  with them.  Or with old Mental ray shaders?   

 For sure PBR was an upgrade visually and no need to go back .  But it looks better not because it's "physically accurate"  rather simply because it uses environment  cubmap reflection  with Fresnel  dotproduct   on everything and  better shaped  GGX highlight spot .   You could do perfectly same  in that Legacy shader too if you understand  basic principles  of energy conservation.

Is it simpler with modern PBR?  Yes for sure .   Is it restrictive  and  you sometimes  spend more time  just to deceive and workaround that  "physics" mechanism to achieve desired material feature.  It sure is.   So why not accepting  the idea  it needs to be  a little bit more flexible for simple manual tweaks.  And stop to call them  physics hacks .   

 For example I am getting not enough contrast and faint shadows  on asphalt because its shiny  nature  makes it reflect too much of a sky in shadows . Especially when  cube map is static  and  out of current context  really and in reality it would be almost pitch black shadow there.        Why not do just a simple  tweak in the shader ?   Perhaps  just 2-3  tweaked shaders per location  . Everything else could be just standard PBR. 

 

 

Eric Chadwick

Sounds like you need a tweak to your shadows, and to your ambient cube map. Shadowed areas shouldn’t be affected by the key light (sun), but should still be hit by ambient (cube map) and masked by specular occlusion.

Some example screenshots would help here, in actual prototype game levels, not just single mesh shader tests. 

Otherwise it’s just a bunch of hypotheticals. Context is everything.

Eric Chadwick

GTA V screenshots