Can't detect baked texture
tracked
Lone Wanderer
We can currently set baked textures using llSetLinkPrimitiveParams and llSetLinkTexture using:
IMG_USE_BAKED_HEAD
IMG_USE_BAKED_UPPER
IMG_USE_BAKED_LOWER
IMG_USE_BAKED_EYES
IMG_USE_BAKED_SKIRT
IMG_USE_BAKED_HAIR
IMG_USE_BAKED_LEFTARM
IMG_USE_BAKED_LEFTLEG
IMG_USE_BAKED_AUX1
IMG_USE_BAKED_AUX2
IMG_USE_BAKED_AUX3
We cannot however detect if these are applied on objects other than full perm ones because llGetLinkPrimitiveParams can't read texture keys without either the texture being in inventory, or the object being full permission.
This issue can be fixed by either supplying the textures mentioned above in the avatar library folders as actual textures we can put into object inventories, or fixing the function to be able to return the baked texture key, such as IMG_USE_BAKED_UPPER (ae2de45c-d252-50b8-5c6e-19f39ce79317).
This is currently preventing me from automating material placement for customers on non full perm assets (such as PBR materials, or normals and speculars to match the BOM diffuses.)
Log In
Lone Wanderer
Hi, the step by step instructions would be to...
1) set a baked texture on an object
2) send the object to someone, with copy/mod/no transfer permission
3) that someone would then create a script, using the function llGetTexture or llGetLinkPrimitiveParams, etc, with the PRIM_TEXTURE input.
It's correct that these functions won't return the key of a user texture, however, IMG_USE_BAKED_HEAD, etc, are categorised as an internal texture. As these are textures everyone has access to, it would make sense to be able to detect their keys as their use is more related to platform functionality. Returning their key wouldn't cause the same issues as returning other keys, which would relate to IP theft.
My personal use case is to detect which faces on a popular mesh body have baked textures on them, and replace them with a corresponding PBR material. This is really needed as some customers struggle with working out how to change one texture, never mind the potential hundreds across all faces in a mesh body.
If it's best to mark this as a new feature request please do so, I assumed it was an oversight on the llGetTexture etc functions, given the restrictions intent was to prevent stealing textures from a modify items and putting them onto other items with no permission restrictions via key, which isn't a concern with internal textures, animations, sounds.
I should add: I also suggested just putting these textures etc in the library, as there would be no issue if we could just copy the textures into our inventory, then the object's. That would enable detection with the current function limitations. If however that would cause a change in asset key for each copy from library to user inventory, to object inventory, that of course wouldn't work. I'm not sure if the assets taken from the library unchanged are using the same asset keys as reference, or if they're duplicated with their own unique keys.
Maestro Linden
marked this post as
tracked
Maestro Linden
Thinking this through, this issue is actually a feature request for llGetLinkPrimitiveParams et al. to not have a permissions limitation when reading textures, which is described in https://wiki.secondlife.com/wiki/PRIM_TEXTURE as:
```
With texture as with llGetTexture, NULL_KEY is returned when the owner does not have full permissions to the object and the texture is not in the prim's inventory.
```
Without that limitation, a script in a limited-permissions object could read the actual UUID of a texture on a prim face and compare it to IMG_USE_BAKED_HEAD and related constants. Tracking for additional public feedback in Canny.
Lone Wanderer
Maestro Linden, I added some further info in the comment above
Maestro Linden
marked this post as
needs info
Maestro Linden
Lone Wanderer please provide step-by-step instructions for how to reproduce this issue.