Frictional Game Wiki

<h1>Artist's Guide</h1> <div class="level1"> </div> <h2>Player Character Information</h2> <div class="level2"> <p> Information regarding the player controlled character to guide for appropriate dimensions. </p> </div> <h4>Player Size</h4> <div class="level4"> <ul> <li class="level1"> Width: 70 cm</li> <li class="level1"> Height standing: 190 cm</li> <li class="level1"> Height crouching: 120 cm</li> <li class="level1"> Eye (camera) position: 10 cm below height.</li> </ul> </div> <h2>Level Information</h2> <div class="level2"> </div> <h4>Measurements</h4> <div class="level4"> <p> The following measurements are good if kept and all models created should assume them. However, they are not set it stone and can be broken if really needed. However, do not go crazy and use other measures for the fun of it, break them only if really needed. For example, if there is to be a hole in a wall for the player to crawl through it might look silly with a 0.25 meters thick wall, and you want to ramp up to 0.5 or even 0.75 to make it look good. </p> </div> <h5>General</h5> <div class="level5"> <p> <b>Wall thickness:</b> 0.25m<br/> <b>Ceiling thickness</b> 0.25m<br/> </p> </div> <h5>Doorways</h5> <div class="level5"> <p> The size of the doorway (ie the hole in the wall that it is placed in) depend on what kind of door it is. For doors that are swingdoors (ie normal doors on hinges) and/or are meant be be used in a realistic real-life environment then a certain set of measurements. This type is called "realistic". If the door is meant to be used in more sci-fi setting or that the doors themselves are not ordinary, then another set of messurements is used. This type is called "fantastic". </p> <p> <b>Realistic:</b> 1.5m x 2.5m<br/> <b>Fantastic:</b> 1.75m x 2.75m<br/> </p> </div> <h5>Doors & Frames</h5> <div class="level5"> <p> The doors should be smaller than the doorframe hole, but be careful not to overdo this. The rest of the hole space is filled up by the frame (see below).<br/> <b>Standard size:</b> 1.3m x 2.45m (this is what looks best for a normal realistic door)<br/> <b>Minimum size:</b> 1.1m x 2.3m (this is so that AI will always fit).<br/> </p> <p> The frames of the doors can be whatever you like, the only thing necessary is that they fill up the hole so if the door were to removed the walls are not visible. </p> </div> <h2>Characters</h2> <div class="level2"> <p> When creating a characters for depth there are some things that need to be kept in mind. </p> </div> <h3>Basics</h3> <div class="level3"> <p> This are some general points that apply to any kind of character. </p> <ul> <li class="level1"> Areas where the character will most likely bend should have extra polygons for smoother deformation. Example: Knees, elbows, wrists. </li> <li class="level1"> Never do any textur mirroring or similar. Every pixel on the rendered character should be a unique texture pixel.</li> <li class="level1"> The max bone count is 96 bones. Make them count and think of this when adding details that need to to be animated.<br/> <em>Note: this limit is not set in stone, if more are needed the engine can be updated to handle this!</em></li> </ul> </div> <h3>Humanlike</h3> <div class="level3"> <p> This include any character that has a human like appearance and features. Basically any character that might be in need of facial animations. </p> <p> <b>General</b> </p> <ul> <li class="level1"> Clothing and accessories like watches should be a part of the mesh. We dont want body parts sticking out of clothes.</li> <li class="level1"> Spend polygon budget wisely. Example: If the character has a baseball cap make sure it is smooth as the silhouette will be very noticable. Also have more polygon density on the head then the body.</li> <li class="level1"> All skin surfaces must be seperate texture</li> </ul> <p> <b>Face</b><br/> </p> <ul> <li class="level1"> The face shall always be a separate texture/material.</li> <li class="level1"> A good idea is to split the head texture where the neck meets the shirt line, to try and keep it as seamless as possible.</li> <li class="level1"> If there is any amount of facial hair (very large beard or any haircut more than very bold), hair must have a separate texture.</li> <li class="level1"> Eyes need to be separate submeshes and also have their own textures.</li> <li class="level1"> Make sure there is enough mesh for the pupil to get to every corner of the eye.</li> <li class="level1"> Eyelids should be able to open and close.</li> <li class="level1"> Mouth need to be able to open, have teeth, toungue and uvula</li> <li class="level1"> The facial rig should allow exaggerated poses (if we were to have animations to be seen at a distance)</li> <li class="level1"> The inside of nostrils must be modeled</li> </ul> </div> <h2>Entities</h2> <div class="level2"> <p> Entities are all objects that can be (but do not have to be) dynamic and will always have an .ent file. The ent-file always include a model file but can also include lights, physics, sounds, animations and more. These make up the foreground of the game. </p> </div> <h3>What is an entity?</h3> <div class="level3"> <p> It should not hard to identify what should be an entity, but sometimes the object you have in mind is made up out of one or several entities. The easiest rule of thumb to have is that an entity only serves a single purpose and allows for a single coordinated movement. For example, if you have a door with a scanner, and lamp above, it and a cog wheels that turn when the door move, this is NOT a single entity instead this would be split into four different. These would be: </p> <ul> <li class="level1"> Door (and frame)</li> <li class="level1"> Scanner</li> <li class="level1"> Lamp</li> <li class="level1"> Cogwheel</li> </ul> <p> Each of these serves a single purpose, the door can be opened, the scanner can be interacted with (and light up/down), the lamp can be turned on/off and the cogwheel can spin or stand still. All of these require different controls and thus need to be made into different entities. Another example (which is different from how Amnesia worked) would be a desk of drawers, here there would actually be two different entities. One for the frame and one for each drawer. The reason is that each drawer has its own movement to be controlled, and thus require a single entity for each drawer the desk contains. If the desk had only contained a single drawer the drawer and frame would be one single entity! </p> <p> Do NOT take this this thinking too far though. For example if a machine has lots of lights that light up when it starts working, and no other moving parts, then DO NOT make this into two entities, one lamp and one machine. Because the lamp and machine work in unison (lights light up when the machine start) there is no need to split them up! As always, if unsure, ask someone else (this makes it possible to put the blame on another person ;)) </p> </div> <h3>Categories</h3> <div class="level3"> <p> First of all, entities needs to be placed in the main category that they belong to. This is can be "creatures", "organic" or a category for a specific type of environment in the game, e.g. "shipwreck". All main categories then have sub categories that the individual entity folders are placed and for most categories these vary a lot. However for the environmental categories (like "shipwreck") there is a certain basic system: </p> <p> What follows is a list of the most common categories of entities: </p> <p> "lamps"<br/> Everything that emits light and can be turned on and off. </p> <p> "furniture"<br/> Stuff like sofa, tables, chairs, etc are placed here. Most stuff you see at Ikea is found here. </p> <p> "ornaments"<br/> This entails any kind of objects explicitly used to spice up the room. Vases, statues, books, etc belong here. This is NOT anything you think will spice up a room, but something the virtual/fictional owners have placed to do so. </p> <p> "ornaments_wall"<br/> Just like ornaments but everything that belongs on a wall. Posters, paintings, mirror, etc are in here. </p> <p> "machines"<br/> Anything that does some kind of mechanical process is in here. Diesel engine, pneumatic press, etc are here. </p> <p> "tech"<br/> All electronic gadgets go here: computers, speakers, radios, etc. </p> <p> "panels"<br/> Screens hat can be interacted with. E.g. hand scanners, eye scanners, touch screens, etc. </p> <p> "gameplay"<br/> Simple things that the player can physically interact with, which includes buttons, switches, levers, wheels, etc. This also any special object used for gameplay purposes, for instance woodboards the player can pry of a window or a special bridge that comes out of a wall. If it is used for gameplay, and do is not really fitting in another category it belongs here! </p> <p> "storage"<br/> Inventories you would find in a warehouse or storage room. Barrels, crates, boxes and shit. </p> <p> "tools"<br/> Any common (or perhaps uncommon) useful tools go here. Scissor, hammer, screwdriver, fire extinguisher, buzz saw, etc </p> <p> "utility"<br/> Things that are sort of "attached" to the environment and serve direct specfic physical usage. Examples: sprinkler, electrical outlet, ventilation, etc </p> <p> "organic"<br/> Flowers, corpses, gibs, etc. Anything like that. </p> <p> "debris"<br/> Non-useable static junk for the floor. stones, plaster, cloth, paper, etc. </p> <p> "support"<br/> Things that cannot really stand on their own and have many uses. Planks, girders, steel bars, beams, stretch of rope, etc. Anything that you use together with the environment and very seldom by itself. Important note: Much of this should probably be in static objects, so only use it here if it has lots of polys or a need to by dynamic. </p> <p> These are of course not the only categories available but should give a good start. If adding categories, do NOT add to specific ones like "red herrings" or have two categories that could contain the same entities, like "food" and "groceries". </p> </div> <h3>Naming</h3> <div class="level3"> <p> When naming entities the main rule is to make it easy for other people to easily find objects when editing. In order to do so make sure not to be to general and to name things in order of descending importance. Something like this: </p> <p> <em>[type of object]_[object name]_[attributes]</em> </p> <p> Examples: "computer_laptop_broken", "table_dining_room_wood_large" </p> <p> Make sure to be consistent in this type of naming, so that you do not have several different names for the same type of object. For example, do NOT begin some names with "pc", some with "computer", some with "terminal", etc. Instead begin all entity names with a single name, like "computer_" instead! </p> <p> You do not need to be all to specific in this kind of naming, so do NOT have names like: "computer_linux_red_hat_networked_600gb_ram_white"!!!<br/> But do NOT be too unspecfic either and name something "computer_small" either! </p> </div> <h3>Type Specifics</h3> <div class="level3"> </div> <h4>Slide Door</h4> <div class="level4"> <p> When making a slider door make sure that the opening is always along the Z-axis (that is any character would go through the door along the z-axis). </p> </div> <h4>Swing Door</h4> <div class="level4"> <p> Make sure that the door opens in the postive Z direction. That is when the door swings open it will travel down a postive z axis. </p> </div> <h3>Shapes, bodies & Collisions</h3> <div class="level3"> <p> Shapes are used to create bodies which in turn are used to give entities all their physical properties. </p> </div> <h4>Shapes</h4> <div class="level4"> <p> Shapes can consist of the following shapes: </p> <ul> <li class="level1"> Box</li> <li class="level2"> Capsule</li> <li class="level2"> Cylinder</li> <li class="level2"> Sphere</li> </ul> <p> Sphere is the fastest (as in takes the least amount of processing power), followed by capsule, cylinder and finally the box is the slowest. </p> </div> <h4>Bodies</h4> <div class="level4"> <p> Bodies are created from one or several shapes. Bodies contain the actual properties for weight, collisions and so forth. It is to bodies that you attach models, lights, sound etc which results in the final entity. </p> <p> For all bodies make sure to, AT THE VERY LEAST, configure: </p> <ul> <li class="level1"> Body Material, this sets what sound, particle and physical behavior the body will have. For example, set it to Metal, and it will clank and show a spark on impact, and the entitiy will have less friction than if it were set to for example dirt.</li> <li class="level1"> Mass, set this to something realistic (in kg), setting it to 0 will make any type of entity static.</li> <li class="level1"> Max Linear & Angular Speed, a value of 8 to 16 seems to let entities move fast, but not get out of hand. Tip of the day: This can be used to fake air resistance by using a very low value.</li> </ul> </div> <h4>Creating Bodies for Collision</h4> <div class="level4"> <p> When configuring the bodies to be proper colliders for entities there is basically one goal: <b>To use as few and simple shapes as possible to create an as accurate as possible body (or bodies) for collsions.</b> </p> <p> Some general rules: </p> <ul> <li class="level1"> Don't create a body that has too great of a difference for the values of x, y, z. For example creating a very thin box to be a collider for a piece of paper is a bad idea if the paper is going to be dynamic, it will behave strangely and can even fall through the floor.</li> <li class="level2"> Use a mix of bodies that have character collide, none character collide and both. For example a table, should have character collide turned off on all bodies that does the actual colliding for the table shape against other entities. Then one single body should enclose the whole table, with character collide turned on but none character collide turned off. This will make the player character behave more appropriate when in contact with the table.</li> <li class="level2"> Test collisions for your entities in-game. This is best done by taking a simple entity, like a small box and then push it against the newly created entity to see how well the collisions work. This is mainly important in the beginning, to see just how simple type of shapes you can get away with, or to quickly notice that you can't be too sloppy either.</li> </ul> </div> <h5>Collider Examples - Wheel</h5> <div class="level5"> <p> <a href="/lib/exe/fetch.php?media=stash:depth:wheel_collide1.jpg" class="media" title="stash:depth:wheel_collide1.jpg"><img src="/lib/exe/fetch.php?w=300&tok=711607&media=stash:depth:wheel_collide1.jpg" class="mediaright" alt="" width="300" /></a> The body of the wheel is only one cylinder, there is no need to make shapes for all the small bars in the wheel. As this is the only body for this entity it collides with both the character and other entities, no need to have different bodies with different collider types. Also see how the purple marked models (the mount and bar attaching to the wheel) have no bodies at all, this because nothing is small enough to actually get in between the wheel and the wall it is mounted to. There is a joint for this entity, and the joint will make sure that the wheel is stuck in mid-air and can be rotated. <br/> <br/> <br/> <br/> <br/> <br/> <br/> </p> </div> <h5>Collider Examples - Shelf</h5> <div class="level5"> <p> <a href="/lib/exe/fetch.php?media=stash:depth:shelf_collide1.jpg" class="media" title="stash:depth:shelf_collide1.jpg"><img src="/lib/exe/fetch.php?w=300&tok=8d9d8c&media=stash:depth:shelf_collide1.jpg" class="mediaright" alt="" width="300" /></a>The body for the collision against other objects. The body is quite similar to the actual graphical object, mainly lacks the small differences. Depending on game and what type of other objects that exists, the sides could be changed to one single boxed shape instead of the current six box shapes. But if you have small objects like cans they could potentially collide in mid-air if cheating too much with the collision details.<br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> </p> <p> <a href="/lib/exe/fetch.php?media=stash:depth:shelf_collide2.jpg" class="media" title="stash:depth:shelf_collide2.jpg"><img src="/lib/exe/fetch.php?w=300&tok=e66047&media=stash:depth:shelf_collide2.jpg" class="mediaright" alt="" width="300" /></a>The box for colliding with the character. One single large box covering the whole model, this will make the character collision work faster and there is no risk of small weirds bumps and similar if the player walks against the model. <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> </p> </div> <h5>Collider Examples - Organic</h5> <div class="level5"> <p> <a href="/lib/exe/fetch.php?media=stash:depth:organic_collide1.jpg" class="media" title="stash:depth:organic_collide1.jpg"><img src="/lib/exe/fetch.php?w=300&tok=5abfba&media=stash:depth:organic_collide1.jpg" class="mediaright" alt="" width="300" /></a>Normally for something as small as a fish you only use one simple shape, as the entity is so small that you can't really tell how well it collides with other entities. But the fish gives a nice organic, complicated shape that is easy to show how to simplify. </p> <p> Using three capsules and one box you can create a very detailed collision model for the fish, it is likely even only two capsules would work just as well, but it would have to be tested and tweaked. All the parts of the model not covered by a shape is not a problem, because the outtermost points of the shapes will create areas inbetween them, where nothing is small enough to get into. Or it would be such a small part of the entity that it would be difficult to see on screen when moving if it clips into other entities on collision. <br/> <br/> <br/> <br/> <br/> <br/> <br/> </p> </div> <h2>Terrain</h2> <div class="level2"> </div> <h3>Settings</h3> <div class="level3"> <p> All maps shall have the following settings:<br/> unit size: 1 m<br/> geometry patch size: 16<br/> texture patch size: 16<br/> Max height map size to use is 1024×1024. Keep this lower if possible (but still make sure there is ample of room around the area of gameplay focus). </p> <p> The sizes of the blend textures are a blir more flexible. Having the default of texture size == heightmap size should be good enough, but it is okay to crank the size up to 2048×2048 for a SINGLE layer if more fine details are needed. This is also true for the diffuse color blend texture. </p> </div> <h2>Static Objects</h2> <div class="level2"> <p> Static objects make up the background of the game and are always immovable. The include things like walls, pillar, pipes, and more. </p> <p> The most important dimensions to learn in the game is the sizes of the different static objects. The reason that is so important is that it must be possible to use assets from several different sets together. By being able to to do this it is easy to piece together unique looking environments by combining objects from different sets. Another important aspects is that it is much easier to make generic entities and other set pieces that can easily fit together. </p> <p> So make sure to keep the directions given below as much as possible. There might be occasions when it is necessary to break, but do not do this without think about it and asking somebody else. </p> <p> The names that are given to the various objects are also important to keep the same, but it is necessary then it is of course possible to deivate from this standard as well. </p> </div> <h3>General</h3> <div class="level3"> <p> <b>Origo</b><br/> The Y-axis-origo of most static objects shall be at the lower part of the model. This so that it is easy to place them in the editor. However this is not optimal for all objects, for example ceiling welders. <br/> The X/Z-axis-origo depends a lot on what type of object. For walls, it should be at the front of the object where (from where the floor is visible), for pillars at the center, etc. The important thing is that the origo placement makes the object easy to rotate into place in the level editor.<br/> If unsure, try and figure what is the the default relative postion you want a certain object to be in compared to other objects, and put the origo there. Make sure to also ask another person for advice! This is a vital part as bad origos will make mapping more cumbersome and will probably end up wasting a lot of time. </p> <p> <b>Naming</b><br/> The models(.dae) should be organized in a folder structure as follows:<br/> ..<em>category/typeofobject/nameofobject.dae</em><br/> ..example: "station/wall/default.dae"<br/> </p> <p> If the texture(s) for pieces are shared with other types(i.e. ceiling, floor)they should be place in the graphic set’s root folder:<br/> ..<em>category/nameoftexture.dds</em><br/> ..example: "station/wall/default.dds"<br/> </p> <p> Or if they are specific for the type of object they should be placed in wall folder instead:<br/> ..<em>category/station/nameoftexture.dds</em><br/> ..example: "station/infirmary_base.dds"<br/> </p> </div> <h3>Walls</h3> <div class="level3"> </div> <h4>Default</h4> <div class="level4"> <p> <b>Dimensions:</b><br/> X: 4.0m Y: 4.0m Z: 0.0m-0.5m (or more)<br/> </p> <p> <b>Naming examples:</b><br/> default (can be used on the most generic type of wall, avoid using though!)<br/> default_window (default with a window)<br/> rock (material differnt)<br/> decayed01, decayed02 (two versions of a decayed wall)<br/> </p> <p> <b>Template image:</b><br/> <a href="/lib/exe/fetch.php?media=stash:depth:wall.gif" class="media" title="stash:depth:wall.gif"><img src="/lib/exe/fetch.php?w=200&tok=e324b2&media=stash:depth:wall.gif" class="media" alt="" width="200" /></a> </p> </div> <h4>Short</h4> <div class="level4"> <p> <b>Dimensions:</b><br/> X: 2.0m Y: 4.0m Z: 0.0m-0.5m (or more)<br/> </p> <p> <b>Naming examples:</b><br/> default_short (can be used on the most generic type of wall, avoid using though!)<br/> default_window_short (it has a window)<br/> rock_short (material different)<br/> decayed_short01, decayed_short02 (two versions of a decayed wall)<br/> </p> <p> <b>Template image:</b><br/> <a href="/lib/exe/fetch.php?media=stash:depth:wall_short.gif" class="media" title="stash:depth:wall_short.gif"><img src="/lib/exe/fetch.php?w=200&tok=07abfb&media=stash:depth:wall_short.gif" class="media" alt="" width="200" /></a> </p> </div> <h4>Welders</h4> <div class="level4"> <p> Since it is very hard (at times impossible) to two pieces of wall to seamlessly tile, it is almost always necessary to have an object between two wall pieces, in order to hide any seams. This object is called the welder. The welders can have a very varied ranged of looks, so the measurements here are very flexible. The only really important thing is that the welder is just as high as the wall. </p> <p> <b>Dimensions:</b><br/> X: 0.25 -0.5m Y: 4.0m Z: 0.25m-0.5m </p> <p> <b>Naming examples:</b><br/> welder_default (the most common welder)<br/> welder_stone (used to weld stone walls)<br/> welder_default_concave (to be positioned over corner seam, see right-most example image.)<br/> welder_default_convex (to be positioned over corner seam, see bottom example image.)<br/> </p> <p> <b>Template image:</b><br/> <a href="/lib/exe/fetch.php?media=stash:depth:welder.gif" class="media" title="stash:depth:welder.gif"><img src="/lib/exe/fetch.php?w=200&tok=6db7b0&media=stash:depth:welder.gif" class="media" alt="" width="200" /></a>' </p> <p> <b>Examples of welder usage</b><br/> <a href="/lib/exe/fetch.php?media=stash:depth:wall_wedger_examples.gif" class="media" title="stash:depth:wall_wedger_examples.gif"><img src="/lib/exe/fetch.php?w=200&tok=148c94&media=stash:depth:wall_wedger_examples.gif" class="media" alt="" width="200" /></a> </p> </div> <h4>Doorway</h4> <div class="level4"> <p> Door ways are holes in walls that are either meant to place a door entity (contain both frame and door) or a static doorframe (see below) in.<br/> For more discussion this see <a href="/doku.php?id=stash:depth:art_guidelines#measurements" class="wikilink2" title="stash:depth:art_guidelines" rel="nofollow">messurements above</a> </p> <p> <b>Dimensions:</b><br/> Outside: X: 4.0m Y: 4.0m Z: 0.05m-0.5m<br/> Hole <em>(<a href="/doku.php?id=stash:depth:art_guidelines#doorways" class="wikilink2" title="stash:depth:art_guidelines" rel="nofollow">realistic type</a>)</em>: X: 1.5m Y: 2.5m<br/> Hole <em>(<a href="/doku.php?id=stash:depth:art_guidelines#doorways" class="wikilink2" title="stash:depth:art_guidelines" rel="nofollow">fanastic type</a>)</em>: X: 1.75m Y: 2.75m </p> <p> <b>Dimensions (double):</b><br/> <em>(simply double with of above)</em><br/> </p> <p> <b>Naming examples:</b><br/> doorway_default (doorway for default wall type) doorway_default_double (double doorway for default wall type) </p> <p> <b>Template image:</b><br/> <a href="/lib/exe/fetch.php?media=stash:depth:doorway.gif" class="media" title="stash:depth:doorway.gif"><img src="/lib/exe/fetch.php?w=200&tok=89f388&media=stash:depth:doorway.gif" class="media" alt="" width="200" /></a> </p> </div> <h4>Doorframe</h4> <div class="level4"> <p> A piece that is a doorframe, the piece will be positioned in the hole in Doorways, so that it creates a nice frame for a hole when there is no door to fill it out. The dimensions are not exact as it depends on the look of the frame. </p> <p> When a doorframe is placed a door entity is NOT meant to be placed inside it! </p> <p> <b>Naming examples:</b><br/> doorframe_default (doorframe for default wall type)<br/> doorframe_stone_double (double doorway for stone wall)<br/> </p> <p> <b>Template image:</b><br/> <a href="/lib/exe/fetch.php?media=stash:depth:doorframe.gif" class="media" title="stash:depth:doorframe.gif"><img src="/lib/exe/fetch.php?w=200&tok=c7aee3&media=stash:depth:doorframe.gif" class="media" alt="" width="200" /></a> </p> </div> <h4>Notes</h4> <div class="level4"> <p> The above are just the most general types of walls and should serve as general guide for the kind of sizes that are needed. There are tons of other wall types that are possible. Here are some examples that have been used in the past: </p> <p> <b>corner_concave</b><br/> A special piece for round corners. </p> <p> <b>corner_convex</b><br/> Another special piece for round corners, but this timed beveled in the opposite direction. </p> <p> <b>doorway_arched</b><br/> The same as the doorway above, but with an arched top. The arched bit should start at (or close to) 3 meters. </p> <p> <b>doorframe_arched</b><br/> The arched version of the door way. </p> <p> <b>wall_extension</b><br/> Placed above walls in order to make the room higher. Normally these are 2 meters in y-size. </p> <p> The above are just examples so do not let this stop you from doing cylindric corridors, non-euclidean geometry or whatever madness your deranged mind can make up! <b>Wall extension</b><br/> </p> </div> <h3>Stairs</h3> <div class="level3"> </div> <h4>Default</h4> <div class="level4"> <p> A piece of stair that can be “tiled” endlessly to make as long of a stair as needed. If the model can’t be created to be “tile’able”, make one additional stair model (see stairs Long). Also see example below of how the stair models should be “tiled” and also how they use the welder. </p> <p> <b>Dimensions:</b><br/> Total: X: 4.0m Y: 2.0m Z: 4.0m<br/> Step height: ~0.25m<br/> Railing Height: About the same as "welder" (see below)<br/> Notes:<br/> </p> <ul> <li class="level1"> The actual model with steps, a bottom and railings on the side can be larger than the step measures. The bottom and rail could expand beyond the measures, as well as the railing go into the model. See measures in sketch.</li> <li class="level1"> It’s important that the steps are 4m wide(X) and that the Y distance is from the bottom of the first step to the top of the last step.</li> </ul> <p> <b>Naming Examples:</b> default (the default stairs for the set) metal (metallic stairs) </p> <p> <b>Template Image:</b><br/> <a href="/lib/exe/fetch.php?media=stash:depth:stairs_default.gif" class="media" title="stash:depth:stairs_default.gif"><img src="/lib/exe/fetch.php?w=200&tok=6de1cf&media=stash:depth:stairs_default.gif" class="media" alt="" width="200" /></a> </p> </div> <h4>Welder</h4> <div class="level4"> <p> These welders are to be used to give stairs a nice look at the beginning and end. They are also be used for making railings look good, see examples. If not possible to use the same welder for the railing as for the stair, make an additional welder for railings. </p> <p> Measurements are very much estimates, so feel free to change as see fit. </p> <p> Note: The model must be solid, as in all planes are modeled and textured. </p> <p> <b>Dimensions:</b><br/> X: 0.75m-1.25m Y: 1.5m-2.0m Z: 0.75m-1.25m </p> <p> <b>Naming examples:</b><br/> welder_default (for the default staircase) </p> <p> <b>Template image:</b><br/> <a href="/lib/exe/fetch.php?media=stash:depth:stairs_welder.gif" class="media" title="stash:depth:stairs_welder.gif"><img src="/lib/exe/fetch.php?w=200&tok=ce7410&media=stash:depth:stairs_welder.gif" class="media" alt="" width="200" /></a> </p> <p> <b>Examples of usage</b><br/> <a href="/lib/exe/fetch.php?media=stash:depth:stairs_welder_example.gif" class="media" title="stash:depth:stairs_welder_example.gif"><img src="/lib/exe/fetch.php?w=200&tok=b96850&media=stash:depth:stairs_welder_example.gif" class="media" alt="" width="200" /></a> </p> </div> <h4>Railing</h4> <div class="level4"> <p> A railing that can be used to create catwalk like Stairs, imagine a stair with a stair that leads up to another stair in the same room and that stair has the railings along the steep to the lower stair. </p> <p> This is not the railing that is part of the stairs! </p> <p> <b>Dimensions:</b><br/> X: 4.0m Y: 1.0m-1.25m Z: 0.25m-0.75m<br/> Note:<br/> The width(X) must always be 4, but the rest of the measures can be quite freely as long as it works well with the stair and static object set in general. </p> <p> <b>Naming examples:</b><br/> railing_default (railing used for the default staircase) </p> <p> <b>Template image:</b><br/> <a href="/lib/exe/fetch.php?media=stash:depth:stairs_railing.gif" class="media" title="stash:depth:stairs_railing.gif"><img src="/lib/exe/fetch.php?w=200&tok=c89f04&media=stash:depth:stairs_railing.gif" class="media" alt="" width="200" /></a> </p> </div> <h4>Long</h4> <div class="level4"> <p> Same as Stairs default, but does not need to be tileable and is only to be made if the default version is not tileable. </p> <p> <b>Dimensions:</b> Step: X: 4.0m Y: 4.0m Z: 8.0m<br/> Step height: ~0.25m<br/> Railing Height: About the same as 3- Stairs Railings<br/> Notes:<br/> </p> <ul> <li class="level1"> The actual model with steps, a bottom and railings on the side can be larger than the step measures. The bottom and rail could expand beyond the measures, as well as the railing go into the model. See measures in sketch.</li> <li class="level1"> It’s important that the steps are 4m wide(X) and that the Y distance is from the bottom of the first step to the top of the last step.</li> </ul> <p> <b>Naming examples:</b><br/> default_long (long version of the default staircase) </p> <p> <b>Template image:</b><br/> <a href="/lib/exe/fetch.php?media=stash:depth:stairs_long.gif" class="media" title="stash:depth:stairs_long.gif"><img src="/lib/exe/fetch.php?w=200&tok=0697c3&media=stash:depth:stairs_long.gif" class="media" alt="" width="200" /></a> </p> </div> <h3>Special</h3> <div class="level3"> <p> The special folder is only used for objects that are only meant to be used at very specifc places. Name these according tp the level where they are used. For example:<br/> "01_machine_room_giant_machine". </p> </div> <h3>Misc</h3> <div class="level3"> <p> There are lots of other categories that can be added as well. As always let your imagination be your limit, but do not try and be too specific, because that might make it too hard to find certain pieces. Examples of other previously used categories include: </p> <p> <b>floor</b><br/> Normally floor is made up textured planes but it might be necessary for more specific pieces at times. Place these here. </p> <p> <b>ceiling</b><br/> Like floor, ceiling is normally planes. Place specifics needed here. Often used for pieces that makes the ceiling arched and so on. </p> <p> <b>pipes</b><br/> You guessed it. Pipes and shit. </p> <p> And so on… </p> </div>