Switch to GGX for both ibl and conventional lights!

We have now switched to GGX for both image based lighting and for
conventional non ibl lights!
Furthermore this release provides a major leap towards greater accuracy and
parity between Unity and the 3D views of several existing content creation
tools (when viewing the same content). Smoothness maps in particular are
very closely matched now!

As a downside our new offline convolution is currently slower than the
original but we have significant improvements to this in the pipes as I
write this!


Morten S. Mikkelsen.

 

>It seems a 0 smoothness value in Unity, is more or less equal to a 0.6 roughness value in substance painter

This is not what we have seen in our own testing. In terms of blurriness it has been a match across the entire range. Can you provide an example? One thing I am aware of is the brightness at the very rough values but by the time we had this ready experiments had already been done comparing gamma vs. linear space cases and trying to match them up. So for now we've held off on bringing this into 5.3.

There are many good reasons why we have chosen to not use more mips. First off quality wise cube mips below a certain resolution are useless for ibl. There isn't any point to using 1x1 and 2x2 because they look quite bad. Another less known issue is on various high-end graphics cards sampling the very bottom mip levels of a cube map is excessively inefficient.
My preference would probably be to never start lower than 8x8 which in my experience is visually the best one to start from
but performance wise, particularly taking mobile into account, it was more efficient to use a fixed constant as the range of mip maps (which was also the case in 5.2).

 

Could you provide this as a unity project I can test?

Have you tested your content in something else like toolbag2, v-ray, cycles in blender etc?

 

For now I guess all I really need is the hdr map. What's the name of the hdr map? I may have it already.

 

I've been out for a couple of days so my reply is a little late. Anyway here is what I have to say.

I ran the same scenario through cycles in blender and I did a shot in 5.3b5 and one using the darkness term I described in the beginning. Keep in mind this is a very extreme case since we're talking a metal surface with maximum roughness. The difference in brightness when applying the term is significantly less for more typical metal reflections where roughness is not set to maximum.

unity beta5, unity with darkness term, cycles:




As you can see in cycles it doesn't turn completely flat.
The middle shot of unity with the term applied is of course not completely identical to cycles but the reason there's a difference is because of pre-convolution where you are forced to assume the normal aligns with the view vector in your pre-convolution process. I have compared results to other viewers that use pre-convolution and they look the same under the same condition.

My interpretation is there is no bug here in terms of ihow roughness is read (blurriness wise).
It's primarily down to pre-convolve vs. on the fly integration like in SD and TB2.

Does this help?

In regards to the questions about performance. This change should not cause any additional cost in performance for the following reasons.

1. A physically based normalized phong is about the same cost as a physically based ggx.
2. We already have simplified brdf models for low-end mobile (have for a long time).
3. Many of the changes were on c++ side and done to the convolution process.

That being said we do of course pay close attention to any changes in performance and I will confirm with people here as well.

Thanks,

Morten

 

Those shots were with 512 but it looks very similar at 256x256. At 128x128 you are correct there's no longer enough pixels to sustain a reflection that rough. So if you like it rough go 256+

 

Did you handle this skybox in any way in photoshop? Did you import it and re-export it from photoshop? Maybe even change it in some way?