Store material names as metadata for meshes, exposing them to scripts
tracked
Nyx Onyx
Using Blender and probably other 3D authoring tools, you can name the materials assigned to the faces of the mesh. These names are then included in the export to DAE and GLTF/GLB files. But as soon as it's uploaded to SL, this information is either lost or at least is unavailable to viewer and scripts. In SL we can only access the so-called "side number", which is used for various things such as tinting or applying a material asset with a script.
It would be helpful if the material names in a mesh upload could be retained, such that it then can be accessed by scripts, and possibly by viewers too should it be desired in for example the toolbox window.
I will file a separate ticket referencing this one, regarding how this could be used with scripts. It's now found at https://feedback.secondlife.com/scripting-features/p/get-list-of-assigned-material-names-for-mesh-sides
I don't believe that this feature will have any negative consequences beyond increased data storage utilization.
Log In
Beatrice Voxel
Based off of what Journey has said, the "workaround" will probably have to be including materials as some kind of objects within the contents of the scripted object. Scripts can address contents, and use them, whereas facings on mesh are just numbers and have no other properties to report back to LSL to my knowledge.
As of now, materials would have to be included as sets of textures (matte, normal, specular) or as PBR texture objects (not sure if they're able to be dropped into an object's contents and thus referenced to be applied to given faces.)
Nyx Onyx
Beatrice Voxel it seems to be that you misunderstood the idea here, and that is to start including the metadata that already exist in the GLTF/GLB files, as well as the DAE files, so that this actually can be used. It's today discarded data in SL. With both formats you can export with placeholder materials, and if you're smart about your choice of material (slot) names you can then make use of this data to inform scripts inworld. Today it's not possible at all because of SL discarding this data.
Beatrice Voxel
Nyx Onyx That's the problem, SL doesn't define object faces with any attributes that can be stored, not even names. They're just numbered.
In order for this to be implemented, SL would have to define more attributes to mesh/prim faces, which is not an easy change. How would legacy objects be handled (those with 'null' values)? How would memory management in viewers cope with added data for thousands of rezzed objects in a given sim? These are the considerations that must be addressed.
Nyx Onyx
Beatrice Voxel It's metadata, it doesn't have to be added to the object data itself necessarily, but do need to be stored on the asset server, and probably brought in by the simulator. It doesn't have to be sent to the viewers (unless implemented there, and provided on request). Correct, it doesn't exist right now, it's what I am requesting to be added. Objects that already exist would return empty strings in a list. See the referenced Canny post.
Journey Bunny
Bit torn on this. Faces in SL don't have names. Materials in SL do have names. I see what the intention is--a vertex group associated with a material slot taking on a reference name for that vertex group for easy reference when scripting--but this is coupling things that aren't coupled. The slots are indexed by number in the model, and the faces in Secondlife are indexed by number.
The names of the material data blocks that get assigned to those slot numbers are not the "names" of the faces. One might choose to imagine them as such in a personal project, but it's not how they are. It is possible--and in plenty of circumstances, desirable--to have, for example, the same material data block (eg, "material name") assigned to more than one material slot in Blender. This results in multiple material slots being established on the model during upload, and they absolutely should NOT be the same slot.
A material isn't as simple as a texture; it is desirable, for example, to assign an identical material to two slots in the editing tools, and then to have one slot hold a separate tint value from the other (but all the same material maps) once the model is in-world. The setup must not treat these as "name of material = name of face" because that breaks model definition.
This is not merely a "use if you want, don't if not" convenience; this maps a named reference to things that don't work that way in the model. It proposes to conflate two concepts that are separate. I love the idea of named faces for scripting--let us name them on import or somesuch--but using the wrong data for the name is going to get us off to a bad start.
Nyx Onyx
Journey Bunny This is not coupling anything, it's keeping and making accessible data that already exist in the files exported from the authoring programs and that today is discarded. If the data is retained it can be used. It's then up to the creators to be smart about the naming so that they can make use of it inworld, or to not be. It becomes a design tool, you choose whether to use it or not, you won't be worse off for this feature existing. Now I don't mind you being able to edit these names in the uploader, but I'd prefer the default being set to the names already in the file.
Journey Bunny
Nyx Onyx
Materials in Blender correspond to materials in Second Life. Material slots in Blender become faces in Second Life. Imported materials retain the material’s name, but faces themselves should not inherit that name.
You suggest relying on “smart” creators. A smart creator names their materials things like “metal paneling” or “plastic armor.” Once the object is in-world, the area that was metal paneling may later be retextured as plastic armor. That face should not continue to be named after whatever material happened to be applied at upload time.
If the assumption is that creators will name materials things like “front panel,” then the feature is designed around a workflow many prolific creators do not use. It’s common to create many material variations for a model, and the material name should describe the material asset, not the logical face of the mesh. Creators are not being “smart” by giving materials inaccurate names just to opt into a scripting feature.
It doesn’t add value to say creators can simply choose not to use the feature. The question is why the material name--already paired with the material asset on upload--is required at all. A more valuable approach would allow faces to have their own distinct names, rather than forcing creators to name material assets after faces.
There’s also an unaddressed technical issue. Second Life currently identifies faces by unique numbers; it does not handle two faces being identified the same way. This is not about whether scripters use the feature, but about how data is entered at upload time, which affects everyone.
Proposal: The upload form should include fields for naming faces. These could be prefilled with the material names, but must handle name collisions, allow edits at upload time, and enforce uniqueness server-side. That would provide a solid foundation for a feature like this.
Nyx Onyx
Journey Bunny Smart naming of material slots on an object in Blender, with the intention of uploading a model that should have a variety of texturing options inworld, especially if they are multiple different objects that will be sharing a set of trimsheet materials, is naming the material slots according to where those trimsheet materials will be used. This could be codified like "SheetA1" "SheetA2" etc, or it could be sections like "OuterWalls" "Door" "WindowGlass". The material slots on the object will then not correspond to Material Assets, merely be named slots that can be referenced / looked up by a script so it knows where a set of Material Assets can be applied. All Material Assets intended for "OuterWall" can then easily be mapped by a script due to a personal naming convention such as "OuterWall_GreyStones" "OuterWall_RedBricks".
Now I do agree with your proposal as such, it would be nice if you could define the names in the uploader, though I'd be happy enough to have the material slot names just go in automatically. In the end, I'm happy if I can have a script do the mapping on its own by way of using names. I don't need the material slots to be unique either, as sometimes multiple material slots are intended to be used as one, but are added twice to the object due to the limits of how many triangles can be assigned one material. If unique names are required, I can work with that in scripting anyway though, as I'd just have the material slots be named "OuterWallA" "OuterWallB" and interpret them as the same one.
Spidey Linden
marked this post as
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.