Due to the inheritance structure of material assignments, there is no way in a production environment to get the original material path from a given IEntity within the game. BaseContainer can be used to investigate material overrides present on a prefab via the AssignedMaterial and SourceMaterial attributes, however if a prefab does not override the default material of a given .xob mesh object, those parameters will not exist within the prefab (no override = no data). Attempting to use FileIO to read the .xob as a string allows for the extraction of these default material resource names only within the workbench environment.
Here is an example of how one could get the materials assigned to an object via prefab.
```
EntityPrefabData prefabData = entity.GetPrefabData();
if (prefabData)
{
BaseContainer prefabSource = prefabData.GetPrefab();
if (prefabSource)
{
IEntitySource entitySource = prefabSource.ToEntitySource();
if (entitySource)
{
BaseContainer meshContainer = SCR_BaseContainerTools.FindComponentSource(entitySource, "MeshObject");
if (meshContainer)
{
// Below can be used to get path to base .xob mesh object.
ResourceName meshPath;
meshContainer.Get("Object", meshPath);
// Below can iterate through materials list of material overrides present on prefab.
BaseContainerList materialsList = meshContainer.GetObjectArray("Materials");
if (materialsList && materialsList.Count() > 0)
{
for (int i = 0; i < materialsList.Count(); i++)
{
BaseContainer materialContainer = materialsList.Get(i);
if (materialContainer)
{
ResourceName assignedMaterial;
ResourceName sourceMaterial;
materialContainer.Get("AssignedMaterial", assignedMaterial);
materialContainer.Get("SourceMaterial", sourceMaterial);
}
}
}
}
}
}
}
```
Specifically, we can try to get the materials from the VObject:
```
//! Returns visual object set to this Entity. No reference is added.
proto external VObject GetVObject();
//! Visual object
sealed class VObject: BaseResourceObject
{
proto external int GetMaterials(string materials[]);
}
```
Unfortunately, this only returns the list of material names, this also heavily complicates remap operations, where the remap string expects => name remaps to path, but to remap back to the base material, we have no way to know the original. Yes, using SetObject with no $remap string does revert to default materials - there are cases such as with resolving materials to a Material class (to do runtime editing of materials), but for some usecases knowing the object'swhere material name is not sufficient to resolve a materials (with paths) is necessary instance.
**I therefor, am suggesting an additional function which would allow for the easy collection of ResourceNames present on a VObject, perhaps something like:**
```
//Takes a material name parameter, mutates given ResourceName with resolved path. Returns false if unsuccessful.
proto external bool GetMaterialPath(string materialName, ResourceName materialPath);
```
This would allow a user to resolve a material name (given from GetMaterials) into a ResourceName (full material path) - while this may not be the original material, it would help in 90% of situations where the "original" is desired.
Maybe a lower level API for reading the original materials assigned by the .xob during import would be beneficial as well.
Thank you for your time.