Applied "Prim Property" PBR Materials Do Not Update When Altered in Prim Inventory
tracked
Polymath Snuggler
- Place a Material within a Prim inventory.
- Apply it to object faces with LSL ApplyRenderMaterial Function.
- Edit Material in Prim Inventory. Press "Save". Observe it is not updated.
This further complicates things when attempting to use Local Textures.
PBR materials exist in two different copies:
1 : Stored inside an inventory. ( Personal or Prim )
2 : When applied to an Object, in the object face
"Inventory"
<< reason for these quotes below.This makes sense in the context of an LSL script, or any other editable asset within SL, but those objects appear within the inventory of the Prim when Applied.
PBR materials function identically, but there is no UI notification to alert the user of this.
When you apply a PBR material to an entity ( logically of course ) it makes a copy of itself, thus letting someone else with full perms adjust it, while the original remains unaltered.
Local textures are able to be applied to both In-User-Inventory PBR materials, In-Object-Inventory (the visible one) , as well as In-Face-
"Inventory"
PBR materials ( that are actively applied to faces) However, you can edit the ones in your personal inventory, as well as the ones in the object inventory, and the ones actively displayed upon the object WILL NOT UPDATE ( as they are in face "Inventory"
) even after "Save" is clicked. The only time that pressing "Save" on the material that you have chosen to edit, actively updates the visible material is when the Material that is currently being edited resides in the object face "Inventory"
. Personal inventory, and Object Inventory updates are not-re-broadcast until the newly saved material is either dragged and dropped from Inventory >> Face "Inventory"
or an LSL script event transfers it from Object Inventory >> Face "Inventory"
. This makes logical sense, when you understand the mechanics of what is taking place, but it does not make user sense; due to the configuration of the UI, and our previous mental patterns regarding how textures are applied don't align with this. As such a lot of our expectations regarding how things should work do not match reality. While I am unsure precisely what to do about this predicament. My best suggestion is as follows :
I believe Materials residing in the inventory of the object should auto-update all related Face "Inventories" when they are modified and the user clicks the "Save" button on the Material Asset residing within a prim inventory. This material is discrete and does not have additional copies, unless it is removed so force updating it makes sense. This has parity with what happens when you delete the Material Asset from the Prim inventory, and it reverts to a pine box.
I also believe User-Inventory materials should not be allowed to contain Local Texture links, as this starts to become exceedingly confusing from the end-user perspective. Either place a large notification on the "Local" Tab of PBR materials with "This item resides in your inventory, and changes will not be updated until re-applied to objects, please place a copy in prim inventory to use this." or remove the functionality altogether and replace with a similar message.
Log In
Dan Linden
Thank you for the report, Polymath!
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Dan Linden
tracked
R
Runitai Linden
What you're getting at is functionality that allows an instance of a mesh to references a modifiable instance of a material (as you see in Blender and elsewhere). However, the Second Life asset system is, by design, write once -- every time you modify a material it makes a new copy of that material and leaves old copies untouched, which is why clicking "save" changes the material's asset id, so implementing this with our existing data model will really just be a series of UI shortcuts, which is doable -- something like a "Save and Apply" button in the material editor that does what you describe above.
I should note, though, that we're looking at implementing support for full GLTF scenes, not just materials, and in that data model, you'd be able to instance meshes and materials in a node hierarchy. My inclination is to not try to make the existing SL data model act like it supports instancing even though it doesn't really, but add support for GLTF scenes according to the GLTF specification so there's no ambiguity about what the expected behavior is.
Polymath Snuggler
It's difficult to make an argument for the intuitive-ness of something, as that varies from person to person. But having three different locations of an editable material instance, the most functional of which has no UI indication that it's an inventory item, due to the fact that it's a "prim property", is very obtuse UX to me. For a material residing inside a primobject inventory ~ perhaps a UI Function "Save and Update Faces" or something similar is in order. Likewise if it's in the prim-property "Inventory" slot ~ a UI button "Save and Save Copy to User Inventory" << ( though that context button is way too wordy )
Dan Linden
under review
Beq Janus
https://jira.firestormviewer.org/browse/FIRE-33684 - for a tracking JIRA for the same issue on FS.