#1465: Small material textures encode, and an encode failure no longer freezes the material editor #1474
No reviewers
Labels
No labels
amd
avatars
bug
builder
cannot-reproduce
crash
epic
feature
from-viewer
gl-removal
known-limitation
monitoring
parity
perf
platform
priority
critical
priority
high
priority
low
priority
medium
provenance
rendering
rt
status
in-progress
status
testing
status
up-next
triage
ui
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sky_line/Slipstream!1474
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "TheSlowly/Slipstream:material-encode-stuck-1465"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #1465.
Based on main; the ticket mentions #1443, which isn't merged yet.
Tests:
j2c_small_image_encode_checks.py,material_encode_failure_checks.pyin indra/newview/tests.When an imported glTF texture fails to encode, convertToUploadFile returns null but the texture's upload id stays set. On save, saveTextures counted it as pending, saveTexture returned early without calling either callback, and mUploadingTexturesCount never got back to zero, so the editor stayed disabled and could not be closed. saveIfNeeded now checks for pending textures with no encoded data before any upload starts. It shows the existing CannotEncodeFile error naming those textures, uploads nothing (so nothing is charged) and leaves the editor enabled, so the texture can be replaced or the editor closed. The texture is not resized or dropped. The material editor's debug logging no longer dereferences the null image either. Test-Plan: python3 indra/newview/tests/material_encode_failure_checks.py In world: upload a glTF material with a texture that fails to encode (the 64x17 stained_glass one) and press Save. Expect "Unable to encode file: <material>: <texture>", and an editor that is still enabled and closes normally. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>The J2C encoder left OpenJPEG at its default of 6 resolution levels, which needs both sides to be at least 32 pixels, and rejects anything smaller when compression starts. Uploads scale images to powers of two first, so the 64x17 material texture became 64x16 and failed to encode, and any small texture upload failed the same way. The encoder now uses as many levels as the smaller side allows (1 + log2 of it), never more than 6 (the same rule the reference encoder uses). The image itself is not changed. Test-Plan: python3 indra/newview/tests/j2c_small_image_encode_checks.py (fails before, OK after; compiles the helper with g++ and checks 64x16 -> 5, 4x4 -> 3, 2048x2048 -> 6) In world: upload the stained_glass glTF material; every texture uploads. Upload a 16x16 and a 64x8 texture through Upload > Image; both upload and display. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>Superseded by your fix on main (
b2d53d1b54,2ff357f3b4,fdb5a110bf), closing this one. The ticket's still in testing; I'll check your version in world.Pull request closed