Derender other avatars' attachments per object (Firestorm-style, top-level right-click) #202

New issue

Closed

opened 2026-09-30 05:36:32 +00:00 by sky_line · 1 comment

sky_line commented

2026-09-30 05:36:32 +00:00

Owner

Firestorm lets you right-click any single object and pick Derender / Derender + Blacklist from the top level of the menu, including another avatar's attachments: an obnoxious particle collar, a laggy hair, a blinding bling prim. We can only derender unattached in-world objects.

Current state (ours)

Object menu only: menu_object.xml has Session Derender / Permanent Derender (Object.Derender with temporary / persistent, Object.EnableDerender). menu_avatar_other.xml and menu_attachment_other.xml have no derender entry.
Attachments refused: LLDerenderList::canAdd (llderenderlist.cpp:340) refuses attachments outright (!pObj->isAttachment()), and child prims (root only).
Pie menus (#137): the FS pies already carry the derender slices (remapped to Object.Derender in 1b9c27fae9). The enable check still refuses attachments, so they're disabled on avatars.

Firestorm behaviour (phoenix-firestorm `llviewermenu.cpp`, `LLObjectDerender` / `LLObjectDerenderPermanent`, ~3300-3430)

Menus: top-level Derender and Derender + Blacklist in menu_object, menu_avatar_other and menu_attachment_other (and the pies).
Other avatars' attachments: allowed. The selected attachment (linkset) is killed locally (gObjectList.killObject) and its ID added to the derender list so object updates for it are ignored. Your own attachments are refused, and RLVa can gate it.
Blacklist: "+ Blacklist" persists the asset/object in FSAssetBlacklist across sessions. Plain Derender is session-only.
Sit targets: derendering the object you sit on stands you up (or, under RLVa @unsit, refuses).

To do

Allow attachments of OTHER avatars in LLDerenderList::canAdd. Still refuse your own attachments and your own avatar, and respect RLVa (fartouch / unsit) like FS.
- Attachment linksets derender as a unit: the root attachment plus children.
Menus: add top-level Derender / Derender permanently to menu_avatar_other.xml (acts on the clicked attachment, or every selected attachment) and to menu_attachment_other.xml. Keep menu_object.xml. Make sure the pies' slices enable.
Persistence semantics for attachments: attachment object IDs change every time they're re-worn, so a UUID-keyed permanent derender only lasts until the wearer re-attaches.
- Key permanent attachment derenders on something stable: the owner + attachment point + item/asset, or the mesh/sculpt asset ID, the way FS's blacklist uses the asset.
- Or state clearly in the UI that attachment derender lasts until the item is re-worn.
Render path: make sure a derendered attachment disappears on Vulkan immediately and stays gone:
- its instances leave the GPU scene (instance store / skin store for rigged pieces);
- it doesn't reappear via re-ingest (selfRegisterSweep) or cached object updates (killCacheEntry, as FS does);
- its particles / lights / sounds stop too.
Undo: the Blocked / derender list floater (blocked, derender_to_select) lists attachment entries with the wearer's name, and removing an entry re-requests the object.
Optional FS extras: "Derender all attachments of this avatar" (short of the existing whole-avatar render modes) and FS's animesh kill switch (Tools.DerenderAnimatedObjects).

Related: #137 / #198 (pie menus), avatar render modes (Display > Never / Fully).

Firestorm lets you right-click **any single object** and pick **Derender** / **Derender + Blacklist** from the top level of the menu, including **another avatar's attachments**: an obnoxious particle collar, a laggy hair, a blinding bling prim. We can only derender unattached in-world objects. ## Current state (ours) - **Object menu only:** `menu_object.xml` has *Session Derender* / *Permanent Derender* (`Object.Derender` with `temporary` / `persistent`, `Object.EnableDerender`). `menu_avatar_other.xml` and `menu_attachment_other.xml` have no derender entry. - **Attachments refused:** `LLDerenderList::canAdd` (`llderenderlist.cpp:340`) refuses attachments outright (`!pObj->isAttachment()`), and child prims (root only). - **Pie menus (#137):** the FS pies already carry the derender slices (remapped to `Object.Derender` in 1b9c27fae9). The enable check still refuses attachments, so they're disabled on avatars. ## Firestorm behaviour (phoenix-firestorm `llviewermenu.cpp`, `LLObjectDerender` / `LLObjectDerenderPermanent`, ~3300-3430) - **Menus:** top-level **Derender** and **Derender + Blacklist** in `menu_object`, `menu_avatar_other` and `menu_attachment_other` (and the pies). - **Other avatars' attachments:** allowed. The selected attachment (linkset) is killed locally (`gObjectList.killObject`) and its ID added to the derender list so object updates for it are ignored. Your own attachments are refused, and RLVa can gate it. - **Blacklist:** "+ Blacklist" persists the asset/object in `FSAssetBlacklist` across sessions. Plain Derender is session-only. - **Sit targets:** derendering the object you sit on stands you up (or, under RLVa `@unsit`, refuses). ## To do 1. **Allow attachments of OTHER avatars** in `LLDerenderList::canAdd`. Still refuse your own attachments and your own avatar, and respect RLVa (`fartouch` / `unsit`) like FS. - Attachment linksets derender as a unit: the root attachment plus children. 2. **Menus:** add top-level *Derender* / *Derender permanently* to `menu_avatar_other.xml` (acts on the clicked attachment, or every selected attachment) and to `menu_attachment_other.xml`. Keep `menu_object.xml`. Make sure the pies' slices enable. 3. **Persistence semantics for attachments:** attachment object IDs change every time they're re-worn, so a UUID-keyed permanent derender only lasts until the wearer re-attaches. - Key permanent attachment derenders on something stable: the owner + attachment point + item/asset, or the mesh/sculpt asset ID, the way FS's blacklist uses the asset. - Or state clearly in the UI that attachment derender lasts until the item is re-worn. 4. **Render path:** make sure a derendered attachment disappears on Vulkan immediately and stays gone: - its instances leave the GPU scene (instance store / skin store for rigged pieces); - it doesn't reappear via re-ingest (`selfRegisterSweep`) or cached object updates (`killCacheEntry`, as FS does); - its particles / lights / sounds stop too. 5. **Undo:** the Blocked / derender list floater (`blocked`, `derender_to_select`) lists attachment entries with the wearer's name, and removing an entry re-requests the object. 6. **Optional FS extras:** "Derender all attachments of this avatar" (short of the existing whole-avatar render modes) and FS's animesh kill switch (`Tools.DerenderAnimatedObjects`). Related: #137 / #198 (pie menus), avatar render modes (Display > Never / Fully).

sky_line referenced this issue

2026-10-05 11:23:52 +00:00

Derender / blacklist: audit the existing derender list and wire Area Search Blacklist to it (FS asset blacklist not present) #426

sky_line added this to the Slipstream project

2026-10-06 15:04:15 +00:00

sky_line referenced this issue from a commit

2026-10-10 22:19:26 +00:00

#202: derender other residents' attachments and avatars (Firestorm-style)

sky_line referenced this issue from a commit

2026-10-10 22:19:26 +00:00

#202: avatar pie derender slices act on the avatar; forget blocked local ids with their region

sky_line commented