Perhaps this is just me but it appears that in Muse Texture 0.3.1, the PBR texture generation of textures that have materials of differing metalicity / roughness causes problems in the generation of the metallicMap and roughtnessMap.
Material properties that Muse Textures understands with isolated materials (gold, marble, …) are no longer understood when combining them. Interesting enough the non-PBR base map would look correct (or at least more correct)
I’m using the URP sample project to have a well understood and well defined setup.
Prompt: polished gold

The polished gold looks as I would expect both from the base map and from it being gold

Prompt: marble, polished gold cracks
Issue: The gold is no longer reflecting light the way it should. The roughness needs to be turned down to a value well below 0.3 at which point the marble looks like plastic. The base map still looks correctly.

See how the PBR looks dull and wrong

While trying to find a way to work around it using import settings I realized that at this moment at least, the metallicMap and roughtnessMap, despite being grayscale and used as 1D input in the fragment on the URP graph, are not in fact contained to a single channel.
Is this desired, despite it preventing texture packing of AO + Roughtness + Metallic?
Based on my test, the 2 maps must at least be RGB24 to retain their look, with less than that they are negatively impacted on their PBR representation.
Roughness SingleChannel Alpha / Alpha8

Roughtness SingleChannel Red

Metallic SingleChannel Alpha / Alpha8

Metallic SingleChannel Red

This is less extreme but still a visible difference in brightness and the shadows when compared to the original from above

Also perhaps a request: Could the generated PBR textures be named correctly? Right now I feel like baseMap and diffuseMap are creating confusion especially because the MuseMaterial calls the slot BaseMap, expects the diffuseMap which probably both should be called AlbedoMap.
I realize that would be inconsistent with Unity’s normal shaders so it would probably make sense to at least have the Albedo in the baseMap instead of the diffuseMap and find a better name for the current baseMap that does not create conflicts in the domain glossary.
