GGX / maximum roughness compared to vray ?

[Nicolaswi]

Hi,

I'm working on various converters for Substance Designer/Painter, we'd like to provide users the ability to export maps for various renderers.
I made a first one for vray, it works very well and I now want to adapt it to corona.

I first had a problem with the ior texture: in vray the [1, 100] is remapped in the [0, 1] by simply doing 1/ior. It's really convenient as it allows the usage of a texture quite easily. In corona, even if a texture input is supplied for the ior, it seems it's stuck at 1. So I found a work around: I put a "CoronaMix" and made 1 Divided by my "1/ior" texture, to get the ior value back. it works! but it'd just be more convenient if you did the same trick as vray ;)

Another problem: the glossiness. Eventhough you say you have GGX implemented, it looks like you have applied a curve on the glossiness.. It can't produce as rough surfaces as it should when glossiness = 0.

In Substance Designer/Painter, we have implemented GGX without any changes from the paper, Chaos probably did the same because their glossiness really matches ours. But Corona seems very different..

This is the same setup, the material is
- diffuse black
- reflection white
- ior 100
- glossiness 0
- (ggx in vray)

Corona:


Vray:

[dubcat]

I hope this can get sorted out somehow.
I use Substance Painter/Designer for everything non-Corona related, would be awesome to have that power inside Corona.

Chaosgroup shared some GGX documentation here

[Jarda]

Hi Nicolaswi,
yes, we do apply a curve to the glossiness parameter. The reason we did this was that we wanted a given glossiness value to produce similar look in the old BRDF we used previously and in the new GGX one. A consequence of this is that the range of roughness is indeed limited by this remapping and you are right that we do not cover the entire range of roughness of the GGX BRDF. This is not a limitation of our GGX implementation, only a consequence of the curve applied to the glossiness parameter before it is fed to the GGX BRDF.
I can provide you with the curve so you can use in the converter but that will not solve the problem that we do not cover the entire roughness range. Is that a problem in practice? As far as I know, so far no one needed a GGX BRDF that would be rougher than the one that corresponds to our glossiness=0 setting. (Also, from a physical point of view, this does not make much sense because the physical validity GGX BRDF model is questionable for extreme roughness values - but I know, who cares in practice.)
Cheers,
Jarda

[dubcat]

I can provide you with the curve so you can use in the converter

Could you share it with DeadClown? The current material converter is way off.

[Ludvik Koutny]

Hi Nicolaswi,
yes, we do apply a curve to the glossiness parameter. The reason we did this was that we wanted a given glossiness value to produce similar look in the old BRDF we used previously and in the new GGX one. A consequence of this is that the range of roughness is indeed limited by this remapping and you are right that we do not cover the entire range of roughness of the GGX BRDF. This is not a limitation of our GGX implementation, only a consequence of the curve applied to the glossiness parameter before it is fed to the GGX BRDF.
I can provide you with the curve so you can use in the converter but that will not solve the problem that we do not cover the entire roughness range. Is that a problem in practice? As far as I know, so far no one needed a GGX BRDF that would be rougher than the one that corresponds to our glossiness=0 setting. (Also, from a physical point of view, this does not make much sense because the physical validity GGX BRDF model is questionable for extreme roughness values - but I know, who cares in practice.)
Cheers,
Jarda

Actually there were quite a few people needing more roughness range, at least to the lambert diffuse point. But they all settled on the fact it was limitation of used BRDF at the time. So it's not that no one needs it, it's just that everyone learned to live with what was there before. But now that we have finally good BRDF, there is not much excuse left to have limited roughness range. It will definitely be needed in future once PBR texturing standards settle in.

[romullus]

[...]

Actually there were quite a few people needing more roughness range, at least to the lambert diffuse point. But they all settled on the fact it was limitation of used BRDF at the time. So it's not that no one needs it, it's just that everyone learned to live with what was there before. But now that we have finally good BRDF, there is not much excuse left to have limited roughness range. It will definitely be needed in future once PBR texturing standards settle in.

+1!

[dubcat]

What about removing the curve and have a legacy option (or just remap the values) for older scenes ? Would make everything easier if Corona used the "universal" GGX that other programs use, right now we have to adjust the glossiness maps in Corona. It's the only thing that really bugs me.

[Nicolaswi]

I think in practice you can need it and it'd be a lot easier if everyone out there use the same convention.
Also it means that you can't convert Vray 3.2 materials that have specific glossiness values (and use GGX).

So, yeah, I think getting rid of this curve would be a good idea :)
Until then, if you can give me information on the curve, it can help me making the correct conversion in my filter, thanks!

[somedoggy]

+1 to increasing the roughness range. To add to this, and something I mentioned on Polycount, I noticed that displacement was causing surfaces to appear overly glossy for me. Could just be a perceptual thing, but it seemed to intense to just be that. I'll try to put together a test based off what I was doing before, but I'm on the free alpha version of Corona now so it may be different.

I'd like to hear more about the mention that the high roughness ranges aren't physically plausible for GGX.

[Ondra]

I'd like to hear more about the mention that the high roughness ranges aren't physically plausible for GGX.

For any BRDF I know of. Designing a BRDF function with reasonable shape that is physically correct (meaning properly normalized, symmetrical), flexible (going from mirror to diffuse), and efficient (meaning it can be sampled reasonably closely and efficiently evaluated) is actually pretty hard.

What is usually done is some kind of approximation that is "close enough" on the physical correctness side. It usually works well for nearly-mirror surfaces (it is much easier to design a function that looks almost-mirror), but when going more diffuse, the whole thing just goes bonkers. This was the case with previous BRDFs in Corona, which is why the minimal glossiness was cut off a bit. I dont know how badly GGX blows up on near-diffuse end though. Not blowing up in vray does not mean there are no problems with GGX generally, they could have done further research, some masking hacks, or it could blow up in a way that is usually not visible (as did some previous Corona BRDFs)

[somedoggy]

I'd like to hear more about the mention that the high roughness ranges aren't physically plausible for GGX.

For any BRDF I know of. Designing a BRDF function with reasonable shape that is physically correct (meaning properly normalized, symmetrical), flexible (going from mirror to diffuse), and efficient (meaning it can be sampled reasonably closely and efficiently evaluated) is actually pretty hard.

What is usually done is some kind of approximation that is "close enough" on the physical correctness side. It usually works well for nearly-mirror surfaces (it is much easier to design a function that looks almost-mirror), but when going more diffuse, the whole thing just goes bonkers. This was the case with previous BRDFs in Corona, which is why the minimal glossiness was cut off a bit. I dont know how badly GGX blows up on near-diffuse end though. Not blowing up in vray does not mean there are no problems with GGX generally, they could have done further research, some masking hacks, or it could blow up in a way that is usually not visible (as did some previous Corona BRDFs)

I remember reading at first they had a problem with it blowing out for rough surfaces, and if I remember correctly it was due to their shadowing-masking function. This paper outlines height-correlated shadowing and masking, which is a pretty good solution to balance that out: http://jcgt.org/published/0003/02/03/paper.pdf
Page 75 Eq. 99
I believe the best form though is Equation 101 on the next page. Since I'm not sure how the sampling or brdf in Corona work in code I can't really speak on being properly normalized otherwise. Could be a number of things. It would be really cool to have references for these types things to ensure people are getting the best results from their workflows. Also I wanted to pitch an idea, if it hasn't already been implemented. There are normalized functions out there for burley diffuse which would be a cool brdf option for Corona :) When balanced properly the resulting soft brightening of a rough surface's diffuse is very nice.

Edit: I found their post https://labs.chaosgroup.com/index.php/rendering-rd/improvements-to-the-gtr-brdf/

[vkiuru]

Actually there were quite a few people needing more roughness range, at least to the lambert diffuse point. But they all settled on the fact it was limitation of used BRDF at the time. So it's not that no one needs it, it's just that everyone learned to live with what was there before. But now that we have finally good BRDF, there is not much excuse left to have limited roughness range. It will definitely be needed in future once PBR texturing standards settle in.

This is 100% the case here. I posted about it way back: https://forum.corona-renderer.com/index.php?topic=2666.0 and have since settled to avoiding the whole thing.

[Ludvik Koutny]

Well, there are at least 3 different renderers i know of employing GGX which does not blow up at diffuse roughness, so it's fair to assume GGX is safe in this way. Or all of them managed to do their own BRDF fix to get it working. If they could, there's no reason we shouldn't. Renderers are starting to unify in this way, even realtime engines, like unreal engine. Sooner or later there will be one roughness standard with one curve, so the sooner we support this standard, the better.

[vkiuru]

Yeah, hope so. I haven´t used Vray in two years now so my memory of the shading models is from Vray 2.x era and there are huge differencies there but I tried to avoid comparing to 2.x since I´m pretty sure things have changed with the release of v3.

[Juraj]

Hah interesting, I defininitely remember having that discussion here :- ).

It's not big issue, but comparing to Unreal4, I expected Glossy=0 to really become quite diffuse, which it wasn't with the original model in Corona and improved with GGX, but just not in way as expected. It's true it doesn't match to elsewhere,
and perhaps only seemingly (actually might not be direct consequence, though I thought there is) forces me to lower reflectivity where I wouldn't want otherwise for more rough materials.

(Vray had sampling issue the low tail parameter rather than low glossiness )