Results 1 to 8 of 8

Thread: How to bring custom buildings in-game

  1. #1
    Mr.Jox's Avatar WHY SO SERIOUS?!
    Join Date
    Mar 2013
    Location
    Crimea
    Posts
    2,362

    Icon3 How to bring custom buildings in-game

    Earlier I have created another similar tutorial which is obsolete and no longer relevant. In these series of tutorials I'm going to provide you all the most recent information how to bring your custom building asset in-game and have it behaving properly.

    CONTENTS



    The process recorded in video format
    Last edited by Mr.Jox; February 22, 2018 at 08:10 AM.

  2. #2
    Mr.Jox's Avatar WHY SO SERIOUS?!
    Join Date
    Mar 2013
    Location
    Crimea
    Posts
    2,362

    Default Re: How to bring custom buildings in-game

    SCENE OBJECT TYPES ENUMERATION

    According to my researches, a common scene may include following object types:


    • Geometry (3d models consisted of different LOD levels);
    • Collision (3d models that are not supposed to be shown in game however they serve as a physical representation of your asset in-game);
    • Animation (a number of 3d models each of which has it's own animation clip);
    • Geometry reference (any random primitive geometry which you use to refer to already existing asset you want to include in your current asset);
    • Hard (a primitive figure consisted of enclosed series of lines that define your asset's shape);
    • Ground_ad (a primitive line with 2 vertices defining somewhat the ground-level AI hint line);
    • Platform (a plane 3d model which is used to define standing position(s) for units);
    • Platform ground (a primitive plane on the ground level which defines how and where unit will pass thru your destroyed asset);
    • EFline (a primitive line which is used to define unit's behaviour in particular spot on the platform according to your asset's geometry);
    • Docking line (a primitive line which defines the location of siege engine to be used to pass thru your asset);
    • Region zone (a primitive figure consisted of series of lines and serves some logical purpose of your asset);
    • Pipes (a primitive figure of series of lines (not enclosed) which defined how unit is supposed to climb on your asset. Somewhat I call a teleport);
    • Arrow emitter (a primitive geometry shape which specifies the vector of tower arrow to be thrown from);
    • Flag (some UI position?).


    Let's have a detailed look into each object. To have some uniformity between different objects and to ease your understanding of future steps I will describe objects in some attributes (which will be used in later steps).

    Geometry
    The creation of 3d models for your geometry is beyond our scope here and we suppose you're familiar with at least some basics of 3d modellings and texturing.
    Here we're going to have a look at how geometry is represented in your scene, it's naming standard and properties.
    Geometry objects are assets which you see in-game. It's a visible part of your asset in-game. A geometry is usually broken down on LODs (level of detail) meaning your asset will appear with different polygons(and vertices) count on different distances from your asset. A common number of LODs per geometry for buildings is 5.
    Besides LODs each geometry object can be split on several pieces. It means you can create various number of models and treat them as pieces of same, greater object.
    The last aspect of geometry we need to mention is destruction ID. Destruction ID specifies which geometry is going be shown at different destruction levels. So far I had luck to see up to 4 destruction levels used in vanilla assets.

    Naming standard: pieceID_destructID_lodID
    Where pieceID is your piece number. Pieces can't have similar ID if they are not supposed to be superseded by another object with the destruction level increased. It is common to have one/two/three pieces per asset. Higher number of pieces is optional but at least one is required.
    The destructID is your destruction level ID. Here in piece ID you should specify the exact same piece ID as you used for previous destruction ID so later during the game as you destroy your asset, the model gets replaced by next in order destruction asset. It's common to have one/two/three destruction levels. Higher is optional but at least one is required.
    The lodID is your lod number. As we mentioned above, 5 is the standard number of lods per geometry object.
    Piece is the minimal unit here. For each piece you have at least one destruction level and for each destruction level you have 5 LODs.

    rigid_TYPE STAND_RIGID
    class_TYPE DISPLAY
    piece_INFO pieceID (same as in object's name)
    destruct_ID destructID (same as in object's name)
    graphics_OPTION GRAPHICS_HIGH
    class_rigidINFO lodID
    rigid_OBJECT

    LODs example picture
    pieces example picture
    destructs example picture

    Collision3d
    The collision is an invisible geometry that defined some physical properties of your asset. Basically it helps the engine to understand whether projectile hits your object or not. It also does not let you pass thru invisible geometry box according the it's shape. One huge requirement in collision creating is the have as low vertices count as possible because each vertex is involved in expensive collision detection algorithm thus it's extremely important for performance. Unlike geometry, collision has no LOD levels.

    Naming standard: pieceID_destructID_collision3d_[optional]
    Where pieceID and destructID correspond to geometry objects (each collision piece should match the general shape of geometry piece and each collision destruction level should match general geometry destruction level). collision3d is a special tag that enforces this object to be collision-only. The [optional] tag is used in special cases like if you make the gateway asset. Since you have gates geometry which are dynamic at different circumstances, you have to define special tags such as gate_ajar and gate_closed.
    Naming example: piece02_destruct01_collision3d_gate_ajar which means that your piece02 is your not destructed gates (in open mode) model's collision.

    rigid_TYPE STAND_RIGID
    class_TYPE TECH
    piece_INFO pieceID (same as in object's name)
    destruct_ID destructID (same as in object's name)
    graphics_OPTION NOT_GRAPHICS
    class_rigidINFO collision3d_[optional] (_[optional] is gate-specific case, in other cases you should use only collision3d)
    rigid_OBJECT

    Collision3d picture example

    Animation
    The animation is a set of visible geometry with it's own animation clip. Animations in their most common way are played when your asset changes it's destruction level due to being damaged. During this process your original geometry models are hid and instead of them your animation geometry becomes visible and plays until it ends and after that all animation-related geometry is hid again and instead of it the game displays next destruction level geometry. Long story short: piece01_destruct01_lod1 gets damaged by some degree and according to db value at some point piece01_destruct01_lod01 becomes invisible and at the same time all building_piece01_destruct01_anim models become visible, all their animation tracks are played until the very end and then all building_piece01_destruct01_anim are hid again and game will make piece01_destruct02_lod01 visible instead.
    We will denote it as piece01_destruct01_lod01->
    building_piece01_destruct01_anim->piece01_destruct02_lod01
    Animations are usually the most time intensive objects to make. Unlike the creation of meshes I will briefly describe how to create animations:
    I use NVIDIA's PhysX plugin for 3ds max. I copy my geometry models that should be animated, I manually split them on different pieces with the same initial position as original mesh had and then I define rigid_body/kinematic_body/static_body properties of PhysX's plugin and simulate the scene. I usually have to fix some animations which don't look finished after being ruined.

    Naming standard building_pieceID_destructID_[optional]_anim
    Where building is a constant prefix, pieceID corresponds to proper pieceID of original geometry, destructID corresponds to original destructID (you never make animation for the last destruction level because you can't destroy the most ruined model) and anim is a tag that enforces converter to treat your geometry as animation object. [optional] tag determines special animations for different stances of gates (gate_closing, gate_opening, gate_closed_destruct, gate_open_destruct).
    It is important to mention that each new chunk of your original piece should be named in the same way. In other words when you manually split your original mesh onto chunks of that original mesh, each chunk of that particular mesh should be named exactly the same.
    For example, we had piece01_destruct01_lod01 and we created 10 chunks from it. Each chunk of that mesh should be named as
    building_piece01_destruct01_anim

    rigid_TYPE STAND_RIGID
    class_TYPE DISPLAY
    piece_INFO pieceID (same as in object's name)
    destruct_ID destructID (same as in object's name)
    graphics_OPTION GRAPHICS_HIGH
    class_rigidINFO [optional]_anim (where [optional]_ is used for some gate-specific cases. In most cases you must use anim)
    rigid_OBJECT

    Animation picture example (note that the final frame of animation perfectly matches the last destruct level of the tower with exception of pieces which went under the ground - this is the result you should achieve in order to make smooth transition) - that's why you first create undamaged geometry -> create animation out of it by splitting it on independent chunks and animating them using NVIDIA's PhysX -> create damaged version of building by copying animation chunks and merging those objects into a single mesh with name pieceID_destruct02_lodID.

    Geometry reference
    Imagine you have made/found another small asset such as torch or door or repetitive piece of geometry and want to use it in another asset once or several times. Sometimes the best way to do this is to refer to another asset. This is exactly what geometry reference is. The representation of reference is not strict. It mean you can create simple cube and use it as a reference to another object. What makes reference work is the proper naming and attributes. It doesn't mean you can't use the original model as a reference. Sometimes you wanna see how it is attached to your asset and so the best choice would be to use the original model as a reference to itself.

    Naming standard pieceID_destructID_file:filename
    Where pieceID and destructID are unique for the reference itself, not for the model you are referring to. file tag makes the BOB converter treat the object as a reference to another object with the filename which is the exact name of asset you are referring to.
    Naming example:
    piece01_destruct01_file:torch_sconce

    rigid_TYPE STAND_RIGID
    class_TYPE TECH
    piece_INFO pieceID (same as in object's name)
    destruct_ID destructID (same as in object's name)
    graphics_OPTION NOT_GRAPHICS
    class_rigidINFO key
    rigid_OBJECT relative_path_to_file (for example,RigidModels\Buildings\torch_sconce\ where RigidModels\Buoldings is the location of your source and reference assets and torch_sconce is the name of referred asset).

    File instancing example picture

    Hard
    A hard object is a primitive object consisted of an enclosed set of lines. It roughly describes ground-level boundaries of your visible asset. Hards are used per destruct level. In most cases you have only one hard per destructID but in special cases as with gates you make 2 hards per destructID.

    Naming standard pieceID_destructID_[optional]_hardID
    Where pieceID and destructID are naming attributes of attached geometry file. [optional] tag is used for special cases such as gates (for example, piece02_destruct01_outlineID_hard). As you can see when you use an optional tag you don't specify hard's ID but you specify optional's ID. The hard tag is the commonly used one and if you don't specify the optional tag you also have to specify hard's ID. in most cases it's just hard01.
    A hard is created on a per-destruct basis (meaning you should create a hard per each destruction level).
    Unlike all previous objects that are treated as meshes, this object is not a mesh. It is a set of lines. Thus in 3ds max you use Line object to create hards.

    rigid_TYPE STAND_RIGID
    class_TYPE TECH
    piece_INFO pieceID (same as in object's name)
    destruct_ID destructID (same as in object's name)
    graphics_OPTION NOT_GRAPHICS
    class_rigidINFO [optional]_hardID (where [optional]_ is used for some gate-specific cases. In most cases you must use hardID. However if you specify an optional tag you should not specify hard's ID)
    rigid_OBJECT

    Hard example picture

    Ground_ad
    The ground_ad object type is used to define an AI Hint from what I understood. It is consisted of strictly 2 vertices and is a Line object in 3ds max scene. Commonly you locate it in origin on the ground level (means Z(up) = 0) with Y(front/back) position displaced depending where the centre of your asset is located along this axis). X is also defined as 0.

    Naming standard: pieceID_destructID_ground_ad
    Where pieceID and destructID are normally have ID = 01 (because ground ID is a single per asset and so is attached to the main piece and none of destruct levels but 01 have this type of object).

    rigid_TYPE STAND_RIGID
    class_TYPE TECH
    piece_INFO pieceID (same as in object's name)
    destruct_ID destructID (same as in object's name)
    graphics_OPTION NOT_GRAPHICS
    class_rigidINFOground_ad
    rigid_OBJECT

    ground_ad example picture


    Platform
    A platform object is usually a primitive plane mesh covering the area which will allow your units to stand and move on. It is important to mention here that if you're making fort assets such as walls, towers, gateways etc you should ensure that platforms perfectly connect and snap vertex-to-vertex in connection zones. Otherwise you will end up with units being unable to deploy/move on your assets. A platform is created on a per-destruct basis.

    Naming standard: pieceID_destructID_platformID
    Where pieceID and destructID are respective IDs of "parent" visible geometry object, i.e. if you have a wall denoted as piece01_destructID_lodID and you create a platform for this wall you should give the pieceID the ID of it's visible geometry.
    platformID is a unique ID of platform per single destruct. As you can guess, you can have more than single platform per destruct level.

    rigid_TYPE STAND_RIGID
    class_TYPE TECH
    piece_INFO pieceID (same as in object's name)
    destruct_ID destructID (same as in object's name)
    graphics_OPTION NOT_GRAPHICS
    class_rigidINFO platformID
    rigid_OBJECT

    Platform example picture

    Platform_Ground
    A platform_ground object type is used to allow units to pass through ruined version of your asset. As you could guess it is used mainly for ruined wall pieces as the last destruct level. Platform_ground is relatively simple shape but unlike the regular platform, this one is not a perfect straight plane. It has somewhat curved shape where the middle is the highest point and sides are lowest so when units steps onto this platform it looks like climbing on a heap of trash/ruins. The boundaries of this platform should match boundaries of your destructed asset so it doesn't look like units fly above your asset or go underneath. This is still made from a plane primitive 3d object and has no backfaces, only the faces above the ground level (that's where name comes from). Normally platform_ground is a single object of this type per asset.

    Naming standard: pieceID_destructID_platform_ground
    Where pieceID and destructID are inherited from your last destruct level. platform_ground is a constant tag to help the converter tool to treat it as a platform_ground object (obviously).

    rigid_TYPE STAND_RIGID
    class_TYPE TECH
    piece_INFO pieceID (same as in object's name)
    destruct_ID destructID (same as in object's name)
    graphics_OPTION NOT_GRAPHICS
    class_rigidINFO platform_ground
    rigid_OBJECT

    Platform_ground example picture

    EFLines
    EFlines will quickly become the most hateful object in your asset scene. These lines are small strictly 2-vertices-based line objects (yeah the same lines are used for hards). You have a set of EFLines per platform because during the converting process all your eflines are attached to platforms and if at least one doesn't match you will fail to convert your asset.
    So what are these objects? These objects define unit's behaviour when it is standing within the area of efline. Ever encountered how units turn their bodies near merlons on the walls while rest of units standing behind them and act the other way? That's exactly what eflines are used for.
    It's a common practice to have about 200 eflines per scene/asset. What is even worse, you have to attach attributes a properties for EACH. Fortunately I found a way to create a 3ds max script (will be provided in last tutorial) that eases your work and makes all that work in single mouse click. However before using the script you must create all your eflines and ensure the result is final because the process is
    irreversible.

    Naming standard:
    EFline_pieceID_destructID_lineID
    Where EFline is a constant tag defining object as an efline object. pieceID and destructID correspond to appropriate platform (to understand the "parent" platform of your efline you simple check with your eyes whether it lies on the platform or not.
    lineID tag stands for your unique line's ID. It's important to mention that eflines within the same destruct level can't share same lineID even if they are attached to different pieces.

    rigid_TYPE STAND_RIGID
    class_TYPE TECH
    piece_INFO pieceID (same as in object's name)
    destruct_ID destructID (same as in object's name)
    graphics_OPTION NOT_GRAPHICS
    class_rigidINFO EFLineID
    rigid_OBJECT

    Docking_lines
    Unlike EFLines the docking lines are easy and fast to create. Obviously, like EFLines and Hards, DockingLines are the same "line" objects consisted of 2 vertices (you can probably use more but I'm almost sure it's strictly 2 vertices and single line per dockingLine).
    These lines serve as an attaching point for siege engines in order to breach/besiege your asset (wall - siege tower, gate - battering ram etc). You can have multiple dockingLines per destruction level but you have no dockingLines per last damaged destruct level (obviously because it is already ruined).

    Naming standard: DockingLine_pieceID_destructID_lineID
    Where DockingLine is a constant tag defining the object type. pieceID and destructID are appropriate IDs of attached geometry and lineID is a unique ID per each line.

    rigid_TYPE STAND_RIGID
    class_TYPE TECH
    piece_INFO pieceID (same as in object's name)
    destruct_ID destructID (same as in object's name)
    graphics_OPTION NOT_GRAPHICS
    class_rigidINFO DockingLineID
    rigid_OBJECT

    Region_zones
    Region_zones are not completely clear even to me. From my experience they define so called "battlefield_zone" (yes similar to one you have in TEd editor) and this zone allow your units to move/deploy and do rest of siege stuff on/in your asset. If EFLines and DockingLines define the action/purpose itself and define positions for that, region_zones allow those Lines to be used within the area defined in region_zone. Region_zone area is consisted of a set of Lines and is a Line object in 3ds max scene. It is created in the same way as you create Hard objects. So the rule for Hard objects apply for region_zones: it must be enclosed set of Lines meaning the first and the last vertices should be connected with Line.

    Naming standard: region_zoneID
    Where ID is a unique ID of your region_zone object. It means you can have multiple region zones per asset. The common number for region_zones in your scene is 2 region_zones with 4 vertices each (in case your asset is straight). It's unknown to me why you must define at least two region zones where you cover same area with 2 zones instead of single.

    rigid_TYPE STAND_RIGID
    class_TYPE TECH
    piece_INFO pieceID (normally you define 01 as an ID for this kind of object)
    destruct_ID destructID (normally you define 01 as an ID for this kind of object)
    graphics_OPTION NOT_GRAPHICS
    class_rigidINFO region_zoneID
    rigid_OBJECT

    Pipe_wall_door
    Pipes are "open" sets of Lines (meaning you don't have to connect the last vertex with the first). The object type in the scene is "Line". The idea of this object type is some kind of teleport and here is why: when you command a unit to climb on your walls they go to these pipes (invisible in-game and usually are put inside doors, connecting upper and bottom doors) and once they are at a certain distance to your pipes (doors) they disappear nearby your bottom door and appear on the upper door(tunnel) on the wall. This is why I call this teleporting.
    This set of Lines look like a line coming inside the door's geometry (reminding a normal-vector but is not strictly perpendicular), then next lines change direction towards the up axis and then they change direction once more towards the upper doors direction. That's why this object is called pipes - because it's architecture reminds common water pipes which you use to warm-up your house (they are either near wall or built-in the wall).

    Naming standard: pieceID_destructID_pipe_wall_doorID
    Where pieceID and destructID are inherited from the parent's object name (usually it's piece01 and destruct01 because pipes in most cases are used per destruct level undamaged and not per destruct level damaged (obviously coz doors are broken)). pipe_wall_doorID is a unique ID of a particular pipe object.

    rigid_TYPE STAND_RIGID
    class_TYPE TECH
    piece_INFO pieceID (normally you define 01 as an ID for this kind of object)
    destruct_ID destructID (normally you define 01 as an ID for this kind of object)
    graphics_OPTION NOT_GRAPHICS
    class_rigidINFO pipe_wall_doorID
    rigid_OBJECT

    Arrow_emitter
    The arrow_emitter object type is used mainly for towers and it's purpose is to define the direction and position (in other words the vector) of the arrow to be thrown from your tower. Normally in your tower geometry you have small windows as location where arrows will be thrown from and so that's where you have to place your arrow emitters. From my experience arrow emitters can be of any shape however it is recommended to make it a plane with only single side so it defines the direction. Later you match the position and direction (and scale) of your plane object to the window for the arrow to be thrown from and make it N times (where N is the amount of your windows per asset).

    Naming standard: pieceID_destructID_arrow_emitterID
    Where pieceID and destructID are inherited from parent's filename (geometry with built-in windows for this purpose). Usually your pieceID and destructID are always = 01 because for obvious reasons, when your tower is damaged/destroyed you no longer have an access to the windows (because the first thing the game AI is going to damage is your towers).
    The emitterID is a unique ID of your emitter object given with numerical order (same as given for any other object IDs).

    rigid_TYPE STAND_RIGID
    class_TYPE TECH
    piece_INFO pieceID (normally you define 01 as an ID for this kind of object)
    destruct_ID destructID (normally you define 01 as an ID for this kind of object)
    graphics_OPTION NOT_GRAPHICS
    class_rigidINFO arrow_emitterID
    rigid_OBJECT

    Flag
    The flag is the most unknown object type for me so far. I haven't tried to test what it is used for but if you ask my guess I'd bet it is used as an identifier for the UI element to be placed at. Imagine your create different scale towers, some are bigger some are lesser. If you are a programmer how would you ensure the UI element (the type of asset icon, for example, tower, gateway, wall etc.) is located only above your asset and not within it (somewhere in the middle)? From my point of view you have two choices: either find max vertex positions and put a UI element above those values with some given offset or use a special identifier such as this flag (UI flag?).
    Anyway it is only my guess and I did not test whether it is true or not but what I can say about the creation process of this object type is as follows: Flag is any kind of geometry but normally I use box as a placeholder for flag object and define flag's position by specifying position for my box object. It's a common practice to place your flag in 2 or even 3 meters above your highest asset's vertex position.

    Naming standard: flag
    Where flag is a constant tag. As you can see flag tag as no ID postfix and it means you can have no more than only one flag per your asset.

    rigid_TYPE STAND_RIGID
    class_TYPE TECH
    piece_INFO piece01
    destruct_ID destruct01
    graphics_OPTION NOT_GRAPHICS
    class_rigidINFO flag
    rigid_OBJECT

    Please, note: The list of object types above (and highly possibly) is incomplete. I did not have my hands on all of the vanilla assets and I can't be sure the above list is full. If I ever encounter a new type I will add it to the list (if laziness will allow me to ).
    Last edited by Mr.Jox; January 12, 2018 at 03:11 AM.

  3. #3
    Mr.Jox's Avatar WHY SO SERIOUS?!
    Join Date
    Mar 2013
    Location
    Crimea
    Posts
    2,362

    Default Re: How to bring custom buildings in-game

    OBJECT CREATION PIPELINE

    In order to properly build your 3ds max scene in fastest and simpler way with minimum of trial and error ways I denoted so called Object creation pipeline (OCP). It's purpose is to describe steps from where to start, which order to follow and how to get everything together.

    We will break the OCP on the following steps:


    1. First goes the atlas texture. It's not obvious but in order to save memory usage and improve performance you want to make an atlas texture which includes all needed texture patterns for all cases. It means you use single texture for each asset of particular culture. You can find how atlas textures look in vanilla files. The texture creation is beyond our scope in these tutorials.
    2. Create all mesh pieces. It is important to strictly follow the concept of your asset you're going to make. Because if you are not sure of the final shape you want to make, you will be redoing everything almost from scratch several times. Slight changes are still allowed at later steps but try to minimise the changes required on later stages. What is also extremely important here is to consider whether your asset is a standalone or going to be a part of another bigger asset. For example, on one hand you can make a standalone random house model which require literally just the mesh and collision but on the other hand you want to create a wall piece which will be connected to gateways/towers and other pieces of fort. This means you should save sizes somewhere and follow those sizes perfectly. Otherwise your pieces will not match and logic not gonna work (logic means here your units will be unable to deploy on walls, move on them etc).
      If you ask for a tip, add the connection object to your scene, just for the size references. At this particular step it's recommended not to create LODs but only piece(s) and their respective destruction levels. Important: Do not create damaged/destroyed models at this stage! Otherwise you risk not to match it with the animation.
    3. Set up the material settings. At this step we suppose you have created your 3d models and unwrapped them according to your texture atlas. What is needed to know here is mostly the same you do when you create custom assets for units such as helmets. You put different textures to their respective slots in material shader parameters and you specify the rigid_material. However one more advanced step is important here. Usually you have more than just single atlas texture. For example you sometimes have specific texture set for gates only or you have additional texture atlas for doors, windows, columns and such. You simply set up two distinct materials and then you create a 3rd material with Multi/Sub-Object Material type. You just drag your distinct materials to each slot of newest material. To refer to different materials within one supermaterial you use polygon ID in geometry menu (its near smoothing groups). It is extremely important to mention, building assets support 2 layers (channels) of UVs. It means you can have 2 distinct channels with different UV layout for additional effects such as tiled_dirtmap.
    4. Create animations. What you need for animations is only your piece meshes. Split them on chunks manually and simulate the destruction with NVIDIA's PhysX plugin for 3ds max. This step is optional because you don't have destruction levels for assets such as houses or other generic "inner" buildings and even if you do have one you mostly never will encounter AI attempting to damage your inner buildings, for obvious reasons. Important: Only after you've finished the animation you should copy all animation chunks (with exception of chunks beneath the ground for performance reasons) and merge all chunks into single mesh.
    5. Create simple cube shape to refer to external assets if needed. We call this instancing or referring to pre-existing assets.
    6. Once you're done with meshes and animations you can start creating TECH objects. TECH refers to technique and usually means these objects will not be seen by player but play huge role in game logics. These objects are: collision3d, hard, platform, platform_ground, bridging_columns, region_zones, eflines, docking_lines etc. The order is not strict here and you have the freedom what to do, however I suggest leaving eflines and region zones for the last and start with collison3d. That's because eflines are the most tricky to work with and you definitely will not want to remake them.
    7. For this step it is suggested to make asset-specific logics such as arrow emitters, pipes etc. It is also perfect time to create LODs
    8. This step is kind of boring one. It requires you to define object custom attributes and object properties for each object. Yeah! In your scene (if it is fort-related asset) you have in average about 200 objects! And for each of that object you have to define custom attributes and properties. Fortunately I made few 3ds max scripts that ease this process however its not perfect and you often will have to do manual work here.
    9. If all above steps were done correctly you now should be able to export your scene as .cs2 file (don't forget to check "export all keys" if you have animations in ur scene). You should define rules.bob rules in this step and launch BOB convert to proceed your .cs2 file and convert it to game-ready assets.
    10. In this step you should work with database a bit. BOB generates 2 db files, one is battlefield_buildings and the other one is models_buildings. The first one is the one you should edit with PFM and the second one should be not edited (and cannot be edited due to PFM restrictions). Once you're done with this you can optionally copy-paste vanilla .meta files (used for defining SFX per assets) and import your newly converted game-ready asset files to your PACK file with PFM. At this step your asset is consisted of (optional).anim, rigid_model_v2(used for geometry and references to textures), metas(used to refer to SFX), cs2.parsed(consists logics of ur asset, including collision), textures and database files.
    11. The last step depends how you want to use your assets. If you want it to use in TEd to add on your custom map you should create additional pack file and import ONLY database files of your asset. The trick here is to make this pack type -> movie. Because other types of pack don't make your asset visible and accessible in TEd. If you don't want your asset in TEd any longer and want it to appear in game you should have ALL your asset files in ur final pack file and define pack type -> mod. Don't forget to remove movie pack type once you're done with TEd because movie packs make your launcher crash whenever you try to enable/disable mods in mod manager.

    So briefly here's the pipeline:

    Create textures -> create meshes (with exception of damaged meshes) -> set up material -> create anims -> create damaged meshes based on animation's final frame -> create reference meshes (instances) -> create logics -> create asset-specific logics -> apply attributes and properties -> export, setup rules and convert -> code your asset in DB -> add files to pack.
    Last edited by Mr.Jox; November 15, 2017 at 04:57 AM. Reason: Im damn bad at formatting

  4. #4
    Mr.Jox's Avatar WHY SO SERIOUS?!
    Join Date
    Mar 2013
    Location
    Crimea
    Posts
    2,362

    Default Re: How to bring custom buildings in-game

    RESERVED

  5. #5
    Frunk's Avatar Form Follows Function
    Moderator Emeritus

    Join Date
    Jun 2009
    Location
    Gold Coast
    Posts
    6,495

    Default Re: How to bring custom buildings in-game

    Always great to see new tutorials. Awesome work mate! +rep

  6. #6
    Mr.Jox's Avatar WHY SO SERIOUS?!
    Join Date
    Mar 2013
    Location
    Crimea
    Posts
    2,362

    Default Re: How to bring custom buildings in-game

    Quote Originally Posted by Frunk View Post
    Always great to see new tutorials. Awesome work mate! +rep
    Always great to know my researches (I spent weeks on it) are not useless ;P

  7. #7
    Mr.Jox's Avatar WHY SO SERIOUS?!
    Join Date
    Mar 2013
    Location
    Crimea
    Posts
    2,362

    Default Re: How to bring custom buildings in-game

    I felt lazy to finish the text tutorial.
    Instead I've recorded the process in my video series which are available by the following link: https://www.youtube.com/playlist?lis...IfYwpwGFEnsDg2
    It doesn't cover every possible asset that can be made however the biggest majority is all there and should be easy enough for everyone to pick up.

  8. #8

    Default Re: How to bring custom buildings in-game

    Good gracious, imma stick with M2TW and the IWTE o.O

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •