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!
Is there a reason why the convolution happens only up to Mip 6 and not further? Even though more mips may be available.
I guess it’s because the shader itself only cares for up to Mip 6, so no reason to do the extra calculations, but…
Why does the shader only care for up to Mip 6? All probes have at least 7 and higher resolutions have even more.
While compatiblity with things like substance painter/designer has improved GREATLY, it seems that those packages can do much rougher surfaces.
It seems a 0 smoothness value in Unity, is more or less equal to a 0.6 roughness value in substance painter and painter is able to produce much rougher reflections and surfaces. I thought it was a limitation of the reflection probe, since you have a limited number of mips and you can only convolve that far, but it seems that there are mips available that could be used and they just… aren’t.
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).
Regarding mobile, I would suggest that mobile be available to desktop without having some “automagic” switch on unity’s end, or a way to easily override this as many of us are on console, forward rendering and so on for VR purposes we need the speed - in any case this is great news, thank you.
The brightness thing that I reported in another thread, is actually that in very rough values, Substance uses a very very blurred environment so the lighting has evened out completely and in my example that meant from that angle, it looked darker.
But let’s clear up the issue:
Unity, Color White, Metallic 1, Smoothness 0.
The probe used is 512, Baked, HDR. Mip 6 looks exactly like the sphere in my scene.
Now let’s switch to Substance Painter.
Substance Painter, Color White, Metallic 1, Roughness 0.6
Roughness 0.8
Roughness 1
(I’m using medium (16spp) quality for substance)
Yes please, this is also really important for us. Also currently there is an additional problem where you create a custom surface shader using the PBR lighting function this will always use the high quality PC settings becoming a no way to go on mobile.
@mortenm I am still waiting for a case number to my bug report. It seems the server that processes bug reports has some issues. If you don’t have the hdr map I think can upload it somewhere and send you a PM.
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.
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.
A physically based normalized phong is about the same cost as a physically based ggx.
We already have simplified brdf models for low-end mobile (have for a long time).
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.
But your shot of Unity beta 5 is also much “flatter” than what I was getting. What is the size of the reflection probe you are using in Unity? If it’s too low, it naturally gets blurier because there are simply not enough pixels in Mip 6.
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+
