From d34834beb64d5ab1cf43d58759f9396045680651 Mon Sep 17 00:00:00 2001 From: Juanma Hidalgo Date: Mon, 13 Jan 2025 17:28:56 +0100 Subject: [PATCH 1/3] feat: add ADR-278 introducing the field outlineCompatible for wearables --- .../ADR-278-wearable-outline-compatibility.md | 102 ++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 content/ADR-278-wearable-outline-compatibility.md diff --git a/content/ADR-278-wearable-outline-compatibility.md b/content/ADR-278-wearable-outline-compatibility.md new file mode 100644 index 00000000..cc502fe4 --- /dev/null +++ b/content/ADR-278-wearable-outline-compatibility.md @@ -0,0 +1,102 @@ +--- +adr: 278 +date: 2025-01-13 +title: Wearable Outline Compatibility Metadata +status: Draft +type: Standards Track +spdx-license: CC0-1.0 +authors: + - jhidalgo +--- + +## Context and Problem Statement + +The current avatar rendering system uses inverted face rendering for outlines in Medium/High quality settings. This creates conflicts with custom meshes that have manual outlines or inverted normals, resulting in incorrect rendering. Currently, there is no way to identify incompatible assets before they are rendered, leading to visual artifacts and inconsistent appearance. + +Key issues: +- Custom meshes with manual outlines conflict with the system outline rendering +- Inverted normal meshes render incorrectly with the outline pass +- No standardized way to identify outline-incompatible assets beforehand +- No metadata exists to flag rendering compatibility issues + +## Proposed Solution + +Add an `outlineCompatible` boolean field to the wearable configuration metadata to explicitly indicate whether a wearable is compatible with the system's outline rendering pass. + +The wearable configuration schema will be extended as follows: + +```typescript +type WearableConfiguration = { + // ... existing fields ... + data: { + // ... existing data fields ... + /** Indicates if the wearable is compatible with the outline rendering system */ + outlineCompatible: boolean + } +} +``` + +Example wearable configuration with the new field: + +```json +{ + "name": "Special Hat", + "category": "hat", + "data": { + "replaces": [], + "hides": ["hair"], + "tags": ["special", "hat"], + "outlineCompatible": true, + "representations": [ + // ... representations ... + ] + } +} +``` + +### Benefits + +1. **Clear Compatibility Indication**: Creators can explicitly specify if their wearable works with the outline system +2. **Prevention of Visual Artifacts**: Rendering systems can check compatibility before applying outline effects +3. **Better Creator Guidelines**: Clear documentation can be provided about outline compatibility requirements +4. **Future Extensibility**: Foundation for additional rendering compatibility flags if needed + +## Technical Details + +- The `outlineCompatible` field defaults to `true` if not specified +- When `false`, the renderer should skip outline processing for the wearable +- This metadata should be validated during the wearable upload process +- Existing wearables will need to be reviewed and updated with appropriate values + +## Alternatives Considered + +1. **Automatic Detection**: Analyzing mesh normals and geometry to detect compatibility automatically. Rejected due to complexity and potential inaccuracy. +2. **Runtime Switching**: Dynamically switching outline modes based on asset testing. Rejected due to performance implications. +3. **Complex Metadata Schema**: Including detailed information about mesh properties and rendering requirements. Rejected to maintain simplicity. + +## Trade-offs + +### Advantages +- Simple implementation +- Clear creator guidelines +- Minimal performance impact +- Easy to validate + +### Disadvantages +- Requires manual specification by creators +- Existing wearables need updating +- Binary approach may not cover all edge cases + +## Implementation Plan + +1. Update wearable schemas to include the new field +2. Modify the Builder UI to expose the outline compatibility toggle +3. Update validation systems to handle the new field (Builder mainly, Catalyst will accept it) +4. Add documentation for creators about outline compatibility +5. Review and update existing wearables + +## Future Considerations + +- Potential expansion to include other rendering compatibility flags +- Tools to help creators test outline compatibility +- Analytics to track outline compatibility issues \ No newline at end of file From e2c52c675da0e9c70ad68e150daccb1b9981d373 Mon Sep 17 00:00:00 2001 From: Juanma Hidalgo Date: Wed, 15 Jan 2025 14:42:49 +0100 Subject: [PATCH 2/3] feat: renamed ADR to VRM one --- content/ADR-278-vrm-export-control.md | 112 ++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 content/ADR-278-vrm-export-control.md diff --git a/content/ADR-278-vrm-export-control.md b/content/ADR-278-vrm-export-control.md new file mode 100644 index 00000000..4075babe --- /dev/null +++ b/content/ADR-278-vrm-export-control.md @@ -0,0 +1,112 @@ +--- +adr: 278 +date: 2025-01-13 +title: VRM Export Control for Wearables +status: Draft +type: Standards Track +spdx-license: CC0-1.0 +authors: + - jhidalgo +--- + +## Context and Problem Statement + +The Explorer's VRM export feature allows users to export their avatars for use in other platforms. However, this creates potential issues: + +- Some creators want to restrict their wearables from being exported +- Brand assets may only be licensed for use within Decentraland +- No mechanism exists to control VRM export permissions per wearable + +## Proposed Solution + +Add a `blockVrmExport` boolean field to the wearable configuration metadata to explicitly indicate whether a wearable can be exported as VRM. + +The wearable configuration schema will be extended as follows: + +```typescript +type WearableConfiguration = { + // ... existing fields ... + data: { + // ... existing data fields ... + /** Indicates if VRM export should be blocked for this wearable */ + blockVrmExport: boolean + } +} +``` + +Example wearable configuration with the new field: + +```json +{ + "name": "Special Hat", + "category": "hat", + "data": { + "replaces": [], + "hides": ["hair"], + "tags": ["special", "hat"], + "blockVrmExport": false, + "representations": [ + // ... representations ... + ] + } +} +``` + +### Implementation Details + +- The `blockVrmExport` field defaults to `false` if not specified (allowing VRM export by default) +- When `true`, the Explorer will prevent VRM export of any avatar wearing this item +- The field will be included in the wearable metadata stored in Catalyst +- The UI will show a tooltip explaining why VRM export is blocked when attempted + +## Technical Details + +- Field stored in Catalyst as part of wearable metadata +- Explorer must check all equipped wearables before allowing VRM export +- UI feedback required when export is blocked +- Value is set during wearable deployment and requires a new content submission to update + +## Alternatives Considered + +1. **Smart Contract Storage**: Storing the flag in item metadata on-chain. Rejected due to: + - Requires transactions for updates + - Needs curator review for changes + - Increased complexity for simple permission + +2. **Collection-Level Control**: Setting export permission at collection level. Rejected because: + - Less granular control + - Doesn't address mixed-use cases within collections + +3. **Whitelist System**: Explicit allowlist for VRM export. Rejected due to: + - Additional complexity + - Default-deny would break existing use cases + +## Trade-offs + +### Advantages +- Simple implementation +- Easy to update +- Granular per-wearable control +- Consistent with other wearable metadata storage +- Clear user feedback + +### Disadvantages +- Requires content update to change settings +- Less flexible than database storage +- Additional UI complexity in Builder +- Potential user confusion about blocked exports + +## Implementation Plan + +1. Update wearable metadata schema +2. Add UI controls in Builder wearable submission +3. Modify Explorer VRM export to check permissions +4. Add user feedback for blocked exports +5. Update documentation for creators + +## Future Considerations + +- Analytics tracking for export blocks +- Potential for time-based export restrictions +- Integration with licensing system +- Expansion to other export formats \ No newline at end of file From add1edff350e8c75a84dd4de7297ca3dbd6497ca Mon Sep 17 00:00:00 2001 From: Juanma Hidalgo Date: Wed, 15 Jan 2025 14:43:41 +0100 Subject: [PATCH 3/3] feat: remove the other ADR --- .../ADR-278-wearable-outline-compatibility.md | 102 ------------------ 1 file changed, 102 deletions(-) delete mode 100644 content/ADR-278-wearable-outline-compatibility.md diff --git a/content/ADR-278-wearable-outline-compatibility.md b/content/ADR-278-wearable-outline-compatibility.md deleted file mode 100644 index cc502fe4..00000000 --- a/content/ADR-278-wearable-outline-compatibility.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -adr: 278 -date: 2025-01-13 -title: Wearable Outline Compatibility Metadata -status: Draft -type: Standards Track -spdx-license: CC0-1.0 -authors: - - jhidalgo ---- - -## Context and Problem Statement - -The current avatar rendering system uses inverted face rendering for outlines in Medium/High quality settings. This creates conflicts with custom meshes that have manual outlines or inverted normals, resulting in incorrect rendering. Currently, there is no way to identify incompatible assets before they are rendered, leading to visual artifacts and inconsistent appearance. - -Key issues: -- Custom meshes with manual outlines conflict with the system outline rendering -- Inverted normal meshes render incorrectly with the outline pass -- No standardized way to identify outline-incompatible assets beforehand -- No metadata exists to flag rendering compatibility issues - -## Proposed Solution - -Add an `outlineCompatible` boolean field to the wearable configuration metadata to explicitly indicate whether a wearable is compatible with the system's outline rendering pass. - -The wearable configuration schema will be extended as follows: - -```typescript -type WearableConfiguration = { - // ... existing fields ... - data: { - // ... existing data fields ... - /** Indicates if the wearable is compatible with the outline rendering system */ - outlineCompatible: boolean - } -} -``` - -Example wearable configuration with the new field: - -```json -{ - "name": "Special Hat", - "category": "hat", - "data": { - "replaces": [], - "hides": ["hair"], - "tags": ["special", "hat"], - "outlineCompatible": true, - "representations": [ - // ... representations ... - ] - } -} -``` - -### Benefits - -1. **Clear Compatibility Indication**: Creators can explicitly specify if their wearable works with the outline system -2. **Prevention of Visual Artifacts**: Rendering systems can check compatibility before applying outline effects -3. **Better Creator Guidelines**: Clear documentation can be provided about outline compatibility requirements -4. **Future Extensibility**: Foundation for additional rendering compatibility flags if needed - -## Technical Details - -- The `outlineCompatible` field defaults to `true` if not specified -- When `false`, the renderer should skip outline processing for the wearable -- This metadata should be validated during the wearable upload process -- Existing wearables will need to be reviewed and updated with appropriate values - -## Alternatives Considered - -1. **Automatic Detection**: Analyzing mesh normals and geometry to detect compatibility automatically. Rejected due to complexity and potential inaccuracy. -2. **Runtime Switching**: Dynamically switching outline modes based on asset testing. Rejected due to performance implications. -3. **Complex Metadata Schema**: Including detailed information about mesh properties and rendering requirements. Rejected to maintain simplicity. - -## Trade-offs - -### Advantages -- Simple implementation -- Clear creator guidelines -- Minimal performance impact -- Easy to validate - -### Disadvantages -- Requires manual specification by creators -- Existing wearables need updating -- Binary approach may not cover all edge cases - -## Implementation Plan - -1. Update wearable schemas to include the new field -2. Modify the Builder UI to expose the outline compatibility toggle -3. Update validation systems to handle the new field (Builder mainly, Catalyst will accept it) -4. Add documentation for creators about outline compatibility -5. Review and update existing wearables - -## Future Considerations - -- Potential expansion to include other rendering compatibility flags -- Tools to help creators test outline compatibility -- Analytics to track outline compatibility issues \ No newline at end of file