🦴 RFP: A modern Blender-native rigged mesh upload workflow

[bennettgoble]

Request for Proposal (RFP)

Investigate solutions to eliminate the friction in uploading rigged mesh from Blender to Second Life, removing the dependency on outdated third-party plugins and establishing a modern, maintainable workflow for content creators.

Details

Second Life's rigged mesh upload system was designed around Maya's armature format, creating significant compatibility issues for Blender users who represent a large portion of our creator community. Currently, creators are forced to use a proprietary Blender plugins that only supports Blender 3.6 (released October 2022), preventing them from using modern Blender features and improvements, and requiring new creators to learn about bespoke plugin systems on top of general 3D authoring.

This technical investigation should explore multiple approaches to modernize our mesh upload pipeline, with the goal of making Blender a first-class citizen for Second Life content creation while maintaining compatibility with existing content.

Acceptance Criteria

• Document all current incompatibilities between Blender and SL armature systems
• Identify minimum viable changes needed to support native Blender exports
• Design solution that supports Blender 4.0+ (current LTS: 4.2)
• Propose implementation approach with minimal disruption to existing workflows
• Create proof of concept for at least one proposed solution
• Establish testing framework for validating Blender uploads
• Provide effort estimates for full implementation

Expected behavior:

• Direct export from Blender using native tools
• Automatic conversion of Blender conventions to SL requirements
• Clear documentation and templates for creators

Investigation Areas

Option 1: Enhanced Import Conversion

• Develop robust conversion layer in the viewer
• Auto-detect source application (Blender vs Maya)
• Transform armatures on import to match SL expectations
• Pros: No changes to existing content or server-side systems
• Cons: Complexity in the viewer, potential edge cases

Option 2: New Universal Format

• Define new armature format that both tools can target
• Provide conversion tools/plugins for both Blender and Maya
• Pros: Future-proof, clean architecture
• Cons: Requires updates to all creation tools, longer implementation

Option 3: Official Blender Add-on

• Develop and maintain official open-source Blender add-on
• Pros: Full control over creator experience, can iterate quickly
• Cons: Ongoing maintenance burden, need Blender expertise

Testing Considerations

• Test scenarios to cover:
  • Basic humanoid rigging
  • Complex multi-material meshes
  • Facial bones and animations
  • Fitted mesh (clothing)
  • Animesh objects
  • Various Blender versions (4.0, 4.1, 4.2 LTS)

[bennettgoble]

The main barrier to new creators is the fact that we don't have a clean, blender native armature to use for authoring rigged content. Can we simply provide a modified armature, and also update the Second Life mesh upload system to support both the blender native and maya native formats? (Or am I missing something...)

[FelixWolf]

I was working on this for a while https://github.com/felixwolf/plywood-cube
It has the ability to import the SL skeleton, and also import the SL avatar mesh (Although, weight paints for it are incorrect and need to be corrected).

I'd be willing to clean up and contribute / maintain this as a official blender plugin if so desired.

Ideally, with a blender plugin, we'd be able to export native .anim files too.

[Geenz]

A few things:

• Biggest problem is really just we don't have a blender-native rig. The best we can realistically do without breaking import compatibility is convert the current one
• The real ask that I've seen across the board is custom rigs. There's a ton of requirements to get that done that I'm not gonna get into it here - it's complicated. And not something we have the time to do right this second.
• More plugins I feel like don't really help content creators - really the best thing is if we can give something to them to get up and running more than more stuff to download for their blender installs. The ideal needs to be rigging from a clean blender install.

[humbletim]

Geenz's point about a clean Blender install workflow is spot on. Without changing SL armature designs, a couple of alternative angles to consider:

• The Tooling: Instead of a formal add-on, consider a single, distributable Python script. It can still offer a full UI via bpy and be built from a version-controlled source, giving us a stable "dist" file that's trivial for users to update. Blender's built-in Scripting => New => Paste => Alt-P invocation pattern offers one pragmatic initial user integration strategy.

• The Interface: Codify the viewer's battle-tested post-parse, pre-upload data structure and treat it as a stable API target. A pre-formatted buffer conforming to this de facto spec—fed from a file or a live IPC link—could bypass the DAE/glTF parsers entirely. This approach fosters interactive avatar validation features later on, like iteratively applying test animations in the upload previewer to detect and fix nuanced rigging errors before the final upload.

[ebickle]

Blender Compatibility

1. Bone Ends - Blender has bone end points. The Second Life armature only has joint positions, so the lack of 'official' bone end positions for Second Life creates some problems, particularly for fingers.

2. Coordinate Systems - Second Life, Maya, and Blender all have different coordinate systems:

   • Second Life: Z is up/down, X is front/back, Y is left/right.
   • Second Life Attachments: Z is up/down, Y is front/back, X is left/right
   • Blender: Z is up/down, Y is front/back, X is left/right
   • Maya: Y is up/down, Z is front/back, X is left/right

   The main consideration is that "front" in Blender is "side" for Second Life meshes.

Mesh Body Compatibility

Nearly all of the popular Second Life mesh bodies have inconsistencies, requiring different workflows for each one. Some common things that I've encountered are:

3. Joint Positions - Some mesh bodies use the bone pivot attribute values from avatar_skeleton.xml while others use the bone pos attribute values.

4. Rest Poses - Some mesh bodies use a rest pose (referred to as a "bind pose" in Maya) that is different than the Second Life skeleton. This makes uploading from Blender directly difficult, as the mesh needs to be recomputed back into the neutral Second Life T-pose before uploading. Alternately, some people work around this by uploading joint positions - but this can often cause the avatar sliders to stop functioning.

   Here's an example comparing the Second Life armature to one of the popular mesh body dev kits:
   

5. Bone Lengths - Some mesh bodies do not use the correct 'neutral' bone lengths from avatar_skeleton.xml but instead use bone lengths modified by the Second Life appearance sliders. This is often one of two sub-variants, either the "default male" avatar appearance or the "default female" avatar appearance.

Avatar Templates

6. Male/Female Sample Skeleton Files - The avatar templates https://wiki.secondlife.com/wiki/Project_Bento_Resources_and_Information have Male and Female variants (the "default" appearances) rather than the correct neutral bone positions. This is part of what's causing the "Bone Length" problem.

7. Rounding Errors - Many sample avatar files have inconsistent or "rounded off" joint positions for the bones.

Functionality

8. Fitted Mesh Visualization - Blender lacks the ability to visualize rigged fitted mesh. This requires weight painting "blind", uploading, and then checking for weighting issues when modifying avatar appearance sliders in world. The only option for visualizing sliders in Blender is using commercial third-party plugins.

Questions for the Lindens

• What is the official reason why avatar_skeleton.xml has two values for each joint (<bone>): pos and pivot?
• When uploading a rigged mesh to Second Life, which "appearance" should the joint positions be in? Neutral (avatar_skeleton.xml), default female, default male, or something else?