A Cal3d viewer/editor (from now called a Entity Composer) can be seen as both a standalone tool and as a steppingstone for the beforementioned character generator. Possibly based on the existing Cal3d miniviewer sourcecode, the Entity Composer requires the addition of a GUI and extra functionality. The extra functionalities could be added stepwise:

1. Start with normal viewer but add LOAD, SAVE and SAVE AS .cal files through menu browsing. Also add a refresh-button to reload all files linked within the .cal file. (Much) Later add a PUBLISH option to upload the new character to a media server
2. Add the option to start new .cal file and add / edit names and locations of Cal3d files. Also add option to edit character scale and browse/add texture/material overwrite data (as done in sear). Bounding box size readout would be useful in order to set the scale correctly.
3. Add the option to define animations per action by mixing and overlaying multiple animations. Note that Sear does not have this functionality yet.
4. Add the option to attach rigid meshes (.3ds) to the character or to define rigid mesh attachment points and orientations. This would involve loading a .3ds mesh/dummy mesh, transforming the mesh to the correct position relative to the character, and selecting (by using the mouse) the bone to which the rigid mesh will be attached. Note that Sear does not support attached rigid meshes yet.
5. In some ways linked to the previous entry, a mode for viewing and editing rigid meshes (.3ds/.obj) could also be rather useful. Sear loads rigid meshes from a script file by object name. the script defines mesh and redefines the textures used by the mesh. A similar and coordinated approach would be useful to follow.
6. Finally, an option to, based on a script, over time load and view different characters and meshes would be useful for showing our stuff at public occasions. This feature might be built in on an early stage.

• Character. Subfolders: all. Available menu items: skeleton name (type in, view and browse), scaling (type in) & boundigboxsize (view only).
• Actions. Subfolders: animations. Available menu items: Actions (Add, delete, rename) (all available action names on popup list).
• Animation. Subfolders: none. Per action one animation subfolder animation. If one animation selection is selected, then available menu items: animation mixer. If 2 or more animations are selected (by holding in ctrl during selection) then available menu items: action mixer like in callydemo.
• Model. Subfolders: mesh Available menu items: meshes (Add, delete, rename).
• Mesh. Subfolders: none Available menu items: mesh name (browse/type in).
• Materials. Subfolders: single material Available menu items: materials (Add, delete, rename and move up/down in list).
• single materials. Subfolders: none Available menu items: texture(s) (add(browse/type in)/delete/sort), basic material properties.

Entity Media Description

The Entity Media Description is the file format in which the details of a composed entity are stored. It may contain the following data (currently required items are in bold):

• skeleton
  • filename
  • path
• model scale
• entity position and orientation
• animations
  • name
  • filename
  • path
  • default mixmode to use
  • a mix weight maybe?
• poses(single frame animations?)
  • name
  • filename
  • path
• animation blends
  • name
  • animations to mix
    • mixmode
    • percentage
• meshes
  • name
  • filename
  • path
  • mesh scale, position and orientation
  • should also contain submeshes?
  • on/off property for meshes
• rigid meshes (.3ds and .obj for example)
  • name
  • filename
  • path
  • relative attatchment point
  • relative orientation
  • relative scale
  • attatchment to a bone
• materials
  • name
  • basic material parameters like shinyness and specularity
  • textures it uses
    • name
    • multitexturing mode - diffuse, bump, reflection maps etc..
      maybe put other operations here too, like multiply, overlay etc.
• material thread/set specification for each material e.g. thread=chainmail set=torso
• textures
  • name
  • filename
  • path
  • alpha map
  • filename
  • path
  • texture blends
    • name
    • textures to mix
      • mixmode
      • percentage
  • procedural textures
    • name
    • procedure type (fill/gradient, noise etc)
    • parameters (colors etc.)
  • sounds
    • name
    • filename
    • path
  • sound blends
    • name
    • sounds to mix
      • mixmode
      • percentage
  • procedural sounds
    • name
    • procedure type
    • parameters
  • should also support the current uclient fromat

  Some comments by zzorn

  Hierarchial organization

  A document should have a root node, and it could have child nodes that could have child nodes, etc. A node can define properties in relation to the parent node, e.g. position, angle, etc. Motivation: It's a simple and flexible way to organize complex objects, and allows extension and reuse of objects as part of other objects.

  Particle system

  The particles are media object nodes themselves (they can be as simple as billboard sprites, or as complex as other particle systems, etc). A particle system has various properties that the author may tweak, e.g. spawn position, spawn radius, initial velocity, forces affecting the particles, etc.. Some existing particle system API or file format could be reviewed for ideas of what is needed. Initially just a few simple parameters could be provided.

  Properties

  Properties like the position of a node, particle system properties, mesh scale, etc. etc. can be animated over time or depending on a property of the parent node (e.g. the life stage of a particle system particle). The author can create custom properties, that child nodes can use, and that can be exposed to the parent level. Custom properties of the root node may be exposed to the system using the media object. E.g. the game rules could set a "WoundAmount" property of a media object depending on the health of a creature.

  Triggers

  Triggers can be created to do things like start an animation, play a sound, or change a property when some property crosses a threshold. Triggers could also be triggered directly from another trigger, or exposed to the system using the media object. So the game rules could call triggers like "Explode", "ScratchBeard", "StartWalkingAnimation", etc. Doing things like playing a sound, (re)starting and stopping a particle system, starting an animation, etc. could use the same basic mechanism as triggers, so they would be syntactically (and logically) similar. This makes it easier to extend the format with new types of objects, just define the properties and triggers the object has.

  Trigger is perhaps not the best term, rather we could have Methods that do something (possibly taking parameters), and triggers would be separate objects that could be defined to call a method with some parameter when some condition becomes true.

  Notice how this resembles a simple programming language - but I believe a simple language close to the domain of media animation is motivated, and could prove to be a powerful tool in creating good dynamic media for entities, and coordinating and binding together the different types of media used. It would also offer a flexible way to extend the format with new types of nodes as needed.

  Position data for parts of a model

  If we could somehow get position data of null objects in models (or whatever they are called), we could have child nodes to a character model node for example that have positions at the head, hands, and feet.. Then we could insert a tool under a hand node, or add a crown of flames particle system under the head node...

  In some 3D editors such as Maya artists can add custom attributes to null objects.. It would be nice if we could export or access these attributes also. (We could have a node type that could be added as a child to meshes, and given a name of a null object (e.g. "Head", "Left Hand", etc), and that would then contain the properties the artist specified for a null object with that name in the model). This is not necessary though, as long as we at least can get position and direction vector data for null objects in a mesh (using a similar strategy of creating a NullObjectNode with the same name as a null object in the model).

  • Home
  • -
  • About
  • -
  • Introduction
  • -
  • FAQ
  • -
  • Team
  • -
  • Newbie Guide
  • -
  • Getting Started

  
  

  • Editing Guide
  • -
  • Edit
  • -
  • Manage
  • -
  • New Page
  • -
  • Changes
  • -
  • Map
  • -
  • Password
  • -
  • Deprecation

  
  

The content on this site is distributed under the terms of the
GNU Free Documentation License unless expressly stated otherwise.
Copyright © 1998-2008 of the authors of each page.