Minor bug in PBR Workflow example code

📚 Official Books Metal by Tutorials
1

You have…

if let roughness = material?.property(with: .roughness),
   roughness.type == .float3 {
     self.roughness = roughness.floatValue
}

I believe that should be roughness.type == .float which wouldn’t be an issue when there’s a texture present. Correct me if I’m wrong. Relearning Swift at the same time.

Best,
~chuck

1 Like
2

@cocheret

Even though it’s a grayscale value, Model I/O expects the roughness property semantic to be a float3.

You can test this in final by editing cube.mtl. Put a # in front of map_roughness etc, and add the new property:

roughness 1.0 1.0 1.0

(That’s white.)

In PBR.metal, after loading roughness in the fragment shader, add return roughness;.

That will make the cube white.

If you then change float3 to be float in Submesh, and in cube.mtl change roughness 1.0 1.0 1.0 to roughness 1.0, the cube will render in black.

Alternatively, you could simply print out the value after reading it in Submesh of course.

Note: I realised this anomaly in Model I/O fairly late on, and sadly it doesn’t look like the .float3 correction made it to the sample code.

1 Like
3

Thank you very much for this post and the response. I understand now why I had problems with roughness and metallic (metallic has the same problem). Now it works fine. :grinning:
Thank you also for PBR references.

1 Like