How to make IMVU rooms using Blender 3D

 

The following guide instructs on the general process of making a room for IMVU using Blender 2.45 (with Python 2.5.x optionally installed), which should be regarded as the minimum requirement for making IMVU content of any description. For more details see "Getting Started with Blender". Note that a basic understanding of Blender is necessary to properly understand and use the following guide as the it does not explain how to use Blender to any great depth or detail.

• IMVU room example file download

Be aware that making content for IMVU isn't for the faint of heart. Be prepared to spend a lot of time reading, researching and trying to understand the processes being explained; it's not generally possible to make custom rooms for IMVU in a few minutes of trying being new to 3D and IMVU creating.

Making IMVU rooms with Blender ^

Making an IMVU room using Blender involves the same basic principles required for any other type of product. There are differences of course, so although a 'room' and a 'pet' are not outwardly the same, they do however have similar internal structures, essentially that of a single 'mesh' and 'skeleton'.

The Mesh (.MESH)

Meshes are the actual objects people see in an IMVU chat. It's simply a collection of coordinates, points in space shaped to represent an object three dimensionally regardless as to whether that's a room, chair or necklace. . Once the object is made, it needs at least one "Material" (which contains a "Texture") and to be "UVW unwrapped" - to which an "Image" is assigned. It then needs to be "Parented" to the rooms 'skeleton' (an "Armature" object) and a "Vertex Group" assigned - this lets IMVU know how the mesh is supposed to behave relative to more complex products; each area of a mesh can be 'paired' (linked) to a specific element of the skeleton and controlled independently of other sub componants

Design Note: meshes should ideally be appended with "*.MESH" to help distinguish the data-type within a given project. A project called "boxroom" for example, with a mesh called "box", would be appended like so, "box.MESH". This is not critical to functionality of the room in IMVU but it can help distinguished different objects and data-types with similar names from each other.

To parent the mesh, RMB select it then "Shift+RMB" click the 'Armature' object (the rooms 'skeleton'). Using "Ctrl+P" to access the "Parent" options, select "Parent to Armature", then "Don't Create Groups". This will 'pair' the Mesh to the Armature. Once done, select the mesh then in Edit mode, create the new "Vertex Group" in the "Links and Materials" panel under "Editing" properties ("F9").

Design Note: it possible to create the appropriate vertex groups before parenting, the order in which groups and parenting is done is not critical to proper functionality

The Skeleton (.RIG)

The 'skeleton' referred to above is in fact an "Armature" Object in Blender. There are five main components to a room; 1) the 'root' of the room itself, 2) a set of 'furniture' nodes, 3) a set of 'seat' nodes, 4) lighting, and 5) a camera(s).

When using Blender all these particular elements are actually individual "Bones" within an "Armature" (more on this below), set up so they have a very specific hierarchy - although the order of display can differ, on export the relationship between the elements determines the structure of the resulting file. The main difference between a room skeleton and that of a furniture item then, is largely one of complexity, generally speaking rooms perform more functions so require a certain degrees of complexity to accommodate these additional features.

Design note : an Armatures name should ideally be appended "*.RIG" to similarly help distinguish it from other types of object as per the above for meshes.

Furniture

There are two types of room in IMVU, 1) 'locked', and 2) 'furniture'. 'Locked' room are relatively rare because they proved a limited functionality in IMVU. 'Furniture' rooms on the other hand are the main-stay because they are much more flexible for the end user to use. Because of this each type of room requires a different set-up for their respective Armatures. As with 'seating' discussed above, because of the relative complexity and importance 'furniture' (or not) is to a room generally, this aspect development is discussed below in detail.

Seating

Avatars interact with the scene and each other using a set of bones collectively referred to as a "seat node" or "pose spot". By default there are two types of 'node', 1) a "standing" and 2) a "sitting". As the names suggest they provide 'standing' and 'sitting' (seated) positions for the avatars in IMVU. Because of their relative importance 'seats' are discussed in more detail below.

Lighting

As briefly mentioned above, lights are one of the main sub-component of a rooms Armature. They are not actual 'lights' (or 'Lamp') entities in Blender but rather bones specifically identified for the purpose of illuminating a room and its contents in IMVU - although 'Lamps' can be placed to provide a general feel to a rooms eventual illumination in IMVU, they would need to be 'converted' (exchanged) to bones. They are generally 'global' in nature in that they tend to illuminate a scene in a relatively uniform manner - only one or two are ever needed.

Design Note: IMVU does support three different types of 'light', however, "Omni" (omni directional) are the most common due to their ease of use. When 'converting' a Lamp into a bone, either place a new Armature object into the scene and then join that to the main room armature, or 'extrude' a new bone from another. Armatures or bones used for lights can be added to the 3DView in front, side or top view.

Camera

As with lights discussed above, cameras are another sub-component of a room Armature, and similarly rather than being an actual camera entity, they are instead a pair of bones which provide the necessary 'source' and 'target' mechanism IMVU needs as a scenes focal point (the point around which the scene is viewed an manipulated). Again this means in practice, although 'Camera' objects can be used for positional purposes in Blender, they will need to be replaced with specifically named bones.

Design Note: replace Blender camera objects with a bones naming the camera "camera.01.01.root" and its target (what it points at) "camera.01.01.root.Target". Camera armature/bones should be added in side view.

IMPORTANT

It's important to reiterate here that although a room can be developed in Blender using Blenders own camera, light and other entities, they will always need to be 'converted' to bones before use in IMVU; each must be swapped out and replaced with a bone.

Structure of an Armature ^

A room Armature then, is an 'Object' containing a number of individual bones, with each bone performing a particular function based on their assigned roles (a 'light', 'camera' etc.). Each 'role' is then determined by the bone name and their position in an overall "hierarchy", an internal "parent » child" structural relationship between the bones. This is important for a number of reasons, namely relative to order in which bones load when opening a room in-Client - if a 'furniture' bone is loaded before the main 'root' bone it can cause problems because IMVU assumes the first bone to load is what everything else it linked to. To prevent this bones need to be linked together to form a proper relationship.

A default hierarchy (assuming a standard no-frills room) looks similar to the following (colour-coded for clarity);

• skeleton.Room

• node.Room

  • Omni1[*]

• camera.01.01.root[*]

• camera.01.01.root.Target[*]

• furniture.Floor.01

• ... +floor

• furniture.Wall.01

• ... +wall

• furniture.Ceiling.01

• ... +ceiling

• seat01.Standing

• Pitcher01.Standing

• Catcher01.Standing

• Handle01

• seat02.Sitting

• Pitcher02.Sitting

• Catcher02.Sitting

• Handle02

Design Note: The bare minimum requirement for a working room is "skeleton.Room" (previously called "skeleton.Scene") and "node.Room" (previously called "node.Scene"). For a furniture room a furniture node is required as the presence of those are what the client uses to distinguish 'locked' and 'open' rooms. If no seat or camera nodes are present the client defaults to adding them approximate to the position of the origin of the armature. Bones marked "[*]" in the above are the replacements for 'Lamp' and 'Camera' items (as discussed above) - Lamp Objects are called "Omni" and Camera Entities "camera";

• "Omni[n]" (where [n] is a number, e.g.."Omni1")

• "camera.01.01.root"

• "camera.01.01.root.Target"

Obviously depending on how a room was set up, if separate Armature objects are used then will need to be merged together to form a single object and their respective names and 'parenting' checked.

IMPORTANT

Bone names are cSse seNsItiVE; "Seat01" is not the same a "seat01"

skeleton.Room root bone ^

The 'master', 'root' or 'top' bone of an Armatures hierarchy is "skeleton.Room" (previously "skeleton.Scene"). Everything connects to this single bone. It's "X", "Y" and "Z" orientation is very important so when the Armature is initially being added to the 3DView make sure this is done in "Top" Orthogonal view ("numPad7") to ensure these values as "0.000" (this can be checked pressing "N" to open "Transform Properties"), "Z" should always point 'up' - the bone itself can then be rotated onto its side in Edit mode.

Design Note: Armatures are added to a scene in 'EDIT' mode already selected for manipulation. To cancel this and exit Edit mode, RMB then press "Tab". Note also that due to the scale used by IMVU, the Armature will initially be tiny - avoid scaling the Armature itself. Instead, after initial placement, press "G" and drag the bone up (hold "Ctrl" to snap) to increase it's size.

Once the initial Armature it placed and the bone correctly size, adding other bones is then simple a question of; RMB selecting the original and using "Shift+D" to "Duplicate" it; RMB selecting the 'Tail' node (smaller of the two spheres) and using "E" to "Extrude" a new bone. Alternatively, another Armature can used and positioned independently of the original Armature but the latter will eventually need to be joined to the former.

Design Note: unlike extruding, duplication does not create an automatic 'link' between parent (original) and child (duplicate) bones. This will have to be done manually in the latter's case. Note also that bone names are appended with an incremental numerical value "*.001", "*.002", *.003" and so on. These will need to be edited and changed manually.

Room Seating ^

The position avatars stand, sit or otherwise interact with the room is done via a series of named bones parented to the main 'root' bone of the room. Each bone in the set performs a particular function; "Catcher" and "Pitcher" for instance are placement points for avatars when interacting - you on the "Catcher", them on the "Pitcher"; "*.Sitting" and "*.Standing" indicate the 'type' of position the avatar uses, the defaults being 'standing' and 'sitting'; "Handle" acts as the on-screen prompt indicating where the seat node is on screen, when click the avatar will jump to that location.

IMPORTANT

The distance between the "Catcher" and "Pitcher" bones MUST NOT be altered.

Seat Numbering

IMVU room can hold a number of concurrent users, currently 10. To facilitate this a corresponding number of seat nodes need to built into the room. The minimum number of seats is six. For IMVU to work out how many seats there are the associated bones are number sequentially irrespective as to the type of seat being used; having two standing and one sitting seat would be numbered similar to the following;

• seat01.Sitting
  Handle01
  Pitcher01.Sitting
  Catcher01.Sitting

• seat02.Standing
  Handle02
  Pitcher02.Standing
  Catcher02.Standing

• seat03.Sitting
  Handle03
  Pitcher03.Sitting
  Catcher03.Sitting

Design Note: there is no "00" seat, number starts at "01" NOT "00". So "01" to "09, "10" to "999". For example, the tenth seat would be "seat10.[seat-type]", the one hundredth would be "seat100.[seat-type]" - note that it's not necessary to have more than a dozen or so seats in a room by default as they are often added to the furniture users place in rooms.

Seat Parenting

As briefly mentioned above, the bones comprising a seat 'node' need to be properly parented to once the Armature object is joined to room Armature. It's important to note that this needs to be done correctly to avoid problems when a room loads, IMVU determines the 'root' bone as being the first loading into the client, and not its name, if a seat node loads first everything else then treats that as the root and the room breaks. To avoid this problem make sure that each bone within a seating node is parented to "skeleton.Room";

• skeleton.Room

  • seat01.Sitting

  • seat02.Standing

  • seat03.Sitting

  • etc..

Design Note: again pay attention to bone names as they are CaSe-sEnitIVe.

Seat Orientation

To make rooms and avatar interaction more interesting it's possible rotate and position seat nodes in any direction or general location; turned around a particular axis, flipped upside-down, pitched, rolled, etc.. To avoid problems this type of manipulation (using the usual manipulation tools/options) should be done to the seat Armature and NOT individual bones - it's important to avoid tampering with seat nodes as the distances used are not arbitrary, they serve a very specific purpose which tend to break certain aspects of avatar/room interaction if they are changed.

WARNING : when using the example room DO NOT TAMPER with 'seating' except to position, rotate and join them to the main room Armature. Once joined, only edit individual bone names and/or change the 'parent>child' relationship as directed.

Furniture ^

Furniture is what makes a room a 'furniture' room. Essentially just a series of 'nodes' onto which items can be placed - 'chairs', 'beds', 'cars', 'boats' and so on. There are three types depending on their general location; 'floor', 'wall' and 'ceiling' - "furniture.Floor", "furniture.Wall" and "furniture.Ceiling" - placed into a scene whilst in "Top" Ortho ("numPad7") to ensure correct orientation relative to the room Armature. Furniture nodes are number sequentially per node type, for example having 200 floor, 20 wall and 10 ceiling nodes would be numbered/named;

• furniture.Floor.01 > 201

• furniture.Wall.01 > 21

• furniture.Ceiling.01 > 11

Design Note: as with seating, numbering for all types of furniture node starts at "01", there is no "00". Again, bone names are cASe SenSitIVE.

Furniture Parenting

To ensure proper room functioning, by default all types of furniture node are parented to the rooms root bone, "skeleton.Room". For example;

• skeleton.Room

  • furniture.Floor.01

  • furniture.Wall.01

  • furniture.Ceiling.01

Design Note: the 'order' in which bones are joined to the root bone and/or listed in the OOPS editor is as important as ensuring a proper hierarchical relationship - a room will break if a furniture nodes loads into IMVU first instead of the root bone.

Furniture Orientation

Aside from making sure furniture bones are correctly parented to "skeleton.Room" it's also important to make sure they point in the right direction to ensure items load in to and are orientated correctly relative to the room. IMVU uses the "Z" axis to indicate the 'inward' direction of a node, which means;

• bones used for 'floor' nodes typically lie flat with the 'Z' axis pointing up into the room; the bone itself typically lies flat along the floor surface and itself points at the top of the 3D window in Blender.

• bones used for 'wall' nodes typically stand upright with the 'Z' axis pointing into the room.

• bones used for 'ceiling' nodes should lie flat and be placed in a similar way to Wall bones when near the edges of the ceiling and similar to floor ones when on the inner surfaces of the ceiling. Ceiling bones also need a "Roll" value of "180º" to invert the axis (else they point 'up').

Design Note: when setting the “Roll” value to “180”, may automatically 'invert' that to "-180.000" (negative 180) because of the way it works. To prevent this enter a value of "179.999".

In addition when placing furniture nodes it's best to keep them all pointing in the same direction, generally letting the user control final position and rotation for items added to a room in Client rather than rotation bones in Blender.

Exporting a mesh and armature to IMVU ^

Generally speaking exporting content from Blender to IMVU tends to use the same basic process of preparation regardless, the only real difference being one associated with functionality in-Client. This means export will generally need to include a Mesh parented to an Armature with an Action assigned.

Preparing for IMVU Export

Before exporting make sure the following checklist is gone through (not necessarily in order);

• Armature

  • "Apply Scale & Rotation" (Ctrl+A) is applied to the Armature (if the Armature was added to the scene correctly this shouldn't need to be done, it actually need to be avoided because it can cause orientation problems that are difficult to fix).

  • Individual Armatures used during build are 'joined' (Shift+J) into a single unit.

  • Armature bones are correctly parented to "skeleton.Room" (all bones parented to skeleton.Room with Omni parented to "node.Room", which in turn is then parented to "skeleton.Room").

  • Bones are correctly named and numbered per their type and role in a room.

  • Bones are orientated correctly relative to their function and the room itself.

  • The position of skeleton.Room is relative to Blenders 0,0,0 grid centre.

• Mesh

  • "Apply Scale & Rotation" applied to mesh.

  • Mesh parented to Armature.

  • Mesh has a vertex group named "skeleton.Room" (assuming a standard non-animated room).

  • Mesh is UVW mapped.

  • Mesh has a material (materials) applied and is textured.

  • Mesh should be "Triangulated" to avoid problems during export and in IMVU (select all ['A'] then "Ctrl+T").

Add an Action

For a standard room (non-animated) this is not needed by IMVU, but it is needed for the export process to produce the necessary files. Simply select the room Armature then in "Pose" mode ("Ctrl+Tab" - Armature should display 'blue') Select All and press "I" to "Insert" a keyframe; from the menu pop-up that appears select "LocRot" ("Location" and "Rotation") from the list. This creates an "Action" (with a default name "Action") in which all the selected bones have a single keyframe associated with them in the time-line (exit pose mode once done, "Ctrl+Tab").

Design Note: it may be necessary to have the Action Editor open to ensure the necessary short sequence is keyed to the first frame in the timeline - with the editor open, LMB+drag the green timeline widget if not, to the first frame then press "I" to key the pose.

Exporting room Animation for IMVU

The 'Action' discussed above is an animation, however it only contains the single frame sufficient for a standard room. Where an actual animated sequence is present the room Armature and Action need a slightly different set up. Everything discussed so far assumes a non-animated room so the room Armatures bones are parented in a particular way to produce a specific hierarchy, however this can be over-ridden to certain extent by parenting animated bones together to form a sub-grouping within the Armature which is then parented to skeleton.Room. A moving wall with a light source attached (a wall torch for example) might result in the following hierarchy;

• skeleton.Room

  • wallControl

    • furniture.Floor.13

    • furniture.Floor.14

    • Omni2

In the above "wallControl" is the 'control' and local parent for the two furniture nodes and light, typically when the control moves, so too do the connected bones (because of the parent>child relationship). When movement is keyed across a number of frames in the timeline this produces and animation of a particular duration. The checklist for animated areas of a room are;

• Bone or bones to be animated ideally need separate 'Action' animations (only the bones that are animated should be included in a sequence, this saves on file size).

• Animated bones may still need to be part of the main rooms Armature (if animation is part of the actual scene/room).

• Any parts of the main room mesh that need to move need to be 'connected' to the animated bone/s by the use of an appropriately named 'vertex group' (vertex group names for animated mesh sections should correspond to the bone controlling their movement, in the above example that would be "wallControl" and not "skeleton.Room").

• Animation export should result in the generation of a separate *.xaf file per sequence.

Design Note: when working with animations it's a good idea to get into the habit of version saving so sequences can be checked for problems without over-writing or loosing data.

Exporting to IMVU

Once the above have been checked and applied where necessary, to export the scenes contents to IMVU, first select the Mesh, then "Shift+RMB" click the Armature. From the "File" menu select "Export > CAL3D" (or whatever name is used to list the script in the export menu), choose a location to save the file in the "Browser" that appears then finally click "Cal3D Export"; a pop-up will appear, leave everything 'as is' and click "Export/OK". A few seconds may pass and once completed Blender will return to the previous screen indicating export is complete with the various XML files having been generated and saved to the projects development folder (the location chosen in the "Browser").

Design Note: the above assumes Blender 2.45, using the included and default Cal3D export script; depending on the Blender and export script version actually used, the details discussed above may differ slightly. However, the general process should be exactly the same - select the mesh, Armature, then export. Choose a location, set any properties, and 'OK' to finish.

Assembling the room in Create Mode ^

After exporting a series of 'XML' files will have been generated. For a standard non-animated room, the "*.xmf", "*.xsf" and "*.xrf" - 'mesh', 'skeleton' and 'material' files - are to be used. First log into IMVU and click "Create" to access Create Mode. On the page that opens click "Derive New Product" and select "Rooms & Furniture" then "Room" to load the default derivation product, or type product number "512" ("Basic Beach Head" scene) into the input field.

Assembling the room is simply a matter of replacing the corresponding components of product 512 from which derivation is being made. So; click "meshes" then "+ Add .XMF" to add the *.xmf mesh file previously export; "config" then "+ Add .XSF" to add the *.xsf skeleton file; then back on "meshes" to add the *.xrf material files clicking "+ Add .XRF" per each material exported.

As the room has a couple of custom avatar seat nodes it's best to test these before publishing the room by clicking "debug" then the "Add Actor" tab, and finally "+ Add an Actor" button to load in a secondary avatar. With the additional character in the room, test the seat nodes by trying different actions - the avatars should shake hands face-to-face and right-side-up. If there are not issues, upload and publish.

Room feature support ^

The following 'caveats' depend greatly on the version of Cal3D export script being used; whilst technically all the follow can be done in Blender (they are features and functions support natively by Blender), support at export varies so will need to be weighed in relation to the final look desired, and if the product is to be made a derivable, the ease with which others are going to be able to derive the items - using Blender 2.45 for example means Creators need to flip textures top-to-bottom before assembling product in Create Mode.

Vertex Colours/Mesh Painting ^

Painting a mesh with "Vertex Colours" for use in IMVU is not supported by the Blender 2.45 or 2.49 Cal3D scripts; if a mesh is painted colouring will not be exported. This mean 'shading' and 'shadows' will need to be painted directly into the texture image (which may require a rethink about the rooms design to facilitate the difference in technique this requires).

Design Note: a number of in development scripts are available for Blender 2.6x series with varying support for vertex colouring. Check the Tools page for details.

Inverted/upside-down Textures ^

As noted above, rooms exported from Blender 2.45 require textures to the flipped top-to-bottom so they have the correct orientation when loaded into Create Mode (and used in IMVU chat). This is a problem with the export script itself and not Blender or IMVU. To correct the problem simply invert the image in a photo-editing application so they are upside-down before assemblage in Create Mode. This problem does not occur when using Blender 2.49 or above and their associated scripts.

Design Note: rooms should be constructed in the normal manner.

No lighting ^

As discussed above, lights in IMVU are not Blender 'Lamp' objects, but Armature bones. For lights to work correctly in IMVU bones set up as lights need a particular set of properties, as these cannot be added and exported from Blender they need to be written to the file manually by editing the *.xsf in NotePad or similar text editor - omitting to do this results in a black room (no lighting).

Design Note: currently the above only applies to the use of Blender 2.45, 2/49 and their associated scripts.

Directional Light

There are two types of lighting available in IMVU; 1) 'direct' and 2) 'ambient' light. Directional lighting is 'source' based, i.e. it has a point of origin - usually a bone marked "Omni[n]". Because this type of light has a source and direction it illuminates the room similarly so that objects within it appear to be lit from a particular direction/orientation. As mentioned above, whilst the bone is placed as part of the room Armature, it contains no data. To add this open the "*.xsf" skeleton file with NotePad or similar text editor and find (if not found, search the document for "Omni1");

<BONE ID="2" NAME="Omni1" NUMCHILD="0">

And then append the following behind the "0" but before the ">" closing bracket.;

LIGHTTYPE="1" LIGHTCOLOR="0.881726 0.869392 0.858118"

The result should be going from this;

<BONE ID="2" NAME="Omni1" NUMCHILD="0">

To this;

<BONE ID="2" NAME="Omni1" NUMCHILD="0" LIGHTTYPE="1" LIGHTCOLOR="0.881726 0.869392 0.858118">

Save the file and reload the *.xsf into the Create Mode to see the difference it makes to the room.

Ambient Light

The second type of lighting is "Ambient" light, this is a flat 'background' light which illuminates all objects with the same level of brightness. Unlike Directional light is does not have a direction so objects are evenly lit and absent any shading. To add this to a file open the "*.xsf" skeletal file into NotePad or similar text editor and find;

<SKELETON NUMBONES="[value]">

Append the following after "[value]" but before the closing ">";

SCENEAMBIENTCOLOR="0.525176 0.555059 0.545235"

The result should be going from this;

<SKELETON NUMBONES="92">

To this;

<SKELETON NUMBONES="92" SCENEAMBIENTCOLOR="0.525176 0.555059 0.545235">

Save the file and reload the *.xsf into Create Mode to see the difference it makes to the room.

Light Colour

IMVU lighting is based on a set of three numerical values, each representing one of "Red", "Green" and "Blue" colour channels. The colour associated with a room is set by changing the values per each channel between "0.000000", no-colour, to "1.000000", full colour. Individually each channel is calculated based on hue, saturation and intensity, setting the red channel to "0.000000" or "1.000000" equates to either no-colour (black), or full colour (100% red). In other words, channel colours by themselves are not 'black/white' representations but based on the amount of colour they display - to achieve 'white' light or similar, the channels all need to use the same value, "0.500000" for example would produce an 'average' untinted light. Generally speaking then, room lighting, both directional and ambient, can be tinted by changing the values attributed to each "R", "G" and "B" channel.