Announcement

Collapse
No announcement yet.

Universal Modular Entity Construction System for UDK

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    The UMECHS Compendium of Interchangeable Modular Entity Asset Parts

    Hello Everyone, I'm in the planning stages for the UMECHS Compendium of Interchangeable Modular Entity Asset Parts for the UE4 Marketplace. I'm a code-centric Game Dev, and for me producing Game Content is a significant challenge and obviously in the highest demand. Unfortunately, I don't have a large budget, which makes Online Marketplaces selling content for reasonable prices extremely appealing. A reasonable price point, geared for distribution to the masses, under non-exclusive licensing. If you're like me, we strongly desire our games to be populated with distinctive entities that standout from the rest. This presents a dilemma.

    I'm faced with the decision to either purchase content with intention to modify it or walk away empty-handed. In the good ole days, modifying textures and materials was enough to transform a store-bought asset into something unique. Today, it requires considerably more work, which is counter productive to purchasing assets in the first place. I usually end up walking away and no profit for the Asset Seller.

    I realized that a possible solution to this dilemma could be similar to what many MMORPGs implement to provide millions of Players distinct Characters: Modularity and Customization. Thus, I went on a quest in search of a Online Market that specialized in interchangeable parts for all types of Game Entities: Character Head/Body, Vehicle/Machines, Melee Weapons, Projectile Weapons, Architecture, Structures, Furniture, Plants, Hybrids, and whatever.

    Unfortunately, no such Marketplace exists. The question is Why Not? Is it due to few Artist enjoy producing interchangeable parts? Is it due to few Game Producers desire or require interchangeable parts in their games? My answer is to the Why Not is two-fold, 1) the need wasn't recognized, 2) no Dedicated System was in place to support this.

    Until now...

    The UMECHS Compendium.

    The UMECHS Compendium will:
    1. Provide an extensible system of assembly for in-game customization of most Game Entities.
    2. Support prefabrication of a various Entities with Parts to provide more in-game Content on a smaller budget of assets, time, money.
    3. Provide numerous layers of modularity to offer Game Producers a means to generate unique Entities via customization.
    4. Allow Game Producers to selectively expose parts of the Assembly System to their Player-base for customizing Characters and more.
    5. Supply the Assembly System with High-quality Interchangeable Asset Parts, Parts Packs, Entity Packs, Entity Collections, Theme Packs.


    The UMECHS Compendium is a Full-Service System: Managed Specifications, Template Assets: Rigs, Skeletal Meshes, Materials, and Blueprint Module/Custom C++ Libraries to support in-game, local/networked, assembly|dis-assembly/modification/animation, optimization of Modular Game Entities. These systems work together to provide Game Producers with a Content Management System to populate their game worlds with Entities; provide Artist a foundation in which to author interchangeable assets automatically within spec, with full creative freedom.

    Mass Customization is the wave of the future. The UMECHS Compendium is designed specifically for authoring Assets for mass distribution in a open online Marketplace. Additionally, it provides a powerful in-game customization system for Game Developers that can used in multiple products. Game Developers like me desire unique and near-exclusive entities for our games and we can achieve this with ability to customize them. I'm seeking Feedback from both Artists and Game Producers. Thanks for reading the massive wall of text.

    Leave a comment:


  • replied
    Thanks for your answer.
    While I consider myself an all-round guy, at this point of time I am unable to lend a hand in this project.
    I do however see the potential here, best of luck to you!

    Leave a comment:


  • replied
    Hi davek,

    With UE4 there comes new developments. In fact, the EPIC developers are dedicating a blog. As UMECHS is based on the use skeletal mesh Rigs, its animation-centric, regardless if animation is used. The UE4 Montage animation system may introduce some changes that UMECHS will adopt. We're in dire need of input from the Artist perspective.

    Leave a comment:


  • replied
    Hi guys, how is this project progressing ? I see a lot of good stuff here. Did UE4 change things in some way ?

    Leave a comment:


  • replied
    Modular Turret Entity


    UMECHS is more than just modular parts for appearance, its about modular functionality too.

    Leave a comment:


  • replied
    Originally posted by CaptCookie View Post
    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.

    Leave a comment:


  • replied
    This is an interesting idea! Any news on progress?

    Leave a comment:


  • replied
    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

    Leave a comment:


  • replied
    Originally posted by Ernesto89x View Post
    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.

    Leave a comment:


  • replied
    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

    Leave a comment:


  • replied
    Originally posted by Ernesto89x View Post
    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.

    Leave a comment:


  • replied
    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 "

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied

    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
    Code:
    Root:{Spine_0:{Spine_1:{Limb_0_Left:null}}}
    Symmetry Suffix
    Code:
    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

    Leave a comment:

Working...
X