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.

Before you even begin

So you are a developerkit creator and you want to make the usage of your Developerkit with Avastar as easy as possible. And now you are eager to learn how that can be done. Relax! You are at the good place. But before we get into the details, please take a minute and understand:

Your Right

Of course you are allowed to include Rigs to your Developerkit, even if the rigs are based on the Avastar Rig (changed or unchanged)

Your Duty

You have to take care of your customers on your own. We take no responsibility for your distribution.

The big exception

When you distribute your Developerkit as a Collada file which can be uploaded to SL without errors, then we support your users if they step into issues!

So we strongly recommend to use Collada files instead of blend files because Blender and Avastar change frequently, while the Collada format remained pretty stable over the years

Please take the above seriously. We simply have no capacities to help out every single user on their issues with your Developerkit. So now you know, now we can step forward to…

Purpose of the Developer kit Manager

The following chapter describes the Developer kit Manager from the point of view of an Attachment maker. If you are a Developer kit creator then you still should read through this chapter so you can better understand what your users (attachment makers) are dealing with.

The problem

Developer kits basically are reference models of already existing Avatar creations. A Developer kit is typically used for creating additional content (attachments) for those Avatar creations. Hence a Developer kit must ensure that whatever attachment is created with it can also later be attached easily to the same Avatar 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 makers always must take care to import the correct Collada file into Blender using the correct import options, or they need to load the Developer kit blend file with the correct version of Avastar and possibly a specific version of Blender and take care to never overwrite the Developer kit itself. This is a very error prone approach. The Developer kit manager comes to the rescue…

The Developer kit Manager

The Developer kit Manager takes as input an original Developer kit file (Collada or Blend) as it was distributed by the Developer kit Creator, then it converts the Developer kit into an Avastar Rig, which finally can be used with Avastar…

Provided the Developer kit creator has taken care to obey some pretty straight forward rules:

  • The Collada file(s) must be correctly importable into SL
  • The Developerkit creator must provide information about some basic properties to allow an attachment maker to create best matching attachments (see the chapter What the Developer kit creator needs to provide further down)
  • If your Developerkit is distributed as a Blend file, then it must contain exactly one SL compatible Rig,otherwise it will not work with the Developerkit Manager.

Configuring the Developer kit Manager

Avastar provides an area in the user Interface where attachment makers can add Developer kits for quick access.

When 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 the attachment maker can integrate more Developer kits at any time as necessary (see the button Add/edit configuration in the image). However adding an entry to the Developer kit Manager needs some basic information which must be provided by the developer kit Creator (see below).

Very important: We (Machinimatrix) do not distribute Developer kits together with Avastar. We also have no plans to do that at any time in the future. Any integration work is only done by the attachment maker. But we have made the integration of a new Developer kit a matter of a few clicks as i will show below

Adding an entry to the Developer kit Manager

  1. The attachment maker 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.
  2. The attachment maker also needs to get a couple of customization parameters of the developer kit from the Developer kit creator.
  3. The attachment maker opens the Developer kit Configuration panel in Avastar, specifies the file location and the custom parameters.
  4. Finally the attachment maker creates a new Developer kit Prefix. The new Prefix will show up in the Developer kit listing, which i have shown on the previous image.

Click to Zoom In

Typical Workflow with Developer kits

When the attachment maker 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 maker will get added to the scene is fully controlled by the developer kit creator. Here is an example:

The Attachment without Rig

The Developer kit is added to the scene without removing anything

Step 1: The Basic adjustment

The very first thing the attachment maker will do is creating an attachment and then 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 maker will Bind the Attachment to the Developer kit Rig. With Avastar this is a matter of a few clicks, where the attachment maker 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.

Important rule of thumb: Attachments must either use only the bones from the Developerkit, or they must use only bones which are not used by the Developerkit. Otherwise you might end up with attachment mismatches or even with distortions on your avatar or on your attachment.

Step 3: The weighting Workflow

Once the model is adjusted and bound to the Armature, the attachment maker 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 maker can select the Skin&Weight Workflow. This workflow prepares the Blender scene such that the attachment maker can select the bones, add/remove weights from the attachment where 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 maker might also want to go into posing and animation.

In this case the attachment maker 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 maker can also change the display style from Shape to Octahedral or Stick.

Step 5: Shape Sliders

Avastar provides a full implementation of the Secondlife Avatar Shape Slider system. The Shape sliders are all located in the Avatar Shape Panel and can be used at any time during a user session for checking if the variations of the Shape 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 to SL(using the SL Importer) then you want to:
    • enable with weights
    • enable or disable with joint offsets depending on the bones you use, see below:

How to set the with joint offsets option

  • If you create an attachment that only uses bones from the Developerkit, then you must disable with joint offsets.
  • If you create an attachment that uses only bones which are not already used by the Developer kit, then you need to enable with joint offsets.

Note: As mentioned before, please avoid to create attachments which are weighted to a mix of bones from the Developerkit and bones which are not used by the Developerkit. Otherwise the resulting meshes might suffer from distortions when worn in SL.

 

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 as text file to the developer kit documentation as described below. ThebDeveloperkit Manager can create such a configuration file for you if you (the developerkit Creator) have configured and tested an entry for your kit in the Developerkit manager.

The Developerkit configuration file

Below you see an example configuration file generated by Avastar. Your customers can later import this text file to their own Developerkit manager. All they have to do additionally is to enter the location where they placed your developerkit on their local file system:

Important: The syntax of the very first line is most important and must follow this structure:

'[' brand '-' name ']'
[Dinkies - v1.9 rev4]
filename = dinkie_sphere_eyes.dae
brand = Dinkies
name = v1.9 rev4
scale = 1.0
up_axis = Z
source.rigtype = SL(1)
source.jointtype = PIVOT(2)
target.rigtype = EXTENDED(3)
target.jointtype = PIVOT(2)
target.skeletontype = AVATAR(4)
use_sl_head = False
use_male_shape = False
use_male_skeleton = False
transfer_joints = True
use_bind_pose = False(5)
use_sl_bone_ends = True
use_sl_bone_rolls = True

Remarks

The remarks below are meant for better understanding the entries in the file above. The Avastar documentation contains a very detailed document about how to create your own developer kit

(1) Can be “SL” or “AVASTAR”

(2) Can be “POS” or “PIVOT”, we recommend you always work with the PIVOT Rig

(3) Can be “BASIC”, “EXTENDED” or “REFERENCE”

(4) Can be “AVASTAR” or “ANIMESH”

(5) If the developer kit restpose 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.

Note: Of course you can also create this file manually with a simple text editor. We recommend though you use the exact same syntax as shown