Should the GLTF loader separate roughness and metallic

[Not-Nik]

GLTF and by extension GLB files support embedding various textures including data for PBR roughness and metallic channels. That data, however, is internally stored in a single GB texture (green is roughness, blue is metallic FWICT from looking at blender shader nodes). While raylib supports loading GLTF files, it simply puts the texture into its MATERIAL_MAP_ROUGHNESS slot.

Now, the question is, should this texture be separated into two textures on load-time? This would add to memory consumption, albeit only during loading, as the Images would be immediately deleted, and two R8 textures should take roughly the same VRAM as one RG8 texture (±overhead for metadata depending on the driver). Additionally, the process would take longer overall, just to copy all the data around (I can't think of any smart ways to separate these channels, either on the CPU or while uploading to the GPU). On the other hand, this would be much more inline with how raylib's material system is already designed, and be much less confusing when you first start out loading PBR models.

I understand the implications of such a change, and my use case would actually allow that I simply do this on my end, but I feel like this would also benefit other members of the raylib community. Any thoughts?

[dc1248]

Nope, the texture should be left in the roughness slot and handled by your PBR shader, as in Raylib's shaders_basic_pbr example.

Game engines typically use an "ORM" texture which is Ambient Occlusion, Roughness, and Metalness packed into the RGB channels. Raylib's PBR example uses an "MRA" texture packed in the opposite order; switch .b and .g in the shader to use ORM. For models without an ORM texture you could set the roughness texture to rlGetTextureIdDefault() and adjust the ao/roughness/metalness shader uniforms.

(@raysan5 - would you like me to submit a GLTF+ORM version of the PBR example?)

There's a trick mentioned in the Blender GLTF exporter documentation to export ORM textures. You need to enable "Shader Editor Add-ons" in the preferences for the "glTF 2.0 format" addon. Then in the shader editor you add a "glTF Material Output" node and connect the red channel to it, like this:

[Not-Nik]

This has already been changed in #4739

[dc1248]

Oh thanks. Then we may need a followup patch to not do that when the GLTF file specifies an ORM texture.

I think we definitely need a GLTF+ORM example... I'll just do it.

[Not-Nik]

Actually, I think it is good the way it is right now. Raylib is not an engine, and focuses more on ease of use, rather than squeezing out raw performance wherever possible. The on-disk size stays the same regardless, and the performance impact is negligible.

[dc1248]

I think it was good before. I'm using ORM textures just fine without any modifications to Raylib 5.5, which doesn't include PBR support except in the shaders_basic_pbr example.

You're just using an ORM texture without an Occlusion channel. Can't you do what you need in your shader?

[Not-Nik]

This makes GLTF files behave the same as any other format, so one shader can be used for all files. That's why we have the clearly defined texture slots. Ultimately, Ray needs to decide, though.