Creators, are you aware that your PBR textures and material UUID are not "protected" (you can get them by script in modifiable mesh) ?

[Gael Streeter]

In the previous Blinn-Phong material system, the UUIDs of the textures applied on one mesh were "protected" and you could not retrieve them by script if you do not have full permissions on them. This was a security system put in place by Linden Lab itself.

But do you know that it is no more the case in PBR ???? Indeed, you can easily get all the PBR textures and materials UUIDs applied on one mesh by dropping a simple script in the mesh if you have it modifiable! No more protection by Linden Lab on these UUIDs!

I learned it recently because I open a bug ticket and got this answer by Linden Lab : https://feedback.secondlife.com/scripting-bugs/p/pbr-script-the-llgetprimitiveparams-function-returns-the-texture-uuid-in-clear-o

So now, if you want to protect your PBR texture UUIDs, the only way is to make the mesh NO MODIFIABLE!

What do you think about it ? I am not sure that all the creators are aware about it...

[Kristy Aurelia]

That depends on how the material is applied. PBR actually makes them even more secure. Just like Linden Lab told you - script can only read/change the overrides.

To put it in layman's terms:

PBR materials are applied in two "layers" - Material object as a whole, as in the inventory material item you have. And Material Overrides - the part that scripts can read/write and also the part you change when editing PBR properties on item itself.

So what that means, if you make a material item in your inventory, set the texture in it, and apply the material to the object - you'll be only setting the Material, which is the PRIM_RENDER_MATERIAL field. It is a single UUID that points to the whole material item. Scripts cannot read any individual parts of that. From script point of view that field is a single UUID, which usually will return blank, as I believe it follows the old rules of permissions (I think Maestro got it the wrong way around in the reply? I asked to clarify), so unless the object is full perm, or the material object is in the inventory, it will just give you blank value. In any case, if you do provide a material in the inventory of a prim, or along side your item. Opening the material in the viewer, does not allow reading UUIDs of the textures the material contains either. Also materials on their own have permissions too.

When you edit the materials on the item itself, or via scripts, you're editing 'Material Overrides' or the 2nd layer... which as the name suggests, overrides whatever values are provided by the base material. So for example, if your material has tint colour set to green, and you edit it on the item to red, the override will be set to red and the viewer will load the material with the original green colour, and swap it to red. Scripts can read/write this new red value. But, if the red was never set, attempting to read the original tint colour will give you white and not green (which is the default for not-set/not-available), same rule applies to texture UUIDs or other parts that are set within the material object.

This also allows the scripts to set a custom texture in the overrides and then set it to blank without losing the original texture, if the original texture is part of the "Material Object" layer.

 

Edit: And to elaborate on the Maestro's answer. If you make materials as overrides, you can save them to your inventory as an object later, which might be easier in some cases than editing just the inventory item directly. After you save the material as an object, you can then clear any PBR materials and just apply the Material Object directly, which will leave all overrides blank. Also, clearing the material beforehand should not be required, as the action of applying material object should also clear any overrides. The same is true if a Material Object field is changed by the scripts - the overrides will be cleared.

So in short, if you want to be safe, have your HUD change the PRIM_RENDER_MATERIAL with a different material object, rather than changing individual material override fields.

 

Edit 2: Textures do have some extra weirdness when being applied into materials too - for example, if you have a copy/mod/no-trans texture, you can apply it as a legacy texture, but you cannot set it to any of the material fields. Only full-perm textures can be set. Which is a bit odd... but I think it has something to do with setting overrides and then saving them out as materials - it stops people converting no-trans textures into full perm materials I think... or something like that... I'm not too sure, but it is still worth being aware of that there are some differences.

Edited May 18 by Kristy Aurelia

[Gael Streeter]

Thank you Kristy Aurelia for your detailed answer!

I did not catch all yet but I will try to clarify my mind with some tests during the next coming days. For the moment, it lets me think that either you put your creations in NO MOD or you always go through PBR Materials...

However I find it is a real gasworks ! Is there somewhere a detailed documentation made by Linden Lab about how it is supposed to work ? The creators need to be informed about all these "subtleties"!

[Gael Streeter]

BTW Kristy Aurelia, is there a special reason to make the override textures UUIDs readable ?

[Qie Niangao]

5 minutes ago, Gael Streeter said:

However I find it is a real gasworks ! Is there somewhere a detailed documentation made by Linden Lab about how it is supposed to work ? The creators need to be informed about all these "subtleties"!

Yeah, everything PBR is still very trial and error for me, with no comprehensive documentation I can find. I mean it's fine to rely on residents to write the wiki, but in the (distant?) past, the beta testers got extensive information from developers about what design considerations went into decisions. Maybe they did this time too, but unless somebody starts documenting now, that's going to be lost to history.

I suspect that permissions on glTF Materials are the product of real, practical considerations about what information is stored where, and how to achieve the highest possible granularity of permissions. A little testing leads me to conclude, for example, that it's possible to set permissions on individual materials used on an object, and include those precisely precisioned materials in the object to establish what if anything the recipient can do with those materials. There was nothing this sophisticated in the old Blinn-Phong matarials model, but it's sure an adventure to discover how any of this works.

[Kristy Aurelia]

 

2 minutes ago, Gael Streeter said:

Thank you Kristy Aurelia for your detailed answer!

I did not catch all yet but I will try to clarify my mind with some tests during the next coming days. For the moment, it lets me think that either you put your creations in NO MOD or you always go through PBR Materials...

However I find it is a real gasworks ! Is there somewhere a detailed documentation made by Linden Lab about how it is supposed to work ? The creators need to be informed about all these "subtleties"!

I'm not sure... I've gathered all my knowledge from multiple sources over time. The main product I'm making is scripts, and I want to make sure that when people put my scripts into their mod stuff, my scripts are not going to accidentally override textures and so on

Some of the places/ways I've learned about all of this:

https://wiki.secondlife.com/wiki/GLTF_Overrides - A notable line in there is "A glTF override is a collection of changes applied on top of a glTF material asset" asset being "material object" I referred to.
https://feedback.secondlife.com/scripting-bugs/p/pbr-colour-data-is-lost-when-setting-pbr-overrides - An issue I ran into when trying to change only alpha, and was unable to read the colour value from the material.
There also was a JIRA, but the page is no longer available, where I asked about how to safely change PBR properties without losing existing textures, that did cover some details of how the overrides work.
When I was writing my 'Mod vs No-Mod' argument doc https://docs.google.com/document/d/1Kosnx9oPTZMrMixtH35zvKUhDC2XlVt2HKZ-uH7csOM I've had someone send me bunch of basic materials with the mix of permissions, so I've tested to see what can and cannot be changed or viewed. The relevant parts would be:
[mod perms] For PBR Materials:

• Allows - Textures to be replaced/removed.
• Allows - Settings to be adjusted.
• Does not allow - Pulling out texture UUIDs of applied textures.
  • This might be viewer dependent (I’ve used Firestorm Beta 7.1.7), no-mod materials preview the textures when clicked, while mod materials bring up the texture picker dialog. So technically, one could screenshot the texture preview on a no-mod material, but not on a mod material.
• Does not allow - Transferring modified materials if part of the textures or settings were changed.

If I remember any other sources, I'll edit this post.

 

[Kristy Aurelia]

3 minutes ago, Gael Streeter said:

BTW Kristy Aurelia, is there a special reason to make the override textures UUIDs readable ?

I don't really know.

I would imagine it allows creators to do various things based on current texture being set and so on. (in cases where there is no worries about textures being used by someone else).

It also could be because of the way the overrides are changed, as the script can only read/write it as a whole set - including texture, UV scale/offsets, rotation, tint colour, alpha mode and so on. There currently are no LSL functions to set the various properties individually, but that is being worked on for the future.

[Gael Streeter]

Thank you again Kristy Aurelia for all the info! I made one test and I confirm the PBR Material is not readable itself if you do not have the rights on it. That is a good news.

I really would like to know why these UUIDs are readable... If someone knows, please tell us! (I hope Linden Lab knows... lol)

[Rick Nightingale]

Perhaps because a script might need to temporarily change something and so needs the original override UUID and parameters to return to.

For instance, to switch an object between visible and invisible, like is done with a sheathed/unsheathed sword: the script needs to be able to read the override texture in order to return it afterwards. Unfortunately, at the moment, there is no other way to do that than using the PRIM_GLTF_BASE_COLOR. I know because I've been having to do it on some of my items.

All of the PRIM_GLTF_* functions are like this.

Edited May 18 by Rick Nightingale

[Kristy Aurelia]

On 5/18/2024 at 11:06 AM, Kristy Aurelia said:

I think Maestro got it the wrong way around in the reply? I asked to clarify

I can't edit the original post anymore, but Maestro did clarify that it works just like regular textures, so indeed he accidentally got it the wrong way around in the initial reply. And it does indeed work the way regular textures do as I mention in the main reply.