[PBR] PBR Material resets to legacy material after teleport.

[KrsityKu]

Environment

This happens on the Official Viewer, Alchemy and Firestorm.

Firestorm 7.1.3 (72975) Feb 15 2024 18:43:30 (64bit / SSE2) (Firestorm-Betax64) with Havok support

You are at 228.7, 84.5, 3,414.4 in Loveless Determination located at simhost-057358e8a50dc518c.agni SLURL: http://maps.secondlife.com/secondlife/Loveless%20Determination/229/85/3414 (global coordinates 273,381.0, 333,652.0, 3,414.4) Second Life Server 2024-01-19.7590161929

CPU: AMD Ryzen 9 7950X 16-Core Processor (4499.89 MHz) Memory: 64652 MB (Used: 2987 MB) Concurrency: 32 OS Version: Microsoft Windows 11 64-bit (Build 22621.3155) Graphics Card Vendor: NVIDIA Corporation Graphics Card: NVIDIA GeForce RTX 4090/PCIe/SSE2 Graphics Card Memory: 23374 MB

Windows Graphics Driver Version: 31.0.15.5152 OpenGL Version: 4.6.0 NVIDIA 551.52

Description

Certain meshes lose PBR material after teleporting. I've initially spotted this issue around Christmas time when trying to DIY PBR-ify a mod item I had, and after applying PBR material to all the faces, one of the faces would revert to legacy material. I could initially only reproduce it on one specific mesh, but today I discovered another mesh that has the same issue.

Both of the meshes seem to have weird interleaving faces:

The white baked specular highlight is the legacy texture, while the very dark grey is a PBR material I've applied. When the item is detached and rettached or rezzed quite often it has PBR material on all faces, but one of them reverts back about 2s later. As per title, teleporting also reverts the material. Relogging does fit the issue until next teleport.

Upon further investigation, we've found out that llGetNumberOfSides() returns 2 in this specific item, but the viewer reports 3 faces:

So far I've only ran into two items that do this. The stockings with the issue are Maitreya version of this: https://marketplace.secondlife.com/p/AURORA-Maid-set-FATPACK/20475576 If you need more details of the items, or need an in-world demonstration, do let me know.

Reproduction steps

1. Acquire mesh with the weird faces as described in the description.
2. Apply a PBR material on all the faces
3. Teleport to any other region
4. One of the faces has now lost PBR material
5. Logout and login
6. Item looks correct again, until step 3 is repeated.

[AtlasLinden]

Hi KrsityKu, Do other users also see this issue? This could be related to an old open issue regarding an extra side being given to a mesh upon upload which can cause a bug similar to this when applying a new texture. https://github.com/secondlife/jira-archive/issues/4046 Are you able to reproduce this issue on a mesh where llGetNumberOfSides() returns the the same value as what you've inspected?

[KrsityKu]

Yes other people could see it, on the first teleport in, it would look fine, but if I detached and re-attached a few times, it would break. Also, if I rezz it on the ground others saw the issue too.

As far as I can tell llGetNumberOfSides() always returns 2 for that specific mesh, and using edit tools on the item, I can always see 3 faces.

[KrsityKu]

It might be a similar issue to the one you've listed - I've just tried to apply unique tint to all 3 faces on legacy materials, re-rezzing the item changed tint value of the faces to the same as another to have only 2 unique colours. If you'd like to see it in world, my SL name is Kristy Aurelia.

Edit: I messed around with it some more, if I tint legacy colours all unique, and re-rezz, or make a copy of the item... it resets the error face to be what it should be based on the correct face. Could it be that whatever viewer does to 'fix' the mystery face is incorrectly resetting PBR material rather than copying over from the correct face?

Edit 2: this is interesting, adding a script to the item, while all 3 faces are unique colours, resets the broken face to match. And if PBR is applied to all 3 faces, doing the same thing causes the 3rd face to swap to legacy materials. Trying to change any material properties on that face, also immediately reverts to the default value.

[AtlasLinden]

Hi KrsityKu, Unfortunately, I'd expect this issue to persist for any changes due to the 3rd face error in this specific mesh. Asking the creator to reupload the mesh could be a solution for this but it may still hit the original error. Stay tuned for a fix for https://github.com/secondlife/jira-archive/issues/4046.

Please let us know if you're able to reproduce this issue with a mesh that doesn't contain this error.

[KrsityKu]

Hi, Atlas. Considering this specific mesh is from at least 2020 and the bug you mentioned dates to 2018, I would assume there are plenty of other meshes experiencing the same issue, and probably some that are made by creators who are no longer active, but their meshes are still being used.

The two meshes I've experienced this issue with both have the erroneous faces.

[KrsityKu]

Hello! I've managed to reproduce a mesh that breaks it using tips from https://github.com/secondlife/viewer/issues/1901

Here's a mesh I've exported from Blender, while the Blender version I've used doesn't allow naming multiple materials with the same name, manually editing .dae file bypassed that, and it is possible that older version of Blender or different tools might result in duplicate face material names. BrokenSphere.zip The viewer has no problems uploading this mesh, and it report it as having 2 faces, while LSL only shows 1 face. And it has the same behaviour of one of the faces swapping back textures as in the original post.

Hopefully this will help fixing the uploader part of this bug. (Assuming .dae uploads are not going to be removed once glTF meshes are supported)

However the handling of already uploaded broken meshes still needs fixing.

Edit: Re-reading Issue 1901 I realised that my reproduction is a bit different, but it does end up with same broken faces in SL - as I was trying to apply two materials with the same name, not same material on two different faces.

[akleshchev]

Yeah, that sphere is weird. I assigned two different textures (not materials) to those two faces, but as soon as I 'wear' it, only one texture remains.

[KrsityKu]

My understanding is that the viewer has some sort of workaround where it applies texture from a valid face onto the broken face in Blinn-Phong mode, but that behaviour is not replicated in PBR, so it reverts back to whatever the BP workaround sets it to.

So in short, this needs a 2 part fix:

1. Fixing mesh uploader or the asset server to detect and resolve duplicate materials... or reject broken upload with specific error telling people to fix their materials. This way we don't get any more broken meshes uploaded.
2. Fixing PBR version behaviour to mimic BP, because there are many many broken assets already in the wild, since there have been broken meshes uploaded since at least 2018. I think people will start running into more and more of issues with this, as now that Firestorm released PBR viewer, people are starting to experiment with it, and end users are taking their old mod stuff and trying out PBR materials on them.

[akleshchev]

has some sort of workaround where it applies texture from a valid face onto the broken face

Sort of, dosn't work all that well. And it actually covers all textures, pbr material included, but in reality only works for diffuse texture because when 'workaround' triggers (in LLViewerObject::setNumTEs) there is no pbr data yet .

If object has faces, server should be accepting data for all of them.

[akleshchev]

Fixed uploader, will make a ticket for server side.

[KrsityKu]

server side

That's interesting. Does that mean that llGetNumberOfSides() is wrong by reporting less faces than the viewer, rather than viewer being wrong and detecting too many faces?

[akleshchev]

Yes, model (sphere) has 2 faces, but server accepts only 1 TE post upload. Part of the problem was: viewer missreported face data during upload. Face count was capped by provided material count. If two faces used same texture, it will be 1 material and only one face gets packed instead of both. But since model still has two faces, viewer treats it like it has 2 faces even if server sends only one TE.

[canny[bot]]

This issue has been linked to a Canny post: PBR not saved :tada:

[georgebproductengine]

Passed QA. Verified on the Second Life Release 7.1.10.10582490681 (64bit) on Win10/OSX in the scope of https://github.com/secondlife/iqa/issues/316.

[KrsityKu]

I've asked about this issue during SUG meeting, here's the reproducible steps for server side:

1. Get the in-world mesh object mentioned in https://github.com/secondlife/viewer/issues/1901 (I can provide this in world or on the test grid, I am Kristy Aurelia in SL, so feel free to poke me if you need it) or any other broken mesh, like the stockings mentioned in my original report.
2. Clear all PBR materials
3. Clear all Blinn-Phong Materials
4. Make Blinn-Phong same colour on all faces - for example - blue
5. Create a PBR material in the inventory, something that looks different from the Blinn-Phong, so like a red wood material
6. Apply the PBR material to all faces
7. Pick up the object and then rezz it again. Or shift-Move to create a copy.
8. One of the faces will revert back to Blinn-Phong.

Note: Since the viewer side fix, uploading a new copy of the mesh will result in a working mesh. But asking creators to check all of their meshes and reuploading them is not really feasible as the broken meshes have been uploaded for years.

[KrsityKu]

Since this is closed now, is there a way for public to track progress on the server side issue? As per comment: https://github.com/secondlife/viewer/issues/853#issuecomment-2265382587

Also, could this https://github.com/secondlife/viewer/issues/853#issuecomment-2327336094 be reposted on the server side issue, as that is the repro for it.

[AtlasLinden]

@KrsityKu thanks for your earlier comment. This will be copied across to the server side issue. Also a note has been made to leave a comment on this issue when a fix is implemented.