Author Topic: dubcats secret little hideout  (Read 264344 times)

2019-01-13, 15:48:42
Reply #345

Fluss

  • Active Users
  • **
  • Posts: 553
    • View Profile
I also want to add that to transpose real-world scene referred data to render scene referred data, you'll at least need to thoroughly stick to energy conservation AND preservation principles. And in that way, Corona is really far from producing accurate results.
Indeed, as roughness increase, we're losing an insane amount of energy. I've made a quick furnace test to check that out we're losing close to 50% 60% energy at high roughness values (well we cannot completely disable fresnel, but that's close enough to see the issue). Even if it still not perfect, Fstorm did a way better job on that side (It actually produce more energy than what it received but the gap is smaller tho).
« Last Edit: 2019-01-16, 14:47:17 by Fluss »

2019-01-13, 15:55:40
Reply #346

bluebox

  • Active Users
  • **
  • Posts: 268
    • View Profile
I'm not that much of a tech guy, but I really appreciate super much and respect you guys for sharing all that knowledge here and moreover developing your studies.

Once more I think you should reach out with your findings to the team so the shader that (I hope) is being developed will be as good as it can be.

A question Fluss - lets say we have a very long and narrow room with a window on one end. Does what you imply - that Corona does a poor job at maintaining the energy conservation rule - mean that it will be darker at the other side of the room than let's say in Fstorm (of course with the same camera exposure etc.) ?

2019-01-14, 13:40:40
Reply #347

Fluss

  • Active Users
  • **
  • Posts: 553
    • View Profile
A question Fluss - lets say we have a very long and narrow room with a window on one end. Does what you imply mean that it will be darker at the other side of the room than let's say in Fstorm (of course with the same camera exposure etc.) ?

I guess it shouldn't affect light propagation that much but rougher materials will appear brighter so overall you should have the feeling that light goes a bit further yes.

what you imply - that Corona does a poor job at maintaining the energy conservation rule

To clarify, Corona team does it the right way and that's totally expected for a single scattering BRDF. That's one of the drawbacks of this kind of implementation. It looks like they've implemented some energy compensation tech for the transmission part already as it doesn't seem to darken when the roughness increase (have to be checked tho, I've made some quick tests a loooooong time ago). And I guess they tried to solve the issue on the specular part and that it was the reason why the glossiness range got fucked up before v1.5, as disabling the PBR checkbox in the shader produces a near perfect furnace test (except edge darkening/brightening).
So basically, it would be really nice to get energy preservation for both specular and diffuse lobes.

You can look at this video to see the phenomenon involved (a lot of the examples are on the transmission lobe, but it's the same for specular and diffuse lobes):


I've already submitted the idea a long time ago and devs checked it and told that this would introduce a massive overhead. But it looks like Sony Imageworks did a pretty decent job to solve that issue and I think that's worth considering. Notice that I've made the distinction between energy conservation and energy preservation. Even if it seems a bit cumbersome, that's how they've described it in their presentation and it's finally a pretty way to focus the incriminated phenomenon.

Have a look at their presentation for more info: https://blog.selfshadow.com/publications/s2017-shading-course/imageworks/s2017_pbs_imageworks_slides_v2.pdf

Also, Stephen Hill made interesting Blog posts on the subject :

« Last Edit: 2019-01-16, 15:13:37 by Fluss »

2019-01-14, 14:25:36
Reply #348

Fluss

  • Active Users
  • **
  • Posts: 553
    • View Profile
Here is an example :

0.9 glossiness :



0.1 glossiness :



As you can see, we're losing an incredible amount of energy here. I'll let you guess the impact of such behavior on an interior render.
« Last Edit: 2019-01-14, 14:35:35 by Fluss »

2019-01-14, 15:37:14
Reply #349

pokoy

  • Active Users
  • **
  • Posts: 1850
    • View Profile
Wait, so this happens not only for refraction but reflection, too? Heck, it almost hurts physically. I wish we could settle the BRDF shortcomings for good rather sooner than later.

2019-01-14, 15:53:07
Reply #350

Fluss

  • Active Users
  • **
  • Posts: 553
    • View Profile
Basically, every micro-faceted BRDF so diffuse, specular and transmission (including clear coat, thin surface etc etc..). We know new shader is gonna come soon so maybe this will be addressed at some point. That would make Corona an absolute killer TBH.
« Last Edit: 2019-01-14, 16:14:55 by Fluss »

2019-01-15, 16:25:47
Reply #351

Fluss

  • Active Users
  • **
  • Posts: 553
    • View Profile
Here is a more practical example demonstrating the difference between GGX and multiscatter GGX implementation of the blender's Disney principled BRDF


2019-01-15, 23:47:52
Reply #352

arqrenderz

  • Active Users
  • **
  • Posts: 990
  • https://www.behance.net/Arqrenderz1
    • View Profile
    • arqrenderz
Dubcat has a website??? where??!

"I have a whole page dedicated to factory paints on my new site (still in beta),"

2019-01-16, 00:25:27
Reply #353

dubcat

  • Active Users
  • **
  • Posts: 425
  • ฅ^•ﻌ•^ฅ meow
    • View Profile
Do you have a link to your site perhaps?

Hey!

There are still a couple of pages I need to write before the site goes public.

Here is a little preview of the calibrated paint page.



It's one thing to calibrate swatches to real world LRV, but the most important step is to remove IOR.
IOR really de-saturates colors (If they are middle dark++). Everyone will notice this the first time they cross specular scan something.

LRV = Value in Corona Color Picker and this value is linear. It's just plain stupid that the "sRGB" check box does not affect Value in "Corona Color Picker" yet.



Maybe you could reach out to the team ?

Hey!

Ondra and the dev team have direct contact to me, so if they ever need anything they know I'll be there.

Hey Dubcat, can you elaborate about this? I'm not sure I get it.

Basically you're asking a slot to input cross polarized specular scan in order to modify the microfacets distribution, is that right?

Hey man!

I want to merge Glossiness/Roughness and IOR/Specular into one map (aka Roughness/Glossiness, it will not degrade the current real world scanned material PBR system in anyway, only improve it). Because we are already 50% there. The lower pbr glossiness value we use, the lower the IOR gets, but this is a global change. The glossiness IOR change does not go above or bellow the initial value (If we use asphalt as an example, it does not respect gem stones in the scan, or micro shadows. Micro shadowing is the #1 error that has to be fixed in CGI imho beside Coronas diffuse roughness ( ͡° ͜ʖ ͡°) ), but kinda act like reflection level did before pbr. Like when you change the opacity of a layer in Photoshop.

I made a quick and dirty proof of concept material for you guys, to show what I mean.



I don't know if the Corona Curve settings get saved with the material preset, I guess so. But just in case, here is the curve.
We really need X/Y value inputs in Corona Curve!



edit: Fixed a mistake in the material.

I also want to mention that the super blurred texture in the "High Pass" section has to be Corona Bitmap with 9999999442119689768320106496 Blur value. 3dsmax bitmap can't blur this much.
We really need a "gaussian blur" function in one of the Corona maps, I made a request on mantis a year or so ago. This feature is the only thing that is halting my mask generator, because we have to gaussian blur procedural maps.
« Last Edit: 2019-01-16, 02:02:03 by dubcat »
             ___
    _] [__|OO|
   (____|___|     https://www.twitch.tv/dubca7 / https://soundcloud.com/dubca7 ( ͡° ͜ʖ ͡°) choo choo

2019-01-16, 14:32:31
Reply #354

Fluss

  • Active Users
  • **
  • Posts: 553
    • View Profile
OK dubcat, got it, thanks!

I have a few questions :

From my test, corona seems to map the value as 1/IOR only when the input is below 1 (so in the sRGB range). Every value above 1 seems to be treated as a proper IOR value. So if you're inputting 1.5 linear value in the Fresnel IOR slot, you should end up with the right result. That's actually quite smart as the lowest IOR value of 1 (linear) is the highest value in sRGB range (255=1.0). So 1.0, the only common value of the two range( [0,1] ; [1,999] ) give the same result (1/1=1). It works with a corona color plugged right into the fresnel slot but as far as I try to mix two linear values together, the IOR is completely messed up, despite the fact that the "perform mixing in sRGB space" checkbox is unticked. Do you have any insight about that? That's totally freaking me out! It would be so much easier to work with linear data directly..

Also, don't you think the glossiness darkening induced by single scattering GGX is kind of a blocker here? I mean, when I look at a linear RAW DSLR picture, it's really flat. We are loosing up to 60% energy on low glossiness values, which bring a lot of contrast (not to mention that it's physically nonsense). If we're aiming at photorealism, especially using real scan data, this phenomenon should have a pretty big impact here.

Finally, as you said, Micro shadowing most of the time overlooked. If it's not that much an issue on close up shots like in your examples but as soon as we move away, filtering comes to action and we're loosing all the micro détails when using bump/normal and micro-displacement maps, resulting in a flat/plasticy render. So translating bump/micro-disp/normal map to microfacets is a must have too. It can also be declined to solve some artifacts introduced with normal mapping with BDPT algorithm (Bump/normal mapping is not reciprocal). And that's what bump to roughness does with no negative impact on render time. These examples speak by themselves :

Bump to roughness :



Normal to roughness :



Regular bump :



Bump to roughness :





Quote from: PIXAR link=https://renderman.pixar.com/stories/cars-3

"We noticed a significant improvement on environment detail, especially surfaces such as concrete and marble,"


Quote from: PIXAR link=https://renderman.pixar.com/stories/cars-3

"Typically with Marble, we try to avoid a glassy look, where the marble is too shiny. With Bump-Roughness we were able to capture all the subtle imperfections that give marble its most distinctive properties,"


Quote from: PIXAR link=https://renderman.pixar.com/stories/cars-3

"The benefits don't stop there, as previously mentioned, Cars 3 saw huge improvements in render times. Bump-Roughness is over 35% faster than bump alone"

« Last Edit: 2019-01-16, 17:56:38 by Fluss »

2019-01-16, 14:42:25
Reply #355

Fluss

  • Active Users
  • **
  • Posts: 553
    • View Profile
Also, have you tried to change the exposure between renders with the node graph you provided plugged in the IOR slot? Render->Lower exposure by let's say 2 stops->re-render. I have some weird inconsistent results under different exposures here. Everything is fine when you generated IOR map is unplugged. Let me know if you observe any issue or if it is on my side.
« Last Edit: 2019-01-16, 15:07:34 by Fluss »

2019-01-24, 00:55:43
Reply #356

dubcat

  • Active Users
  • **
  • Posts: 425
  • ฅ^•ﻌ•^ฅ meow
    • View Profile
Hey Fluss!

"perform mixing in sRGB space" checkbox is unticked. Do you have any insight about that?

I tried 2 multiplied with 0.75 and 1 pluss 0.5 and they seemed to give me 4% IOR. I used the latest Daily Build.
I use the 1/IOR method in my Substance Designer generator since my maps will work in multiple render engines. This proof of concept was based on that generator. For people who are reading this later, feel free to simplify the material with pure float values as Fluss mentioned.

single scattering GGX is kind of a blocker here

When I generate my IOR maps with my Substance Designer generator, it takes into account the global PBR IOR reduction (glossines value). So it only enhances the micro shadows or gem stones in the material. If a 4% flat material has 3% because of the PBR glossiness, it will still be 3% when you use the IOR map. This is something Corona could do behind the scenes, since they know what IOR and Glossiness value we are using in the material.

Finally, as you said, Micro shadowing most of the time overlooked.

For sure!

Bump/Normal to IOR is kind of inferior to "Cross Polarizing" to IOR. Since it is only height based and not specular, (while Cross Polarizing also takes height into account, if we use scanned data), but I would not say no to a height based feature in our current state.

Megascans official specular maps are generated from normal maps, and they kinda have this flat plastic feel that you are talking about (I always associate this feel with Elder Scrolls Oblivion). The next major Quixel Bridge update will include my Roughness to IOR LUT + my latest script for Corona (Metal and Fabric support). Corona is the only engine that support all this stuff, because we have devs that actually listen to user requests.

Here is an example from my generator with roughness and normal map as input, you can see the plastic feeling you get from normal maps (height to IOR).



Also, have you tried to change the exposure between renders with the node graph you provided plugged in the IOR slot? Render->Lower exposure by let's say 2 stops->re-render. I have some weird inconsistent results under different exposures here. Everything is fine when you generated IOR map is unplugged. Let me know if you observe any issue or if it is on my side.

I generate all my maps in Substance Designer, this was only a quick port to 3dsMax as a proof of concept. Maybe Corona Curve map has the same issues as the LUT map had before ? I hope not :( I can do some tests later this week, if you don't want to.

EDIT:
I've added a Photoshop action script that convert normal maps to height info. You can then plug this into the highpass chain in my proof of concept material.
« Last Edit: 2019-01-24, 01:05:11 by dubcat »
             ___
    _] [__|OO|
   (____|___|     https://www.twitch.tv/dubca7 / https://soundcloud.com/dubca7 ( ͡° ͜ʖ ͡°) choo choo

2019-01-24, 14:15:34
Reply #357

Jpjapers

  • Active Users
  • **
  • Posts: 1644
    • View Profile
How do you have such knowledge of the technical aspects of lighting and shading? Id like to have a deeper understanding of it and wondered if you could recommend any resources?
Im warming to the idea of being a Lighting/Shading TD at some point in my career as i really enjoy the technical side of the industry. Any recommendations would be very much appreciated!

2019-01-24, 16:25:30
Reply #358

Fluss

  • Active Users
  • **
  • Posts: 553
    • View Profile
For people who are reading this later, feel free to simplify the material with pure float values as Fluss mentioned.

There is a really strange behavior I cannot explain. After further testing, it looks like it's the 1/IOR part that not working here. On the render result at least as the material preview and the rendered material do not follow the same behavior. Here are some examples demonstrating the issue :

No IOR map plugged (IOR 1.5 in the material) :



1.5 IOR linear float corona color plugged in, work as intended :



Mixing 1.1 to 1.8 linear float using your node graph, the material preview is fucked up but render looks fine to me :



Mixing using the 1/IOR method, the material preview looks fine but render does not :




I have the feeling that there is some weird gamma related stuff behind that.


For the glossiness darkening and for the plasticy bump feeling, I'm not sure we are talking about the same stuff (see my previous posts).
« Last Edit: 2019-01-24, 17:31:30 by Fluss »

2019-01-25, 02:02:26
Reply #359

Fluss

  • Active Users
  • **
  • Posts: 553
    • View Profile
Hey dubcat,

Looks like the exposure inconsistency is related to the gamma 2.2 part in the IOR mask generation. Why did you choose to perform those operations in gamma 2.2 to put it back into gamma 1.0 afterward? To my knowledge, playing with gamma while performing arithmetic in a node tree that is supposed to be plugged in a linear input always end-up in a bad way, especially with data as sensitive as IOR.
« Last Edit: 2019-01-25, 02:20:19 by Fluss »