Universal Modular Entity Construction System for UDK

[TechLord]

PS:. I'm seeking advice of an experienced 3D Artist/Animators on devising the Standards. I've been reviewing Blender Tuts with intention of doing some modeling and animation myself. However, my plate is full developing: ArcadeKomodo and ProjectFujita. I've been gathering references and adding them to list below. I'd appreciate any input towards setting up the UMECHS Standard.

References:

UDK 3D Art Pipelines Naming Conventions
Turbosquid Checkmate Specification
Blender Rigging: Naming_the_bones, Blender Noob to Pro

[LordNelson7]

This is really cool!

[TechLord]

This is really cool!

Thanks LordNelson7. I wish the concept would attract more Artist/Animators. Keltar can see the potential for a Modular Parts System.

[SHOT]http://media.moddb.com/images/downloads/1/57/56577/Modular_Pawns.jpg[/SHOT]
Inspirational!

[Kelt'ar]

Thanks, techlord

[TechLord]

I've decided its time to dive deep into 3D Character modeling, rigging, and animation, devising the UMECHS Standards along the way. I elected Blender as my tool of choice. Its Free, Powerful, Supported, and there is a plethora of tutorials available on the net.

[SHOT]https://arcadekomodo.com/home/wp-content/uploads/2013/08/Blender_Riggin.png[/SHOT]
My First Character Model Rig.

Tutorial References:

UDK/Blender Tutorial: Custom Bots (Part1) [english]

[TechLord]

Universal Modular Entity Construction Hierarchical Sets (UMECHS)
Specification 1.0 Draft In Progress
F.L.Taylor aka TechLord on UDK Forums
September 2013

Abstract

UMECHS is a standardized assembly system for constructing a variety of 3D entities with modular interchangeable Part sets. Parts can be in the form of Skeletal Mesh, Animation Sequence, Texture, or Material Asset. The System is specifically designed to support entity assembly for real-time in-game customization and pre-fabrication; and entity dis-assembly for destruction/dismemberment.

Terminology

Entity

UMECHS defines an Entity as any 3D Interactive or Animated Person, Place, or Thing in the Game World, that can be comprised of 2 or more interconnected parts. We categorize Entity Skeletal Meshes to simplify organization for construction and assembly. Each Skeletal Mesh Category is summarized in a Entity Specification Sheet that outlines its Specifications for Skeletal Hierarchy, Base-body Mesh, Controllers, Textures, Physics Assets and contains a Reference Asset Pack (ZIP format). Entity Spec Sheets are cataloged in the UMECHS Repository Database. With the Entity Spec Sheet in hand, Artist can immediately start creating works-of-Art that are readily available for use by Developers using the UMECHS System.

Hierarchy Sets

UMECHS employs many types of Hierarchies to construct, organize, and manage Modular Entities. Skeletal Meshes themselves contain a Hierarchy of Bones. A Skeletal Mesh Taxonomy is a hierarchy of Skeletal Meshes Categories. Entity Specification Sheets are arrange in a Hierarchical Catalog with references to Parent and Derivative Entity Spec Sheets. The Entity Construction Hierarchy in itself is a Hierarchy of 3D Entity Authoring Stages:

1. Skeleton Hierarchies (Structure)
2. Base-body Mesh Layers (Shape)
3. Modular Part & Attachment Mesh (Shape)
4. Skin Themes and Style Texture/Materials/Shaders Layers (Appearance)
5. Animation
6. Physics Assets

Hierarchies are expressed within the Specification using JavaScript Object Notation (JSON). JSON is versatile, popular, and natively supported by UDK Unrealscript and 3rd Party 3D Authoring Applications. JSON is suitable for use as a raw 3D format, 3D Animation Format(ie: BVH), or General Purpose Hierarchical Data format.

Skeletal Hierarchy

UMECHS Entity Construction Hierarchy is based on the UDK FBX Skeletal Mesh Pipeline. # UMECHS Entities are exclusively Skeletal Meshes. A Skeletal Mesh is a type 3D Mesh bound to a hierarchical set of interconnected bones (Skeletal Hierarchy, Skeleton for short)used to pose and animate its geometry. A UMECHS Entity must contain a Skeleton with a minimum of one bone (Root). Not all Skeletal Hierarchies are animated, but serve as reference for inter-connecting other Skeletal Hierarchies and Parts Meshes. The analogy is using a Skeleton for the structural framework to assemble an entity, vehicles have a chassis, Buildings/Structures have a frame.

Skeletal Mesh Taxonomy

Skeletal Mesh are categorized by their Skeletal Hierarchy. There is no limit to the number of Skeletal Hierarchy derivatives that can be generated, resulting in many Categories. The Skeletal Mesh Taxonomy is a hierarchy of Skeleton Categories/Sub-Catogories.Below is a list of Prime Skeletal Mesh Categories that I've found to be common in Games. New Skeletal Hierarchy can be created through extension, composition, or from scratch.

Characters Face Body Uni-ped Bi-ped Multi-ped Weapons Firearm Melee Vehicles/Crafts Chassis Wheel Tracks Walkers Turret Architecture Door Wall Environmental Tree Furniture Table Chair Bed Lamp

Master Skeleton

A Master Skeleton is a Skeletal Hierarchy that contains all bones used in a Skeletal Mesh Taxonomy. This method of inheritance ensures that each derivative Skeletal Mesh works correctly during the authoring process. Derivative Skeletal Meshes within the Taxonomy will not use all the Master Skeleton bones; unused bones are removed accordingly.

UMECHS takes modularity into consideration when constructing the Master Skeleton. This support modular animation sequences and mesh parts. The Master Skeleton is dissected into modular skeletal segments at the locations which the mesh geometry is intended to be interchangeable.

Skeletal Hierarchies for Characters are arranged differently than that of Vehicles, however, both contain some form of the following:

• Root Pivot - The pivot point of the mesh in Unreal Engine determines the point around which any transformations (translation, rotation, scale) will be performed. This means it does not matter where the root of the skeleton is located within the scene. It will be as though it is at the origin (0,0,0) when exporting from a 3D modeling application.
• Spine/Nucleus - A Centralize Bone or Chain of Bones in which Bones/Limbs are connected.
• Limbs - Two or more inter-connected Bones, used to articulate a Mesh.
• Terminators.

Base-body Mesh

The Base-body Mesh is the Skeletal Mesh Geometry that defines an Entity's default Body Shape visible to the Player. The Base-body is typically presented as a single contiguous mesh in UDK at run-time. However, UMECHS assembles the Base-body from multiple-mesh Parts to provide modularity for generating two or more Base-body variations in: 1) the Authoring of Skeletal Meshes in 3rd Party Authoring Application such as Blender, 2) UnrealEd upon import of separate parts into a package *upk, 3) In-game Assembly as a Modular Part. Base-body Parts are stored and distributed in a FBX format. These Assets serve as Reference Models for Base-body Parts Derivatives that fit properly at the seams with minimum adjustment.

# The Base-body must conform to its Skeletal Hierarchy, making use of all bones. Rigging the Skeleton to the Base-body can influence authoring work flow in Third Party Authoring Application. For some, this may present a the chicken or the egg causality dilemma or which came first, the skeleton or the mesh?

Traditional 3D authoring work flow: Concept Drawing -> Modelling -> Rigging -> Export.

UMECHS authoring work flow (suggested): Concept Drawing: Style 1 & Style 2 -> Master Skeleton Selection -> Modelling:Style 1 & Style 2 -> Rigging -> Dissection -> Export

It is encouraged that Artists create a minimum of two interchangeable Styles of a particular Skeletal Mesh Base-body Part, Modular Part/Attachment, Texture.

Hot-Swaps and Accessories

A Hot-Swap is an independent skeletal mesh designed to be interchangeable with a specific Base-body Part and animated at run-time within the UDK Engine. UMECHS implementation of Hot-Swaps is based on the UDN Modular Pawn. # Hot-Swap Mesh Shape should be uniquely identifiable and conform to the Base-body specifications. In some cases the Hot-Swap may be a Entity with a completely different Skeletal Mesh Taxonomy.

Accessories are independent skeletal meshes attached to a Base-body Part, Hot-Swap, other Accessories via Socket. Accessories are designed to be separate from Base-body and may or may not be animated. Accessories are classified as either Global or Private. Global Accessories can be attached to any Base-body Part, Hot-Swap, other Accessories via Socket. Private Accessories can only be attached to a specified Base-body Part, Hot-Swap, Accessory.

Mesh Layers

Mesh Layering is the stacking of skeletal meshes atop one another, creating externally visible layers of modular construction/destruction. Mesh Layers can be used to visually break up the symmetry using different Accessories on left/right sides. Typically, The Base-body is a bare singular skeletal mesh, and accessories are used to enhance the detail and uniqueness of the Entity.

For example, an Artist authors a bare-skinned Humanoid Base-body, followed by Undergarments to attach atop of the Base-body, followed by Armor Plate Accessories to attach atop of the Undergarment. Undergarment and Armor Plates are Private Accessories, because they're shaped to contour of a particular Base-body shape. Each variation of Accessory available exponentially increases the greater uniqueness can be applied to Entities Base-body.

The above Mesh Layer example for Characters:{Skin:{Undergarment:{Armor}}} is common in Role Playing Games. Mesh Layers could be used for creating layers of Creature internal anatomy:{Bone:{Muscle:{Skin}}} Mesh Layers could be applied to other Skeletal Mesh Taxonomies: Architecture:{Frame:{DryWall:{Wallpaper}}}.

With emphasis on modularity, Artist are encouraged to use mesh layering to provide greater UMECHS Entity Customization options.

Naming Convention

Naming Conventions are the first step towards Syntactic interoperability. A Name Convention allows Artists to extend existing assets while reducing the effort needed to understand them. In many cases, Artist will use the same labels (ie: Skeletal Hierarchy), if extension is needed, there are simple rules to keep everyone aligned. As a programmer, I prefer self-describing verbose (non-abbreviated) labels. I will attempt to apply the methodology within the UMECHS Naming convention and maintain labeling cohesiveness between different assets and their file names.

My original thoughts on the naming convention were to devise a single generic labeling scheme to cover all the common Entity Categories in modern games. Working with Blender, I quickly discovered this is easier said, then done. Numerous possibilities makes this unpractical due to each bone requiring a unique name.

My solution, devise a generic labeling scheme for each common Skeletal Mesh Taxonomy. My rational here is that connecting parts should be labeled logically, for example in a humanoid skeletal hierarchy the shoulder_bone connects to the arm_bone_upper --> the arm_bone_upper connects to the arm_bone_lower, so on and so forth. Some Entity Categories are comprised of a Composite Skeletal Hierarchy in which two or more Skeletal Mesh Sub-categories are interconnected by bone, mesh, or socket.

Examples:
Humanoid = Character Head & Face + Character Biped Body
Mecha = Character Head & Face + Character Upper Body + Vehicle Lower Body

Skeletal Hierarchies are the first stage of authoring to receive a Name Convention. As most Skeletal Hierarchies have at least one axis of symmetry (local X axis), I adopted Blender's “side suffix” (_left/_right) into the UMECHS Skeleton Naming Convention.

I'm also in favor of using other direction designators to describe bone position in reference to the Spine/Nucleus and Root such as _top,_bottom,_upper,_lower,_front,_back.

Skeleton Hierarchy Naming Convention

Sequence of Interconnected Bones

Root:{Spine_0:{Spine_1:{Limb_0_Left:null}}}

Symmetry Suffix

Limb_0_Left

Standards: Geometry

# No isolated vertices. An isolated vertex is a vertex that is not attached to a face. Isolated vertices sometimes result from complex modeling processes or from importing skeletal meshes from 3rd Party Authoring Applications.

# No coincident vertices. Coincident vertices are separate, individual vertices in a single 3D object that occupy the same location. Coincident vertices can cause smoothing problems when the skeletal mesh is rendered, and can cause errors when the skeletal mesh is exported to other applications. To avoid these problems, coincident vertices must be welded or attached together to form a single vertex.

# No coincident/coplanar faces. Coincident or coplanar faces are two or more faces or polygons that occupy the same space and represent the same surface. These types of faces cause rendering problems, particularly a distracting flickering effect in animation renderings. Importing a CAD skeletal mesh into a 3D application can cause coincident faces, as can some face modeling techniques.

# Face normals point outward - By "outward" we mean the appropriate direction for correct rendering, with no normals incorrectly flipped.

# No empty objects - All objects should have geometry or splines or be null/control helpers. No "empty objects" that have names but nothing else permitted.

# No open edges or borders that cause see-through cracks in the skeletal mesh when rendered. This is not applicable to the seam or dissection edge where Skeletal mesh interconnects.

Standards: Geometry Topology

# Topology must use Quads only. Avoid using long Quads as the tend to cause shading errors during animations.

# Sub-dividable Topology: Model can be cleanly sub-dividable for higher detail and still retain shape of model. This requirement ensures that a sub-dividable model, when converted to other formats, will retain the same shape when subdivided. If the skeletal mesh is a real-time skeletal mesh (not sub-dividable), there is no reason to have a Crease value other than 0.

# Clean edge flow: Model must have the best possible edge flow, with sufficient geometry to meet these requirements without superfluous geometry.

# No poles with more than 5 edges on curved surfaces.

Standards: Geometry Scale

# Real-world scale within 1-3% - Model can use any units to achieve real-world scale. If the skeletal mesh does not have an exact real-world counterpart (such as a human character or an unbranded car), the skeletal mesh must use the size/scale of comparable objects in real life. Exception for exceedingly large/small skeletal meshes - Models of objects that have a real-world scale at a microscopic or astronomical level, such as amoebas and solar systems, are excepted from having real-world scale.

# Units used in the file should be included in the description.

Standards: Geometry Orientation

# Position Base of skeletal mesh at or near 0,0,0 origin in which the entire skeletal mesh sits on or just above ground plane.

# Oriented to World up-axis - The obvious "up" side of the skeletal mesh must be pointing toward the World up axis. In other words, the skeletal mesh can't be lying on its side or upside-down when the file is opened.

# Transforms - Artists will often merge your 3D skeletal mesh into a scene with other models. Putting your object at or near the 0,0,0 origin on your grid makes it easy to find the skeletal mesh after merging. You should also move the skeletal mesh to sit on or just above the ground plane.

Standards: Geometry Skeleton

# Skeleton Transforms must be frozen/reset unless model is animated

# Skeleton must function as expected - Rig must perform simple deformations

# Animation must play smoothly - No obvious glitches or hitches, unless it is deliberate for visual effect.

# Animations must include instructions on how to use the Skeleton and Controls in a ReadMe.html file.

Standards: Material & Texture

# At least one Material must be applied to the skeletal mesh to represent real-world object surfaces.

# Materials that are not used in the scene are not referenced by the scene. For example, if you use 3ds Max, materials not used in the scene should not be present in the Material Editor.

# No texture paths referenced by skeletal mesh. Any texture paths must be stripped from skeletal mesh. The Skin Theme Pack ZIP file should be set up with a "flat" file structure (no sub-folders) so that by default, all the files will extract into a single folder.

# Texture maps do not reference sub-folders (no texture paths).

# Textures packaged in a ZIP file with each raw 3D file format.

# No obvious texture stretching on Skeletal Mesh.

# Texture Seams hidden in less visible areas of model.

# All Texture UVs must be unwrapped.

UMECHS Consortium

Is a group of UDK Developers (Artist and Programmers) who volunteer to provide administration, asset inspection/moderation, module development, reference asset packs and other services to ensure the UMECHS system operates with the greatest of ease-of-use to the widest base of UDK Developers.

Repository

The UMECHS Consortium provides a centralized Resource Database to store this information. It would be difficult to keep track or know what Skeletal Mesh, Skeletons, Textures, Base-body, without a searchable knowledge base.

Skeletal Mesh Category ID
Base-body Part ID
Base-body composite ID

[Ernesto89x]

I am also exploring the procedural generation of characters for UDK, but I approached from the point of view of a programmer, I would like you could achieve the standard, to adapt my implementation to your solution, I make it customizable according to the needs of artists , but I like your idea. I advise you to read "Togelius" which is a supporter of procedural content generation

Julian Togelius, Search-based Procedural Content Generation:A Taxonomy and Survey, in IEEE2011. p. 147-161.

[TechLord]

Hi Ernesto89x,

I have every intention of offering Auto Assembly option within the UMECHS Module to compliment manual assembly of prefabs and customization. The Specification categorizes parts so that they are compatible and directly interchangeable. The current plan for the Auto Assembler, is to select at random from available parts using the same specification. However, I would like to offer more intelligence in the selection process so I'm very interested in search-based, generate-test, and rule-based algorithms that can achieve this.

[Ernesto89x]

Part of my thesis was to implement a metaheuristic algorithms library to link with UDK, and is finished with it I think you have the intelligence you want to select the parts. It is important to clarify that it is not very mature yet, only have three algorithms, and the objective function "Haming distance "

[TechLord]

Part of my thesis was to implement a metaheuristic algorithms library to link with UDK, and is finished with it I think you have the intelligence you want to select the parts. It is important to clarify that it is not very mature yet, only have three algorithms, and the objective function "Haming distance "

Hi Ernesto89x, are these algorithms publicly available? If not, would you be willing to share or least express the algorithm in plain english? I'm somewhat familiar with using heuristics in writing A* path-finding algorithm. However, I'm sure if that's related to what you describe.

[Ernesto89x]

Hi TechLord, this library is part of my thesis, so I'm willing to give it to who is interested to use it and modify, but first I have to solve some issues of authorship for the thesis document, so they do not attribute the authorship to someone else. But I can get ahead some reports with explanations of its implementation and design. However I plan post the library with source code, an example of its use in UDK and all documentation.
PS: If you are interested tell me how to send you the documentation

[TechLord]

Hi TechLord, this library is part of my thesis, so I'm willing to give it to who is interested to use it and modify, but first I have to solve some issues of authorship for the thesis document, so they do not attribute the authorship to someone else. But I can get ahead some reports with explanations of its implementation and design. However I plan post the library with source code, an example of its use in UDK and all documentation.
PS: If you are interested tell me how to send you the documentation

Yes, I'm very much interested. Please send to frankie_taylor@hotmail.com. You've mentioned adapting your implementation to the UMECHS solution. I'll take any and all assistance I can muster in drafting the Specification.

[Ernesto89x]

I have a bad news, documents are in Spanish, so I'll linger a while to translate, but do not worry, you will have then soon

[CaptCookie]

This is an interesting idea! Any news on progress?

[TechLord]

This is an interesting idea! Any news on progress?

Hello CaptCookie,

Thanks for your inquiry. Progress has accelerated over the past 3 weeks. In fact, I'm in the process of launching a campaign to promote development of Assets using the system.
Following the works of Siddhartha Chaudhuri chief architect and programmer of the Mixamo Fuse. What are your opinions about this this concept? I'm very much interested in a discussion about UMECHS.