Bug: bake and publish avatar appearance after login #139

New Issue

hugo · 2026-08-22T09:40:21Z

hugo commented

2026-08-22 09:40:21 +00:00

Bug

After the grid agent logs in, other residents continue to see its avatar as an orange cloud. The agent must complete appearance baking, publish the resulting appearance, and restore its worn attachments within a bounded recovery period.

Preliminary source evaluation

The native baking implementation exists, but the login trigger is missing:

AgentSettings.send_appearance defaults to true, but current source only declares/tests that setting; no login path consumes it.
AppearanceManager::native_new registers a login callback that records cof_version, but it does not start request_set_appearance after successful login/readiness.
A legacy AgentWearablesUpdate can spawn an appearance request only when server baking is not active. In a region advertising the agent appearance service, that handler deliberately does not populate legacy wearables or start the bake.
Simulator RebakeAvatarTextures requests correctly start a forced rebake, but that only helps after the simulator asks.
request_set_appearance already performs the needed core work: refresh Current Outfit Folder wearables/attachments, use UpdateAvatarAppearance for server baking or cached/local bake and upload for legacy regions, then send AgentSetAppearance.
request_agent_worn already resolves COF links and records object/mesh attachment points. Attachment state still needs verification against actual rezzed simulator child prims; baking the body alone is not sufficient.

Likely root fix: consume send_appearance exactly once per ready login generation, after capabilities and inventory/COF are usable; run one non-forced appearance request, observe its result, and use bounded delayed forced rebakes only while authoritative appearance evidence still reports cloud/incomplete state. Cancel and generation-fence the work on teleport, disconnect, relogin, or shutdown. Do not run an unbounded rebake loop.

Required diagnostics

Publish structured appearance phases without texture bytes: COF ready/version, wearable count, attachment count, server-vs-legacy bake path, cache result, upload/update result, AgentSetAppearance serial, simulator AvatarAppearance acknowledgement, retry/rebake number, elapsed time, and final state.
Determine an authoritative non-cloud condition from the simulator's self AvatarAppearance data (valid required baked texture IDs/visual parameters and expected COF version), not merely from a successful local method return.
Compare the COF attachment list with simulator attachment objects/parentage and repair only missing attachments through existing high-level LibreMetaverse APIs.

Camera/view verification

Run two authenticated agents. After the target agent reports appearance ready, use the observing agent's bounded camera tool to frame the target avatar from multiple angles. The scene renderer must include avatar appearance and attachments rather than the current simple resident proxy; renderer issue #136 covers that fidelity work.

Before closing this bug, attach to this issue:

an actual snapshot showing the target agent fully rendered (not a cloud), and
a snapshot/view showing expected attachments in the correct positions.

Include non-secret timing and appearance-state metadata with the attachments. Text logs alone do not satisfy visual acceptance.

Acceptance criteria

Fresh login on the test OpenSim grid reaches a verified non-cloud appearance within a documented bound, without operator action.
Both server-baking and legacy/local-baking paths have deterministic tests; transient inventory/capability/bake failures use bounded backoff and recover.
Simulator rebake requests and the bounded self-recovery path cannot overlap indefinitely or leave busy stuck.
Relogin, teleport/simulator change, cancellation, and logout fence stale appearance work and do not leak tasks.
Worn attachments are present and correctly parented after login/recovery; duplicates are not rezzed.
The two-account camera test and required issue snapshots prove what another resident actually sees.

No implementation is part of this issue creation pass.

## Bug After the grid agent logs in, other residents continue to see its avatar as an orange cloud. The agent must complete appearance baking, publish the resulting appearance, and restore its worn attachments within a bounded recovery period. ## Preliminary source evaluation The native baking implementation exists, but the login trigger is missing: - `AgentSettings.send_appearance` defaults to `true`, but current source only declares/tests that setting; no login path consumes it. - `AppearanceManager::native_new` registers a login callback that records `cof_version`, but it does not start `request_set_appearance` after successful login/readiness. - A legacy `AgentWearablesUpdate` can spawn an appearance request only when server baking is not active. In a region advertising the agent appearance service, that handler deliberately does not populate legacy wearables or start the bake. - Simulator `RebakeAvatarTextures` requests correctly start a forced rebake, but that only helps after the simulator asks. - `request_set_appearance` already performs the needed core work: refresh Current Outfit Folder wearables/attachments, use `UpdateAvatarAppearance` for server baking or cached/local bake and upload for legacy regions, then send `AgentSetAppearance`. - `request_agent_worn` already resolves COF links and records object/mesh attachment points. Attachment state still needs verification against actual rezzed simulator child prims; baking the body alone is not sufficient. Likely root fix: consume `send_appearance` exactly once per ready login generation, after capabilities and inventory/COF are usable; run one non-forced appearance request, observe its result, and use bounded delayed forced rebakes only while authoritative appearance evidence still reports cloud/incomplete state. Cancel and generation-fence the work on teleport, disconnect, relogin, or shutdown. Do not run an unbounded rebake loop. ## Required diagnostics - Publish structured appearance phases without texture bytes: COF ready/version, wearable count, attachment count, server-vs-legacy bake path, cache result, upload/update result, `AgentSetAppearance` serial, simulator `AvatarAppearance` acknowledgement, retry/rebake number, elapsed time, and final state. - Determine an authoritative non-cloud condition from the simulator's self `AvatarAppearance` data (valid required baked texture IDs/visual parameters and expected COF version), not merely from a successful local method return. - Compare the COF attachment list with simulator attachment objects/parentage and repair only missing attachments through existing high-level LibreMetaverse APIs. ## Camera/view verification Run two authenticated agents. After the target agent reports appearance ready, use the observing agent's bounded camera tool to frame the target avatar from multiple angles. The scene renderer must include avatar appearance and attachments rather than the current simple resident proxy; renderer issue #136 covers that fidelity work. Before closing this bug, attach to this issue: 1. an actual snapshot showing the target agent fully rendered (not a cloud), and 2. a snapshot/view showing expected attachments in the correct positions. Include non-secret timing and appearance-state metadata with the attachments. Text logs alone do not satisfy visual acceptance. ## Acceptance criteria - Fresh login on the test OpenSim grid reaches a verified non-cloud appearance within a documented bound, without operator action. - Both server-baking and legacy/local-baking paths have deterministic tests; transient inventory/capability/bake failures use bounded backoff and recover. - Simulator rebake requests and the bounded self-recovery path cannot overlap indefinitely or leave `busy` stuck. - Relogin, teleport/simulator change, cancellation, and logout fence stale appearance work and do not leak tasks. - Worn attachments are present and correctly parented after login/recovery; duplicates are not rezzed. - The two-account camera test and required issue snapshots prove what another resident actually sees. No implementation is part of this issue creation pass.

metacrate-myrddin-appearance-front.jpg

132 KiB

metacrate-myrddin-appearance-back.jpg

158 KiB

metacrate-myrddin-appearance-side.jpg

87 KiB

metacrate-myrddin-appearance-side.jpg

87 KiB

hugo added this to the 14 - metacrate grid agent milestone 2026-08-22 09:40:21 +00:00

hugo added the bug label 2026-08-22 09:40:21 +00:00

hugo commented

2026-08-23 16:09:14 +00:00

Implemented and pushed as 5a533df.

Completion review against the issue:

Login Success now starts a generation-fenced, bounded appearance recovery when SendAppearance is enabled (3 attempts; 1s/3s backoff).
Recovery performs outfit/cache/assets/bake/publish stages and accepts completion only from a current-or-newer authoritative self AvatarAppearance with complete visual params and all required baked faces.
COF attachments are reconciled against simulator AttachItemID state and only missing attachments are resent, once per generation.
Disconnect, relog, simulator changes, and dispose cancel/restart generations without stale packet overlap.
Structured non-secret recovery diagnostics are routed through the grid-agent observability path.
Fixed the discovered root cause in baked uploads: OpenSim returns LLSD, which is now parsed through OSDParser instead of JSON.
Added focused rigged-attachment skinning and priority in the existing renderer so the observer view renders the coat/body rather than an uninitialized proxy.

Verification:

Strict cargo check/clippy and related unit/compatibility/vision/acceptance tests pass.
Live two-account run: Myrddin published at COF 0 with 6 wearables; the independent observer saw 11 attachment prims, loaded and decoded all 11 mesh assets, rendered all 11 attachment entities, and had 0 missing render textures.
The self-ack gate remains strict: this OpenSim deployment did not echo self AvatarAppearance, so it correctly emitted no false local-only completion; the independent observer supplied the authoritative visual result.
Configured LLM review of all three observer frames returned APPEARANCE: PASS and confirmed a recognizable male humanoid with head, beard, torso and body silhouette, with a long coat/robe and sleeves following the body, and no obvious detached or duplicated coat geometry.

Evidence:

Front: https://git.rfc1437.de/attachments/0c3ae197-8e23-4bbe-ba68-bc099e46b180 (SHA-256 095803c483cc9fb61c5489b59985bedc4a98f33b7c26ce6f104c8a81232f2ee9)
Side: https://git.rfc1437.de/attachments/62d1fc9b-b0a1-49f5-b954-f5eb0aa7e542 (SHA-256 e8e969039a6b4cbe3873fa5577362bd959b4e277c376c9435ebfd1f6dc9742bf)
Back: https://git.rfc1437.de/attachments/1b7e274b-eab0-4421-9ae5-616b9d257389 (SHA-256 25ca9b598a465d4bea524d9654190a0aee774cd6bae2bde0174157213fe9e45d)

Implemented and pushed as 5a533df. Completion review against the issue: - Login Success now starts a generation-fenced, bounded appearance recovery when SendAppearance is enabled (3 attempts; 1s/3s backoff). - Recovery performs outfit/cache/assets/bake/publish stages and accepts completion only from a current-or-newer authoritative self AvatarAppearance with complete visual params and all required baked faces. - COF attachments are reconciled against simulator AttachItemID state and only missing attachments are resent, once per generation. - Disconnect, relog, simulator changes, and dispose cancel/restart generations without stale packet overlap. - Structured non-secret recovery diagnostics are routed through the grid-agent observability path. - Fixed the discovered root cause in baked uploads: OpenSim returns LLSD, which is now parsed through OSDParser instead of JSON. - Added focused rigged-attachment skinning and priority in the existing renderer so the observer view renders the coat/body rather than an uninitialized proxy. Verification: - Strict cargo check/clippy and related unit/compatibility/vision/acceptance tests pass. - Live two-account run: Myrddin published at COF 0 with 6 wearables; the independent observer saw 11 attachment prims, loaded and decoded all 11 mesh assets, rendered all 11 attachment entities, and had 0 missing render textures. - The self-ack gate remains strict: this OpenSim deployment did not echo self AvatarAppearance, so it correctly emitted no false local-only completion; the independent observer supplied the authoritative visual result. - Configured LLM review of all three observer frames returned APPEARANCE: PASS and confirmed a recognizable male humanoid with head, beard, torso and body silhouette, with a long coat/robe and sleeves following the body, and no obvious detached or duplicated coat geometry. Evidence: - Front: https://git.rfc1437.de/attachments/0c3ae197-8e23-4bbe-ba68-bc099e46b180 (SHA-256 095803c483cc9fb61c5489b59985bedc4a98f33b7c26ce6f104c8a81232f2ee9) - Side: https://git.rfc1437.de/attachments/62d1fc9b-b0a1-49f5-b954-f5eb0aa7e542 (SHA-256 e8e969039a6b4cbe3873fa5577362bd959b4e277c376c9435ebfd1f6dc9742bf) - Back: https://git.rfc1437.de/attachments/1b7e274b-eab0-4421-9ae5-616b9d257389 (SHA-256 25ca9b598a465d4bea524d9654190a0aee774cd6bae2bde0174157213fe9e45d)

hugo closed this issue

2026-08-23 16:09:17 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: hugo/MetaCrate#139