Developer kits Intro
This is a short introduction mainly aimed at Developer kit creators who are not familiar with Blender and Avastar but want to prepare their Developer kit so that it can be used most efficiently from within Blender/Avastar.
Purpose of the Developer kit Manager
Developer kits basically are reference models of already existing (mostly but not restricted to human) Avatar creations. A Developer kit is typically used for creating additional content (attachments). Hence a Developer kit must ensure that whatever attachment is created with it can be attached easily to the original model in SL (or OpenSim).
Developer kits are often distributed as Collada files, less often they are provided as Blend files and sometimes they are even provided with an Avastar Rig. However in all cases the attachment creators have to take care to always import the correct Collada files using the correct import options, or they need to load the Developer kit blend file and take care to never overwrite the Developer kit itself.
The Developer kit Manager
The Developer kit Manager is sort of a “man in the middle” as it takes an original Developer kit file (Collada or blend) as it was distributed by the Developer kit Creator. The Developer kit is then converted on the fly into an equivalent Avastar rig that then can be used by the attachment creator. Provided the Developer kit creator has taken care to obey some pretty straight forward rules:
- Collada files must be correctly importable into SL
- Blend files must contain correct defined Rigs
- The Developer kit creator must provide information about some basic properties to allow an attachment creator to create best matching attachments (see the chapter What the Developer kit creator needs to provide further down)
Configuring the Developer kit Manager
Avastar provides an area in the user Interface where attachment creators can add Developer kits for super easy use during their attachment creation workflow.
Clicking on one of the listed items, a new character plus its Armature are created from the related Developer kit, ready made for direct usage with Avastar.
Furthermore an attachment creator can integrate more Developer kits as necessary and at any time (see the button Add more Developer kits… in the image). Of course this needs some input from the developer kit Creator (see below)
Adding an entry to the Developer kit Manager
- The attachment creator must get the Developer kit from the developer kit creator. The developer kit either comes as a blend file or as a Collada (dae) file with a model and Rig ready made for Secondlife.
- The attachment creator also needs to get a couple of customization parameters of the developer kit from the Developer kit creator.
- The attachment creator opens the Developer kit Configuration panel in Avastar, specifies the file location and the custom parameters.
- And finally the attachment creator creates a new Developer kit Prefix. The new Prefix will show up in the Developer kit listing, which i have shown you at the very top of this article.
Typical Workflow with Developer kits
When the attachment creator clicks on a Developer kit button as described above, then the related kit is added to the current scene. Whatever was in the scene before will remain at its place. What exactly the attachment creator will get added to the scene is fully controlled by the developer kit creator. Here is an example:
Step 1: The Basic adjustment
The very first thing the attachment creator will do is creating an adjustment and adjusting the attachment to the Developer kit model. This is mostly a matter of using appropriate modelling techniques to get the attachment to match with the Developer kit.
I will not get into detail here. The image just shows how it might look after doing the basic adjustments.
Step 2: The Binding
In the next step the attachment creator will Bind the Attachment to the Developer kit Rig. With Avastar this is a matter of a few clicks, where the attachment creator decides from where the attachment shall get its weights (from ‘Meshes’ means the weights are copied from the developer kit) and then call the Bind to Armature Operation.
Step 3: The weighting Workflow
Once the model is adjusted and bound to the Armature, the attachment creator will proceed with checking the weighting and adjusting the weights where necessary to match the Developer kit as good as possible.
We have provided a Workflow panel from where the attachment creator can select the Skin&Weight Workflow. This workflow prepares the Blender scene such that the attachment creator can select the bones, add/remove weights as necessary, and rotate the Bones to test if the weighting is good.
Step 4: Posing and Animation
Once the weights have been set up and tested, the attachment creator might also want to go into posing and animation.
In this case the attachment creator will switch to the Pose&Animation workflow where he/she can use all animation features from Blender to create still poses or animations as they like.
Avastar provides a decent panel for controlling which part of the Rig shall be displayed. The Rig Display panel is probably one of the most used panels we have.
Here the attachment creator can also change the display style from Shape to Octahedral or Stick.
Step 5: Appearance Sliders
Avastar provides a full emulation of the Secondlife Avatar Appearance system. The Appearance sliders are all located in the Appearance Panel and can be used at any time during a user session for checking if the variations of the appearance sliders work well with the user attachment.
Step 6: Export to SL
- Select the mesh attachment(s) for export.
- Call the Avastar Collada exporter as usual.
- When importing the attachment you will
- enable with weights
- disable with joint offsets1
1 If you create an attachment that uses its own bones (Bones which are not already used by the Developer kit) then you probably also want to enable with joint offsets.
What you need to provide to your attachment makers
The developer kit creator needs to provide some technical information about the kit. Best is to add the information to the developer kit documentation. We suggest that Developer kit creators create a text file named after their brand and kit name. This file shall contain the info as a set of parameter definitions. Aside you see an example definition file. The attachment creator will need this later.
Please also read the remarks below. The Avastar documentation contains a very detailed document about how to create your own developer kit
Filename: brandname_devkitname.config devkit_brand = "brandname" devkit_name = "devkitname" scale = 0.01 rig_type = "SL"(1) joint_type = "POS"(2) is_male = False restpose_type = "other-pose"(3) is_bindpose = True(4) is_edited = True
(1): Can be “SL” or “AVASTAR”
(2): Can be “POS” or “PIVOT”, we recommend you always work with the PIVOT Rig
(3): Can be “t-pose” or “other-pose”
(4): If the developer kit restpose type is not the T-pose and if the restpose was created only by rotating the bones, then the rig is most probably good for using the bind pose option.
If the developer kit is mostly non human and comes with a heavily edited rig with bones moved around (translation) to other places, then we recommend to not use the bind pose option to avoid issues in SL.