What Makes A Good Submission/The Models Resource

Model Formats

The two main model formats accepted by the site are Wavefront OBJ (.OBJ) and COLLADA (.DAE). Every model in the submission must be available in at least one of these two formats.

.OBJ Limitations

The .OBJ format is old and therefore limited in what it can do, but it has a smaller file size and is widely supported. The .OBJ format requires an external .MTL file to define materials, including which texture to use. These .MTL files are usually generated automatically by most programs when an .OBJ is exported. Be sure to include the .MTL file with your submission.

The .OBJ format does NOT support bones, animation, vertex colors, individual mesh axis points. You should consider using .DAE instead if your want to include any of these features, though you are welcome to still include the .OBJ as an additional option.

Additional Formats

Some other well-supported formats may be included as bonus formats so long as the required formats are also provided. The main allowed formats are .FBX and .SMD, though some others may be allowed as well. Proprietary formats such as Blender's .BLEND or 3DS Max's .MAX are not allowed, as they can only be opened by specific (and not always free) programs. The only exception to this rule is that the proprietary format files may be included for Custom/Edited models.

If you include .FBX models, do not use the option to include textures in the file. This greatly increases the model's file size and generates redundant texture files when the model is opened. We will remove or reject and FBX models using this option.

Raw game model asset files are not allowed under any circumstances.

Texture Formats

Typically, PNG is the only allowed texture format.

Converting Textures

If you need a tool to convert textures, we recommend using XnConvert or XnShell. When converting textures, you should never convert to Bitmap (.BMP) or JPEG (.JPG) formats. The .JPG format is lossy and will irreversibly damage the quality of the image. The .BMP format, while not lossy, does not support alpha transparency and may destroy transparency information.

In very rare situations, a game's files may be stored natively in .BMP or .JPG format. In these cases, it is okay to use these formats, though we recommend that you convert them to .PNG anyway.

Model Contents

Models are complex and have many different elements. Some of these elements are more important than others, and some elements are impossible to preserve when exporting to common formats.

Polygon Structure

The model's polygons must be intact. The model will not be accepted if it has obvious missing pieces or corruption. Don't manually modify the polygon structure unless you include the unedited version and clearly label the edited version as such. However, if the unedited version doesn't meet normal submission requirements, the whole submission will be rejected. Manually reposing a model qualifies as modifying the polygon structure.

Distortion

Models that are ripped from a 3D scene ripper may be distorted due to how such tools work. Models will not be accepted if the model is noticeably squashed, stretched, skewed, or otherwise distorted as a result of this ripping process.

Mirroring

If a model is mirrored, it will not be accepted. Pay close attention to how the model is ripped and exported, as certain bad export/import settings can cause models to become mirrored.

Poses

Models that are ripped from a 3D scene ripper are often in a pose from an animation rather than the default pose (often a T-Pose). Posed models like this are fine so long as the pose is fairly neutral. A character in an idle standing pose would be allowed, but a character in the middle of a punch attack would be rejected.

Merged Pieces

Models can sometimes have separate pieces are are located in the same exact location, especially if the model is completely flat. Certain optimization processes can cause these pieces to become inseparably merged together, or worse, overwrite each other. This can lead to things like a character's mouth being glued shut or flat models being shredded. Models with these problems will not be approved.

UV Maps

For models that have textures (most of them), textures are mapped to polygons using a system known as UV Mapping. All of a model's UV maps must be intact. Don't manually modify the UV maps unless you include the unedited version and clearly label the edited version as such. However, if the unedited version doesn't meet normal submission requirements, the whole submission will be rejected. If the unedited UV mapping is wrong and needs to be fixed, it means something is wrong with the tools you are using.

Multiple UVs

Some models may have more than one UV map per mesh. However, since not all programs support these, multiple UV maps should be divided up in a reversible manner. The easiest way to do this is to create a duplicate mesh for each additional UV map and assign one UV map per mesh, along with a duplicate material. In order for the split to be reversible, the meshes must have the exact same polygon structure. Otherwise, if you delete polygons or merge them with other objects, users will not be able to combine the UV maps back together. For the duplicate material, be sure to use the texture that is associated with the UV map, even if that texture isn't a color/diffuse texture. You are welcome to include the original, non-split version as well.

Tiling and Clamping

Some models are designed to be used with mirrored texture tiling, rather than default tiling. Other models use a feature known as "clamping", where the edge of the texture is smeared outwards instead of tiling. Preserving these settings is not required, as they are not always supported and do not actually affect the structure of the model.

It is possible to modify a model and textures in such a way that the tiling/clamping is preserved, but doing so requires a lot of knowledge of UV maps and perfect mathematical accuracy. Do not attempt this type of modification unless you have access to tools that will let you manipulate UV coordinates with numeric inputs. If you decide to modify the model in this way, we recommend that you also include the unedited version.

Bones / Joints / Rigging / Armature

Models with bones/joints, sometimes referred to as rigging or armature, must have all of their rigging data intact. If the rigging data is broken or corrupted, the bones may move the wrong points or may not affect the model at all. Any models with rigging problems will be rejected. Don't manually modify the rigging unless you include the unedited version and clearly label the edited version as such. However, if the unedited version doesn't meet normal submission requirements, the whole submission will be rejected.

Animation

Animations are nice to have but are not required, as it is often difficult to rip animations. If you include animations in a .DAE or .FBX model, make sure that the inclusion of this animation does not overwrite the default pose of the model. Animations may be included inside a .DAE/.FBX model, or as .SMD files. If there is a very large amount of animation data, it is recommended that a non-animated version be included for people that are unable to load such large animations.

Morphs

Some models may have morph shapes, which can transform a model's points into a new shape. Morphs are not required, as they can be difficult to rip. Also, since morphs in .DAE is not widely supported, a .FBX must be used instead.

Vertex Colors

Some models, especially older ones, can have colors assigned to each vertex. Such vertex coloration can either be used to simulate lighting, or it can be used to entirely define the model's coloration. Vertex colors are not normally required unless they are vital to the model's design, as they can be difficult to rip and export.

If the model's coloring involves a single color, you can create a simple little texture for that color. If the model is being ripped from a scene ripper, try to get the model's true color as best as possible. Don't use a color from where the model is shaded or highlighted.

If you include custom vertex colors, clearly label them as such.

Baking

One method of preserving vertex coloration in a widely-supported format is to bake the colors into a texture. If you have access to complex vertex shading data, we recommend that you include a version of the model with baked colors. The baked texture should have a high-enough resolution that no seams are visible. Having a baked version is not required for most models but may be required if the model entirely relies on it.

If the model uses both vertex colors and textures, consider baking the colors as a separate additional UV map so that the base texture mapping is not disturbed. (See the section on Multiple UVs.)

Normals / Smoothing

Models can have custom normals, which define the direction that the polygon is "facing". This data also allows polygons to appear smooth in ways different than how the model would be rendered with default shading. Preserving this data isn't required, as it is not always possible to rip. However, if the model appears entirely blocky, this may be a sign that polygons are not properly connected together.

Model Position

Typically, models are located in the center of the model's world (defined by the world axis), facing "forward", and "upright" according to the up axis. Character models are also typically positioned so that they are above the "floor plane" of the world. Models can also be positioned with their center at the world axis point, character or otherwise.

Scene Rips

Models ripped with a scene ripper are rarely located in the center of the scene. These models should be moved to the center of the scene as described above.

Direct Model Exports

Models exported directly from game files do not always follow the "rules" of positioning models, and this is fine. A good example of this is level pieces, which may have pieces positioned in specific locations to match up with the structure other level geometry. Do not reposition models ripped in this manner.

Overlapping Pieces

Model sometimes have different pieces that overlap each other. A knight model may have two versions of the head, one with a helmet and one without. That knight may also have the sword and shield both located at the axis center, overlapping with each other and the feet. This is fine.

It may be tempting to move the pieces to new locations, to tidy up the model, but don't do that. Relocating the pieces actually makes it harder to use the model, especially when using .OBJ models, which will erase the pieces' axis points. Even if it looks ugly, don't move them. Models that have been modified like this will be rejected.

Orientation

Different programs can define the model's world differently, so as long as the model is properly aligned to one of the six major axes, it's fine. Models ripped by scene rippers are usually at arbitrary angles, so try to get them as close to properly aligned as possible.

Materials / Shaders

Materials and Shaders can have a lot of different features, some of which are custom-built for a certain game's engine. Most of these are not supported by common model formats, and the features that are supported can often be interpreted in different ways. Two different programs could read the same specular highlight settings in two different ways. Because of this, there is no reason to try and recreate the exact appearance of the materials as it looks in the game. The only part of the material that matters is the main color texture. Even if the texture isn't used as a color/diffuse/albedo map, it should be assigned to the material as if it were. If a model has multiple UV maps that you've split, use the texture that corresponds to correct UV map.

Texture Paths

Textures are loaded using a file path, which the program then follows to load the texture. There are two types of texture paths: relative and absolute. All models should use relative texture paths, which say where the file is located in relation to the model itself. For example, "body.png" and "textures/body.png" are both relative paths. By contrast, absolute texture paths like "C:\Users\Owner\Desktop\Models\body.png" give the entire exact path on your computer. Nobody else can use these paths because nobody else will have the same folder structure as you, so nobody else will be able to load textures correctly. Check your export settings and ensure that relative texture paths are being used.

Also, do not rename textures after you have exported the model. The model's texture paths are set at the moment the model is exported. If you change the name of a texture afterwards, the model will look for the old file name. The same applies to converting models. If you want to convert textures or rename files, do so before you export the model. If you change the texture names and we cannot easily see how to fix the problem, the submission will be rejected.

Fixing Texture Paths

Both .MTL and .DAE files are written in plain text, which means they can be viewed with any text editor. If you aren't sure if your texture paths are broken, or if you know they are broken, simply use a text editor of your choice and open the .MTL file or .DAE file to find the texture paths.

For an .OBJ model's .MTL file, texture paths are defined for each material using lines such as "map_Kd" followed by the file name. Different lines represent different parts of the material, such as specular map, but they should all be fixed.

For a .DAE model, texture paths are defined inside the "library_images" node, inside "init_from" nodes. If the "library_images" section is empty or missing altogether, it means your export did not define any textures at all and needs to be re-exported with the correct settings.

Textures

All of a model's textures should be included. At the very least, models ripped with a scene viewer should have all of the textures applied to the model at that moment. For models exported directly from files, include all of the files. Be aware that model may have more than just basic color textures. Other possible textures include normal maps, specular maps, and environment reflections. Any submission that is obviously missing such textures will be rejected.

Don't manually modify the textures unless you include the unedited version and clearly label the edited version as such. However, if the unedited version doesn't meet normal submission requirements, the whole submission will be rejected. The only type of texture manipulation that does not fall under this restriction is channel splitting.

Channel Splitting

Some modern game developers save space by combining multiple monochrome images into one image by assigning each map to a different RGBA channel. People usually can't use combined textures in their original format, so it's a good idea to split them with tools like Photoshop or Texture Remix. If you are unsure of whether or not the texture should be split, leave it alone and we'll take care of it. However, if you do know that the texture should be split, splitting it yourself will help speed up the submission process. It is not necessary to include the raw, unsplit texture if you include the split images.

Scene Rip Clutter

If you use a 3D scene ripper, make sure that the resulting model includes only the models belonging to what you want to submit. If you rip a character model, don't include random bits of grass or dust particles from the scene. If you rip a level model, don't include characters, HUD elements, particles, or other elements that are clearly not part of the level.

Lights, Camera, Junk

The .DAE model format supports Light and Camera objects. However, these are rarely part of ripped models. Be careful if you use your model file to create your icons, as this can lead to these junk objects being included in your scene. Make sure you remove these objects from your scene before exporting. We won't reject a model for including these, but it makes models harder for people to use and takes extra time for us to remove them.

Icons

All model submissions require two icons rather than the usual one: a small icon for the browse pages and a big icon for the model's own page. Icons should be rendered at the required size, not scaled up. All icons should be rendered with transparent backgrounds. We recommend that you don't use photo editors to remove non-transparent backgrounds from screen captures, as this usually leaves behind ugly outlines on the models.

Lighting in the icons should be good enough to see the model and its intended appearance. Icons with overly dark or overly bright lighting must be replaced. Flat lighting may be allowed unless it makes the model difficult to distinguish. If you are unsure of how to create good lighting, try studying three-point lighting.

We won't reject a submission if the icons are bad or missing, but models with good icons will be given preference over models without them.

Small Icon

The small icon must be 148 x 125 pixels. The main purpose of this icon is to clearly identify the subject. For characters, this could be a closeup of the face or bust. For location maps, this could be a view of the location's most distinct or well-known feature. You may use extra lighting or material effects to better capture the nature of the model, such as adding reflections to metal or mimicking the game's use of fog. Even with the added effects, the model must be clearly recognizable and should not depict any model assets that are not included in the ZIP.

Big Icon

The big icon must be 750 x 650 pixels. The main purpose of this icon is to give the user a good idea of what the ZIP includes when the user opens it up. For characters and items, show the whole model. For location maps, show as much of the map as you can while still keeping the important part of the map recognizable. Don't use any added colors, shader effects, or fancy lighting.

If there are multiple different models included in the ZIP, show all of the most important ones. If a model has multiple overlapping parts, you may reposition them so that they can be clearly viewed.

Official Render Icons

Sometimes, game developers will provide official renders of models. These renders may be used as the small icon if the model depicted in the render is definitely the one included in the ZIP. However, be aware that many official renders are made using higher quality models than what are actually included in the game. These renders will not be allowed, as they mislead users about the quality of the model.

Using official artwork that is clearly hand-drawn is not allowed at all, no matter where the artwork comes from.

Customs

Custom models should follow all of the general model guidelines regarding format, positioning, and textures, and so on. If you are editing a model that was ripped by someone else, we recommend that you include a file giving credit to the original ripper.

Subject

Customs may be submitted for any game series or media franchise that has at least one official video game associated with it. Models may be of any official character, object, location, etc. from the series. Fan-made characters, fan-made settings, and fan-made redesigns are not allowed.

Re-Textures and Minor Edits

Re-textures and minor edits of character models are allowed so long as they meet the subject requirements above. These models will be expected to have a higher level of quality than entirely custom models due to how easy it can be to create them.

Material Colors

Models can be created with each material using a solid color rather than a texture. This is a fine way of designing a model, but there is a usability issue with this. Not all programs can load material colors, and not all programs export material colors correctly. Those people who can't load the colors correctly won't be able to see your model as you intended. Because of this problem, we recommend that you create simple little solid color textures for each color you want to use and apply them to the model. You don't need to change the UV maps or anything, since the texture is all one color. Doing this will ensure that everybody can use your model the same way. We would do this for you if we could, but since we can't guarantee that the colors are being exported or imported correctly, we don't want to risk messing up the colors.