Get list of assigned material names for mesh "sides"
tracked
Nyx Onyx
This feature request relies on https://feedback.secondlife.com/feature-requests/p/store-material-names-as-metadata-for-meshes-exposing-them-to-scripts being implemented.
If the above feature is implemented, and if we could have a feature to retrieve the material names (not names of Material Assets!) for each "side" or "face" with a script, it'll be easier to implement scripts for controling textures and other "face" related features for several objects at once, without having to first create mappings between face / side number and intended material face.
See the provided images for two objects that are intended to share some materials, while they differ in other ones. I envision having those material names, listed to the right in the pictures, retrievable by for example llGetObjectDetails(OBJECT_SIDE_NAMES), which could return a list like so:
["Floor", "OuterWalls", "Roof", "Underside", "WallEdges", "WindowPanes"]
Which means that "side 0 is named Floor", corresponding to the index.
An object not having this information should return an empty string for each unnamed side.
This makes it possible for a script to automatically map side numbers with intended materials for them. A viewer such as Firestorm with a scripted "bridge" could also potentially retrieve the information to show in the UI.
Log In
Spidey Linden
marked this post as
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Nexii Malthus
Probably something like
PRIM_FACE_MAPPINGS
for llGetLinkPrimitiveParams
/ ll.GetLinkPrimitiveParams
returning a list/table of stringsNyx Onyx
Nexii Malthus I certainly don't mind having that as an additional accessor, but if that's the only way to get the info then it cannot be accessed by scripts outside of the object / linkset, which limits the applications of the feature, such as my example with viewers displaying the information in the UI (unless it injects a script to get it, of course, given that the object is modifiable). Do we want to limit it this way?
Nexii Malthus
Nyx Onyx why not both? Also not like the viewers use the info object details info anyway, firestorm has a bridge but still has broken link numbers in the UI for years despite OBJECT_LINK_NUMBER and llGetObjectLinkKey existing, which continues to confuse users and make them think their builds/scripts are broken all the time.
Nyx Onyx
Nexii Malthus I'd vote for having both ways. At least having both ways it can be used in and out of the object / linkset. Would anyone say the data should be kept secret from the outside?
Nyx Onyx
To add more info about why this is a helpful feature... in the above case the first object has the materials:
Ceiling = 0
Floor = 1
InnerWalls = 2
OuterWalls = 3
Roof = 4
Underside = 5
WallEdges = 6
And the second object has:
Floor = 0
OuterWalls = 1
Roof = 2
Underside = 3
WallEdges = 4
WindowPanes = 5
You can see that "Floor" is "0" in the second object, while it's "1" in the other object, just to show one difference, there are more differences. Today a script can't learn which one is which without you telling it by mapping it in the script or using a notecard for example.