GLTF material asset disappears across multiple object instances
under review
Froukje Hoorenbeek
All objects referencing a specific GLTF material asset suddenly render completely white. The full material assignment disappears from the faces: Base Color, Normal and ORM slots appear empty.
The affected objects had been rezzed and functioning correctly for days prior to this issue. No changes were made to the material or textures. The material is still present in inventory. The material works correctly on other objects (e.g. PG variant of the same table). Relogging and clearing viewer cache did not resolve the issue.
The issue affects all objects referencing this material in different regions. Another object with the exact same texture (pg version) was not affected and the material looks as it should on that one.
A GLTF material asset loading or asset server issue maybe? Please investigate.
Log In
Maestro Linden
marked this post as
under review
Maestro Linden
Hi Froukje Hoorenbeek thanks for the material. I took a look at it, and it appears like this to me:
When I open it with the material editor from inventory, it looks like this:
- Base color: 100% solid white texture, opaque with a white tint
- Metallic-Roughness: bright green background, with yellow flower-like shape in center
- Emissive: empty - no map set.
- Normal: Mostly flat (at preview thumbnail scale) in the main central portion, with some pronounced radial angles in the corners (outside the "flower" are seen in the Metallic-Roughness map)
When I apply the material to a sphere and zoom in, it renders as white (as expected, due to the base color), with a paper-like texture and roughness at the poles, from the normal map. When the camera moves away from the object, the finer details of the normal map are lost, and most of the surface appears as smooth. I don't see much impact from the Metallic-Roughness map with this lighting, but I think that's due to the solid white base color.
Overall, the material appears white to me, but this seems to be expected given the material settings. What are you expecting the object to look like?
Froukje Hoorenbeek
Maestro Linden Thank you for checking the material. The issue I am experiencing is not about how the material renders when correctly applied.
The problem is that, on certain in-world object instances, the PBR material assignment disappears entirely from the face. The surface then renders as plain white until the material is manually reapplied. After reapplying, it renders correctly again.
So the material itself is correct. The issue appears to be that the material slot on the object face is being lost intermittently.
Maestro Linden
Froukje Hoorenbeek: Thanks for the clarification. I have some other questions for investigation:
- When you have an instance of the object affected by this issue, does duplicating the object or taking and re-rezzing it from inventory preserve the bad state?
- Could you point me to some rezzed instances (or send me a copy if the answer to (1) is 'yes') of broken objects?
Froukje Hoorenbeek
Maestro Linden I retrieved one previously affected instance from Trash that had the material assignment missing.
Dragging it back out from Trash did not restore the material. Duplicating that in-world instance also preserved the bad state (the material assignment was still missing).
I have sent that affected object instance to you in-world for inspection.
Maestro Linden
marked this post as
needs info
Maestro Linden
Hi Froukje Hoorenbeek, could you please send me a copy of the material asset in question? If it's rendering correctly on some viewers but not others, this might be a viewer rendering issue for certain viewer builds, hardware, etc.
Froukje Hoorenbeek
Maestro Linden Hi, I’ve sent the material asset to you in-world.
Maestro Linden
Froukje Hoorenbeek: Thanks for the object. I took a look, and was able to confirm that the material is definitely gone from it. Aside from the cloth-like normal map not rendering, I used this LSL script to see that the material asset was cleared:
default
{
state_entry()
{
integer face;
for(face = 0; face < llGetNumberOfSides(); face++)
{
llOwnerSay( "Properties of face " + (string)face + ": "
+ "\n\tPRIM_RENDER_MATERIAL: " + (string)llGetPrimitiveParams([PRIM_RENDER_MATERIAL, face])
+ "\n\tPRIM_GLTF_BASE_COLOR override: " + llList2Json(JSON_ARRAY, llGetPrimitiveParams([PRIM_GLTF_BASE_COLOR, face]))
+ "\n\tPRIM_GLTF_NORMAL override: " + llList2Json(JSON_ARRAY, llGetPrimitiveParams([PRIM_GLTF_NORMAL, face]))
+ "\n\tPRIM_GLTF_METALLIC_ROUGHNESS override: " + llList2Json(JSON_ARRAY, llGetPrimitiveParams([PRIM_GLTF_METALLIC_ROUGHNESS, face]))
+ "\n\tPRIM_GLTF_EMISSIVE override: " + llList2Json(JSON_ARRAY, llGetPrimitiveParams([PRIM_GLTF_EMISSIVE, face]))
);
}
}
}
The "no GLTF material set" output looks like this. It indicates that there's no base material asset set, and no overrides set (the latter is only meaningful if there were a material set):
Properties of face 0:
PRIM_RENDER_MATERIAL: 00000000-0000-0000-0000-000000000000
PRIM_GLTF_BASE_COLOR override: ["","<0.000000, 0.000000, 0.000000>","<0.000000, 0.000000, 0.000000>",0.000000,"","","","",""]
PRIM_GLTF_NORMAL override: ["","<1.000000, 1.000000, 0.000000>","<0.000000, 0.000000, 0.000000>",0.000000]
PRIM_GLTF_METALLIC_ROUGHNESS override: ["","<1.000000, 1.000000, 0.000000>","<0.000000, 0.000000, 0.000000>",0.000000,"",""]
PRIM_GLTF_EMISSIVE override: ["","<1.000000, 1.000000, 0.000000>","<0.000000, 0.000000, 0.000000>",0.000000,""]
Maestro Linden
As a basic test to see what's going on, I manually set the material on the table cloth to a 'green grass' GLTF material, which is obviously distinct from both the material you sent me and a 'blank white' material. When I then sat down at the table, the scripts in it automatically:
- Hid the original table prim with the 'green grass' GLTF material
- Set a 2nd, previously invisible, table mesh to be visible. This table prim uses the d786.. GLTF material you sent to me, with no overrides set.
I think this might be the source of confusion - there are actually
multiple
* table objects involved, which appear and disappear depending on user input.Looking through the scripts in the table, I see that there is also at least 1 script (''Universal Materials Texture Changer: Main Script v8.5") which changes both the PRIM_RENDER_MATERIAL and various other PRIM_GLTF_ parameters across the linkset. This script could be changing the tablecloth material against your wishes.
As such, I have some other questions for you:
- If you set the original table object to have the GLTF material you supplied to me, does that material get lost?
- If the material gets lost, does it get lost when the scripts are removed from the object?
- If no to question (2), there could be a bug in the LSL API related to GLTF material updates. In that case, which LSL calls cause the GLTF material to be altered unexpectedly?
Froukje Hoorenbeek
Maestro Linden To clarify a few points:
• The tablecloth mesh becomes invisible during some animations and another is rezzed. This is intentional and only affects visibility of the linked tablecloth mesh.
• At least two of the affected instances had never been sat on, so the issue occurred without any sitting event.
• The PG version of this product uses the same scripts and mesh setup, and I have never observed the material loss there.
• The “Universal Materials Texture Changer” script only targets linked prims whose description starts with “t;” (the chair wood), and does not modify the tablecloth link or its PRIM_RENDER_MATERIAL.
Based on this, the material loss does not appear to correlate with sit events or the texture changer targeting the tablecloth link.
Froukje Hoorenbeek
Maestro Linden 1. When I manually set the GLTF material on the original table object, it renders correctly. However, on previously affected in-world instances, the material assignment was later found to be cleared without any user interaction.
2. I have not yet performed a controlled test with all scripts removed from the affected Adult version to determine whether the material loss still occurs in the absence of scripting. However, the PG version of this table uses the same scripts and the same GLTF material, and I have not observed this material loss there.
3. Since I have not isolated the issue with scripts removed, I cannot yet determine whether a specific LSL call is altering the GLTF material unexpectedly.
Froukje Hoorenbeek
Maestro Linden The GLTF material assignment disappears without any user interaction on the affected link. The prim in question does not contain any script that modifies PRIM_RENDER_MATERIAL or GLTF parameters; it only contains a visibility control script.
The issue has been observed on multiple regions (different sims).
Additionally, the same GLTF material is used in a similar design (PG version with the same script setup), where I have not observed the material assignment being cleared.
Maestro Linden
Okay, with that in mind I'm leaving a fresh copy of the table rezzed in my test area. The one modification I'm making is to add a GLTF material back to the tablecloth that initially appears. I'll wait and see if it somehow loses the material without outside intervention (such as somebody sitting at the table).
Froukje Hoorenbeek
Update:
Some users were still seeing material structure and shading correctly, some where not. I am at a loss here.