The LabPBR Consortium (doesn’t that sound just nice?) just validated the 1.3 standard of the LabPBR format. The only difference with 1.2 being that the f0 value is now stored linearly (much like Continuum shader has been decoding that value for a while now, despite the LabPBR standard specifying the F0 being stored as sqrt… 😉 )
I mostly use what we call “albedo-based f0” in Vanillaccurate, meaning the real f0 value is being decoded from the albedo RGB color, but in some cases I also use hardcoded metal values. Those hardcoded values are specific values for f0 which shaders are supposed to interpret all the same way. For example, a value of 230 represents iron, whereas a value of 231 is interpreted as gold. There are a fair number of those hardcoded metals but I only use a few of them.
I also decided to use more accurate f0 values for non-metals (AKA dielectrics), and I went looking for the correct values for materials such as diamond. That’s why for example my diamond f0 is not very low (most dielectrics) nor very high (most metals) but somewhere in-between, as real diamond is supposed to behave. Thing is, I just noticed I *didn’t* store those values using sqrt but linearly… which means that Vanillaccurate is in fact… already LabPBR 1.3 compliant. I will possibly ajust the converters to allow conversions to 1.2 (which means basically applying sqrt on the _s green channel) but right now, you can consider Vanillaccurate to be 1.3 compliant.
Good news, isn’t it ? I have a bit of blocks whose AO still needs adjusting, but the first complete release should come quite soon and comply to the latest LabPBR standard !
One thought on “LabPBR 1.3 standard validated”