As a Roblox developer, it is currently very difficult to distinct between the functionalities of MaterialVariant and SurfaceAppearance, as well as intuitively utilize these features for UV mapped meshes in Roblox.
As of now, MaterialVariants exist as a generic method to apply materials to any geometry, with no UV mapping needed out of the box. This is great, but the problem comes when a developer wishes to apply materials to a UV mapped object.
This is where you’d use a SurfaceAppearance, and all would be solved. The problem with this is the non-ideal and unclear workflow introduced via this behavior. Developers will frequently encounter confusing behavior because intuitively, what they want is to apply materials to geometry that tile without seams. This is not the behavior encountered, however. You must create a SurfaceAppearance object and use this to represent a “material” on an object that has been UV mapped.
This leads to situations where materials must be represented by hundreds or thousands of nested SurfaceAppearance objects inside your DataModel. Take for instance, the idea of making a “Leaf” texture for your game’s trees.
As a result, updating these SurfaceAppearances is no longer as intuitive as updating materials. Developers will likely need to integrate some form of command-line code or plugin to swap SurfaceAppearance objects across the entire DataModel.
SurfaceAppearances are likely to be used more frequently by designers or 3D modelers since they involve UV mapping, so it is not ideal that this aspect of material application would require any form of programming or complicated workflow.
This topic is particularly confusing for developers because it is unclear exactly what functionality each tool is meant to provide. If you want your tiling PBRs to reference a UV map, you NEED to use SurfaceAppearance, even if the same tiling PBR will be re-used in various ways across different geometry in your game.
This is a problem for Roblox Development; we now have developers who are using SurfaceAppearance as a substitute for materials. They wanted to use materials originally, but must use SurfaceAppearance purely because they want a PBR to use a UV map. If you want trees with bark that UV map to a PBR texture, you should be able to set a “Bark” material and not worry about it.
If we were to have properties that allowed Materials to obey UVs for meshparts, it would improve the developer experience by dramatically clearing up the intended functionalities of these two objects. Although you can functionally achieve what you want to with SurfaceAppearance, it’s very unintuitive and roblox developers frequently make posts, bug reports and feature requests because the workflow is unclear.
I don’t often make feature posts, so sorry if anything here is unclear. It’s a bit difficult to concisely notate how confusing the current workflows are given the current functionalities of these two objects, as well as how this problem will become more significant when physical properties of materials influence things like sounds and it becomes more important to use the right material for your game objects. I’m available to provide more detail if needed!
