Cannot apply PBR Materials on larger linksets

[canny[bot]]

1. Create and link at least 43 objects together, I used prim boxes.

2. Select PBR material in the texture edit tab

3. Drag and drop a material from your inventory onto the Material preview box

4. Material will look applied. But It is not visible to anyone else. De-rezz and re-rezz (or relog), material will disappear.

5. Unlink enough parts so you're at 42 or less linked parts

6. Repeat the process - it will work now.

Tinting faces seems to also have a similar issue - the change it tint just does not apply.

Note: seems like number of faces matters too, if using mesh or different type prims you might need to link more or less objects to reproduce the issue.

Editing individual links or faces works fine.

Edit: 43 * 6 = 258... I bet it works with 255 Faces :D

https://secondlife.canny.io/admin/board/bug-reports/p/cannot-apply-pbr-materials-on-larger-linksets

[canny[bot]]

This issue has been linked to a Canny post: Cannot apply PBR Materials on larger linksets :tada:

[maestrolinden]

I took a peek at the simulator code, and it appears that for there is a MAX_TASK_UPDATES=256 constant for GLTF material updates. If a viewer submits an update request and exceeds this limit (based on the "object_id" counts in the request), the simulator will respond with an HTTP 429 with a "too many prim updates. (max: 256)" message, and reject the update.

Since GLTF material updates happen on a per-face basis, I suspect that each 'object_id' is a prim face, so this failure will trigger whenever >256 prim faces are updated at once (which aligns with what Himechan noted in Canny). Since GLTF material updates happen on a per-face basis, I suspect that each 'object_id' is actually just a prim face. Since a single prim can have up to 9 faces, a 256-prim linkset could potentially have about 256*9 faces in total.

I believe that either the server-side limit needs to be increased or the viewer needs to modify how it submits these requests.

[akleshchev]

I believe that either the server-side limit needs to be increased or the viewer needs to modify how it submits these requests.

Can server side support some kind of side == -1 value to apply to whole object?

P.S. Spliting into 256 batches is trivial and doesn't look like it will negatively affect selection processing, will do.

[valeriiaaproductengine]

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.