The VG Resource Wiki - User contributions [en]

What Makes A Good Submission/The Models Resource

2023-01-28T19:16:26Z

Peardian: /* Multiple UVs */

[[File:TMR-Logo.png|right|link=]]
==Model Formats==
The two main model formats accepted by the site are [[OBJ|Wavefront OBJ (.OBJ)]] and [[DAE|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 [https://www.xnview.com/en/xnconvert/ XnConvert] or [https://www.xnview.com/en/xnshell/ 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==
[[File:Icon Example - Models.png|center]]
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.

{{GoodSubNav}}

DAE

2021-07-30T02:38:44Z

Peardian: Added description of DAE format

'''''COLLADA DAE''''' (.dae) is a popular common model format. Because it can support model rigging, it is ideal for sharing rigged character models. Because it uses [https://www.w3schools.com/xml/ XML], a model's format can be viewed with any text editor, and the structure can be validated by comparing it with the official COLLADA DAE schema. The two most common versions of the DAE schema are 1.4 and 1.5.

DAE is one of the two preferred model formats on [[The Models Resource]].

== Limitations ==
Because of its XML structure, DAE models tend to have higher file sizes than other formats. Also, while not strictly a limitation of the format itself, some modeling programs use either loose or outdated interpretations of the schema when handling DAE models. This leads to models that seem to work fine for the original exporter but not in other programs.

== Structure ==
Data is divided up into several "library" nodes and can be found in any sequence under the root node.

=== asset ===
The ''asset'' node contains various data about when the file was created, who created it, and which axis is up. This section is can usually be ignored.

=== library_images ===
The ''library_images'' node defines the texture paths for all images used by the model's materials. See [[#Texture Paths|the Texture Paths section]] for details on how to fix problems with these paths. If this section is empty or missing, it means the model will not load any textures at all and needs to be re-exported.

=== library_effects ===
The ''library_effects'' node defines properties for all of the model's materials, such as which colors and images to use. This section is important but is too complex to be manually fixed, so re-exporting is usually recommended.

=== library_materials ===
The ''library_materials'' node defines all of the material names. This section is important but doesn't usually have any problems.

=== library_lights ===
The ''library_lights'' node defines all of the light objects. If this node exists, it usually means that the scene was not cleaned before being exported. This section can be deleted if all of the light nodes in the scene are also removed.

=== library_cameras ===
The ''library_cameras'' node defines all of the camera objects. Like with lights, if this node exists, it usually means that the scene was not cleaned before being exported. This section can be deleted if all of the camera nodes in the scene are also removed.

=== library_geometries ===
The ''library_geometries'' node defines all of the model's meshes and their polygons. This is the largest section, containing all vertex points, UV coordinates, and sometimes even colors. It is possible to identify meshes with more than one UV map by looking for an input node with the ''semantic'' value "TEXCOORD" and a ''set'' value greater than zero. Editing this section is not recommended due to its complexity.

=== library_controllers ===
The ''library_controllers'' node defines all of the model's joints and rigging. Problems with joint binding can be found here, but editing this section is not recommended due to its complexity.

=== library_visual_scenes ===
The ''library_visual_scenes'' node defines the scene hierarchy, such as where each mesh is located and how it is oriented. The visual scene's nodes tie together materials and geometries defined in the other sections. Some model programs have been known to inappropriately use the same ID for both the scene itself and a node within the scene, resulting in problems when loaded to other programs.

=== scene ===
The ''scene'' node defines the scene being loaded. There is usually just one scene. This section can usually be ignored unless the ID of the scene node is being edited.

== Common Problems ==
=== Wrong Format ===
As mentioned above, not all programs strictly adhere to the COLLADA DAE schema when creating models. This can lead to models loading with empty or broken materials, misplaced parts, or broken [[UV Map|UVs]]. In the worst cases, the model will simply fail to load at all or crash the program. Users with knowledge of XML can attempt to fix these issues by validating the structure against the schema and correcting the errors it highlights.

=== Texture Paths ===
Some modeling software will use absolute file paths when defining the name of the texture. This will cause the textures to fail to load when the model is imported if the user does not have the exact same folder structure as the one defined in the model file. For the textures to be able to load properly, the file path should point to the texture's location relative to the model file.

Because DAE uses XML, it is possible to fix the issue using any text editor, such as Notepad or Notepad++, even if the user is not familiar with XML. Texture definitions are stored under the ''library_images'' node, which is usually located at the top of the file. Inside it is a series of ''image'' nodes, one for each texture being used, and inside each of those is a ''init_from'' node. The user simply has to change any absolute file paths to relative paths.

'''Before:'''
<init_from>
<ref>C:\Users\Owner\Desktop\King Dedede\FitDedede_Hammer.png</ref>
</init_from>

'''After:'''
<init_from>
<ref>FitDedede_Hammer.png</ref>
</init_from>

''Note: Not all DAEs will use the exact structure given in this example, but it should still be obvious as to where the path is.''

{{Model Formats}}
[[Category:File Formats]]
[[Category:Model Formats]]

What Makes A Good Submission/The Models Resource

2021-07-30T01:35:43Z

Peardian: Added links to model format pages

[[File:TMR-Logo.png|right|link=]]
==Model Formats==
The two main model formats accepted by the site are [[OBJ|Wavefront OBJ (.OBJ)]] and [[DAE|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 [https://www.xnview.com/en/xnconvert/ XnConvert] or [https://www.xnview.com/en/xnshell/ 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. 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==
[[File:Icon Example - Models.png|center]]
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.

{{GoodSubNav}}

What Makes A Good Submission/The Models Resource

2021-07-03T00:09:11Z

Peardian: /* Morphs */ It seems DAE technically does support morphs, but it is not well supported

[[File:TMR-Logo.png|right|link=]]
==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 [https://www.xnview.com/en/xnconvert/ XnConvert] or [https://www.xnview.com/en/xnshell/ 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. 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==
[[File:Icon Example - Models.png|center]]
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.

{{GoodSubNav}}

What Makes A Good Submission/The Models Resource

2020-09-06T05:01:15Z

Peardian: New version

[[File:TMR-Logo.png|right|link=]]
==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 [https://www.xnview.com/en/xnconvert/ XnConvert] or [https://www.xnview.com/en/xnshell/ 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. 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 .DAE does not support morphs, 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==
[[File:Icon Example - Models.png|center]]
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.

{{GoodSubNav}}

Texture Types

2014-08-31T21:44:39Z

Peardian: Adding basic information so that this page isn't completely useless. Also added a notice. Is there no template for WIP pages?

This page describes the various types of textures, how to identify them, and how they are used in materials and shaders.

For basic information on using materials, see [[Texture Basics]]. For tips on how to create the kinds of textures described here, see [[Creating Textures]].

'''Note: This page is currently under construction. Until it is finished, some sections may be missing detailed descriptions or examples.'''

== Color / Diffuse Map ==
''Color'' maps (also referred to as ''diffuse'' maps) are the main textures on a model, and display the material's base colors. In default lighting, the color seen in the texture is exactly the color seen on the model where light is shining on it. For many games, especially older ones, some models may only have a single texture, putting all of the material's detail into the color map.

For materials with advanced shaders, such as those that include both [[#Specular Map|specular]] and [[#Normal Map|normal maps]], the color map is used for the base colors of the material without any shading, highlights, or other effects. Variations in the color and other features, such as scratches or stains, are also included. Even in modern games, it is not unusual for these maps to involve large patches of solid color.

Depending on the art style or technology of the game, color maps can have attributes of other texture types "baked" into the image. Shadows, highlights, and ambient occlusion can be included in the texture to accentuate features of the model or to achieve a stylistic effect not possible on the game's engine. This is heavily used in games which rely on flat lighting.

== Alpha / Transparency ==
Alpha maps are grey-scale images that define which parts of the texture can be seen through. Generally, white is fully opaque (can't see through) and black is fully transparent, with everything in between being partially transparent to some degree. While alpha maps are usually built into textures, can usually give the option to specify a separate texture to act as the alpha channel.

This is how transparency maps for [[Nintendo 64]] models are ripped, as tools for ripping from that system tend to use [[BMP]] as their image format, which lacks alpha support.

== Specular Map ==
Specular maps define the color and brightness of the highlights on a model. They are often grey-scale, but can use color.

=== Phong Exponent Map ===
Exponent maps are grey-scale images that define the size and sharpness of the highlight on a model. It is very rarely used. Only advanced rendering engines, such as Valve's [[Source Engine]] support this feature.

== Reflection Map ==
Reflection maps define the color and brightness of reflections on a model. This is not to be confused with [[#Specular Map|specular maps]], though they are generally very similar and are sometimes use a single texture.

== Environment ==
Environment maps (sometimes incorrectly referred to as Reflection maps) are textures that define what the reflections of a model should look like so that actual reflections do not have to be calculated. They can also be used to imitate specular highlights that are more complex than what the game engine allows, and are often masked by Specular or Reflection maps.

=== Sphere Maps / Probes ===
Sphere maps usually look like a picture of shiny ball or have a generally circular appearance to them, though this is not always the case. They are usually used to define how the reflections look to the camera regardless of the camera's orientation.

=== Panoramas ===
Panoramic environments are rectangular and define an environment for every possible angle in a 3D space. It uses a spherical projection map, like what is used for maps of the Earth, which means that the top and bottom of the image are stretched out compared to the center. Because of this, the areas above and below the model will have a higher resolution than those along the horizon. Game engines typically do not use this, as they are not as effective as the other two available methods. Because of their layout, however, they can be applied to a sphere model.

=== Cube Maps / Sky Boxes ===
Cube Maps (sometimes referred to as Sky Boxes) are made of six images (or a single image with six segments) that are mapped to a perfect cube to define reflections of a 3D space. Different game engines have different preferences for required structure of the cube map image(s). Because of their layout, these texture(s) can be applied to a cube model.

== Normal Map ==
Normal maps (sometimes incorrectly referred to as bump maps) define the surface angle of a model. This is used to add extra detail to the model without needing to use more polygons. For typical normal maps, his is done by mapping horizontal angle changes to the Red channel of the image and vertical angles to the green channel. The blue channel is left at full strength, which gives normal maps their characteristic blue color.

=== Global Normal Maps ===
A rare type of normal map defines surface angles in full 3D. It does this by mapping each axis to one of the color channels. These images usually feature a full rainbow of colors.

=== Compressed Maps ===
Because normal maps only need two channels, game engines usually compress them in some way to save space. Some games will convert the image to a grey-scale image with alpha, where horizontal angles are mapped to the color and vertical angles are mapped to the alpha. More advanced game engines allow two normal maps to be combined into a single image. The Red and Green channels are used for the first map, and the Blue and Alpha channels are used for the second. If no second normal map is used, the image will simply look yellowish with bits of red and green.

== Bump Map ==
Bump maps, like normal maps, define extra detail on the model without need polygons. Unlike normal maps, however, they achieve this by defining the relative "height" of the a surface feature. The engine then calculates surface details based on the changes in height. Games rarely use this due to normal maps allowing greater control over surface definition.

=== Displacement Map ===
Displacement maps allow models to add extra polygons to a model based on a texture. These are basically the same as bump maps, though some engines give the option of specifying the axis of the displacement by use of the RGB channels of the image.

== Luminance / Incandescence / Emission / Glow Map ==
Luminance maps define which parts of the texture emit their own light. The image defined in the luminance texture will be added to the models' color regardless of lighting and shadows. The only exception is when occlusion maps are used, which can reduce the effect. They are usually black with areas of bright color.

== Occlusion Map ==
Occlusion maps define the shadows created by ambient lighting from all directions. Advanced rendering engines can use this as a way to darken the model's color, highlights, and other effects all at once. They can also be used to accentuate extra model details added by normal maps. Because game models often reuse parts of a texture, a second UV map is usually needed to create an accurate occlusion map. They are usually mostly white with areas of grey.

== Light Map ==
Light maps record lighting information on a model. The image is then multiplied over the model's color to recreate the lighting condition. They are typically used for environment models to create realistic lighting without needing to calculate things like realistic shadows and environmental lighting in real-time. Because environment models tend to repeat textures, a second UV map is required. Each polygon needs its own space on the texture, so light maps for complex environments can get rather large. At the same time, only a small amount of pixels is usually needed for smaller surfaces, so the texture usually ends up looking like a big noisy mess of small colored squares.

== Combined and Compressed Maps ==
Game engines always have to contend with the issue of loading textures as fast as possible. The more detailed the model, the bigger the resources that must be loaded. Because of this, game engines usually have methods for reducing the file size and amount of textures required to load. A common way this is achieved is by combining multiple separate texture maps (not counting color) into a single image. Four grey-scale images can be fit into a single RGBA file. A common example of this is putting the Reflection map as the alpha channel of the specular map, reflection maps are usually grey-scale anyway and neither map allows for transparency. The game ''[[DC Universe Online]]'' takes this a step further by putting the specular map as the Red channel, the reflection map as the Green channel, and a luminance mask as the Blue channel. The result is a strange and colorful image that seems to serve no apparent purpose as a whole. Other methods include putting masks as the alpha channel of a normal map (like in ''[[Team Fortress 2]]'') or reducing a grey-scale map to a single image channel (like the green normal maps in the Doctor Who adventure games).

== Masks ==
Several of the texture types described above can be classified as ''masks''. A mask is simply a texture that, in some way, controls an effect used by the rendering image to display a model. While there can be any number of possible ways to use these masks, they all behave the same way: the brighter the color of the pixel, the stronger the effect is for that particular pixel.

For example, the game ''[[Super Mario Sunshine]]'' uses large masks to control and record the placement of the pollution in levels, dynamically drawing and erasing it as the goop is cleaned up or spread around. In ''[[The Legend of Zelda: Skyward Sword]]'', the way the villain Ghirahim's cape dissolves into diamond shapes is controlled by a mask where the brightness of the pixel determines how long in the animation sequence the pixel lasts before disappearing.

Texture Types

2014-08-28T04:49:29Z

Peardian: very WIP

.3ds

2014-08-18T23:05:45Z

Peardian: redirect

#REDIRECT [[3DS (model format)]]

.wrl

2014-08-18T23:05:09Z

Peardian: redirect

#REDIRECT [[VRML]]

WRL

2014-08-18T22:58:30Z

Peardian: redirect

#REDIRECT [[VRML]]

.fbx

2014-08-18T22:57:53Z

Peardian: redirect

#REDIRECT [[FBX]]

.dae

2014-08-18T22:57:24Z

Peardian: redirect

#REDIRECT [[DAE]]

.mtl

2014-08-18T22:53:03Z

Peardian: oop

#REDIRECT [[OBJ#MTL File]]

.mtl

2014-08-18T22:50:14Z

Peardian: redirect

#REDIRECT [[MTL]]

.obj

2014-08-18T22:49:09Z

Peardian: redirect

#REDIRECT [[OBJ]]

VRML

2014-08-17T04:56:56Z

Peardian: Created page with "'''''VRML''''' (.wrl) is an old model format notable for supporting vertex coloring. It does not support rigging, so it is not suitable for character models. It is the pri..."

'''''VRML''''' (.wrl) is an old model format notable for supporting [[vertex coloring]]. It does not support rigging, so it is not suitable for character models. It is the primary format used by several [[Nintendo 64]] model rippers.

VRML is '''not''' one of the acceptable model formats on [[The Models Resource]].

{{Modeling Format}}

3DS (model format)

2014-08-17T04:51:02Z

Peardian: disclaimer

'''''3DS''''' (.3ds) is an old model format originally developed for the DOS version of 3DS Max. It is very limited, which makes it unsuitable for sharing models. It is the only model format exported by [[bmdview2]], so is usually involved in the ripping process for several of Nintendo's [[GameCube]] games. This format has no association with the [[Nintendo 3DS]].

3DS is '''not''' one of the acceptable model formats for [[The Models Resource]].

== Limitations ==
This is a list of the limitations with the 3DS format, and also why they are not acceptable as model submissions.

* Only supports triangular polygons
* Texture names can only be eight characters long (not counting the file extension)
* Cannot have more than 65536 polygons and vertices.
* Does not support vertex normals, only smoothing groups
* Objects limited to 10 characters in the name, material names limited to 16 characters

{{Model Formats}}

3DS (model format)

2014-08-17T04:49:41Z

Peardian: Created page with "'''''3DS''''' (.3ds) is an old model format originally developed for the DOS version of 3DS Max. It is very limited, which makes it unsuitable for sharing models. It is the on..."

'''''3DS''''' (.3ds) is an old model format originally developed for the DOS version of 3DS Max. It is very limited, which makes it unsuitable for sharing models. It is the only model format exported by [[bmdview2]], so is usually involved in the ripping process for several of Nintendo's [[GameCube]] games.

3DS is '''not''' one of the acceptable model formats for [[The Models Resource]].

== Limitations ==
This is a list of the limitations with the 3DS format, and also why they are not acceptable as model submissions.

* Only supports triangular polygons
* Texture names can only be eight characters long (not counting the file extension)
* Cannot have more than 65536 polygons and vertices.
* Does not support vertex normals, only smoothing groups
* Objects limited to 10 characters in the name, material names limited to 16 characters

{{Model Formats}}

FBX

2014-08-17T04:37:37Z

Peardian: Created page with "'''''FBX''''' (.fbx) is a model format designed for animated models. It supports both model rigging and animation, as well as the ability to store textures within the model fi..."

'''''FBX''''' (.fbx) is a model format designed for animated models. It supports both model rigging and animation, as well as the ability to store textures within the model file itself.

FBX is an acceptable supplementary format on [[The Models Resource]]. [[DAE]] is preferred to FBX due to its wider support and plain text format.

== Limitations ==
Because FBX is a binary file format, flaws in the model such as texture paths cannot be manually corrected or easily diagnosed if the model fails to load.

== Precautions ==
It is easy for a FBX model to have a large file size if extra data is included. FBX models can store one or more animations, as well as all of the textures used by the included scene. If the model is not meant to be animated and the textures are already packaged with the model externally, this will lead to a lot of wasted space. To prevent this from happening, users should pay attention to the export settings when using FBX.

{{Model Formats}}

DAE

2014-08-17T04:23:54Z

Peardian: Created page with "'''''COLLADA DAE''''' (.dae) is a popular common model format. Because it can support model rigging, it is ideal for sharing rigged character models. Because it uses XML, a mo..."

'''''COLLADA DAE''''' (.dae) is a popular common model format. Because it can support model rigging, it is ideal for sharing rigged character models. Because it uses XML, a model's format can be viewed with any text editor, and the structure can be validated by comparing it with the official COLLADA DAE schema. The two most common versions of the DAE schema are 1.4 and 1.5.

DAE is one of the two preferred model formats on [[The Models Resource]].

== Limitations ==
Because of its XML structure, DAE models tend to have higher file sizes than other formats. Also, while not strictly a limitation of the format itself, some modeling programs use either loose or outdated interpretations of the schema when handling DAE models. This leads to models that seem to work fine for the original exporter but not in other programs.

== Common Problems ==
=== Wrong Format ===
As mentioned above, not all programs strictly adhere to the COLLADA DAE schema when creating models. This can lead to models loading with empty or broken materials, misplaced parts, or broken [[UV Map|UVs]]. In the worst cases, the model will simply fail to load at all or crash the program. Users with knowledge of XML can attempt to fix these issues by validating the structure against the schema and correcting the errors it highlights.

=== Texture Paths ===
Some modeling software will use absolute file paths when defining the name of the texture. This will cause the textures to fail to load when the model is imported if the user does not have the exact same folder structure as the one defined in the model file. For the textures to be able to load properly, the file path should point to the texture's location relative to the model file.

Because DAE uses XML, it is possible to fix the issue using any text editor, such as Notepad or Notepad++, even if the user is not familiar with XML. Texture definitions are stored under the ''library_images'' node, which is usually located at the top of the file. Inside it is a series of ''image'' nodes, one for each texture being used, and inside each of those is a ''init_from'' node. The user simply has to change any absolute file paths to relative paths.

'''Before:'''
<init_from>
<ref>C:\Users\Owner\Desktop\King Dedede\FitDedede_Hammer.png</ref>
</init_from>

'''After:'''
<init_from>
<ref>FitDedede_Hammer.png</ref>
</init_from>

''Note: Not all DAEs will use the exact structure given in this example, but it should still be obvious as to where the path is.''

{{Model Formats}}

MTL

2014-08-17T04:00:24Z

Peardian: redirects to OBJ page

#REDIRECT [[OBJ#MTL File]]

OBJ

2014-08-17T03:59:00Z

Peardian: template doesn't exist yet but still

Wavefront's '''''OBJ''''' (.obj) is a very common 3D model format and one of the oldest still in use today. It does not support rigging, and materials are defined in an external '''MTL''' file, but it is stored as plain text and maintains a relatively low file size. Because of this, OBJ models are good for sharing simple objects across modeling platforms.

OBJ is one of the two preferred model formats on [[The Models Resource]]. ''Please note that OBJ submissions with MTL files will not be accepted.''

== Limitations ==
OBJ models do not support model rigging. Any model exported to the OBJ format will lose its rigging information and not have any bones included (unless converted into meshes by the exporter).

Material definitions are handled by an external MTL file, though the materials' names are defined within the OBJ file.

== MTL File ==
Material definitions for the model, including the material's color, specular shine, and textures used, are handled by an external MTL (.mtl) file. Like the OBJ format, it is stored as plain text and is easily human readable. The name of the desired MTL file is specified by the OBJ itself, though usually it is safe to assume the name matches that of the model. Be aware that not all programs will be able to load MTL files correctly if the name includes a space.

Without a MTL file, OBJ models will load with blank materials, requiring the user to have to manually re-texture the model. Depending on what the model is being used for, this may not be possible for the user, making the model unusable.

=== Texture Paths ===
The most common problem with OBJ files is having improper texture path names in the MTL file. Some modeling software will use absolute file paths when defining the name of the texture. This will cause the textures to fail to load when the model is imported. The reason for this, and the reason why it can be hard to catch, is that the textures will import fine only on the computer where the OBJ was created. (Or, if you want to get technical, on any computer with the exact same folder setup.) For the model to properly be able to import textures, the file path should be a relative path from the MTL file's location.

Because the format is stored as plain text, it is possible to fix texture path problems using any text editor (such as Notepad or Notepad++) without having to re-export the model. Texture paths are stored on lines marked with ''"map_Kd"'' (complex materials can have other textures defined with similar labels) followed by the path. If the material is located in the same directory as the model, the texture path should be changed to leave only the name of the texture and its file extension. Please note that not all programs will correctly load textures with spaces in the file name.

'''Before:'''
map_Kd C:\Users\Owner\Desktop\King Dedede\FitDedede_Hammer.png

'''After:'''
map_Kd FitDedede_Hammer.png

{{Model Formats}}

OBJ

2014-08-17T03:58:19Z

Peardian: Created page with "Wavefront's '''''OBJ''''' (.obj) is a very common 3D model format and one of the oldest still in use today. It does not support rigging, and materials are defined in an extern..."

Cinema 4D

2014-08-15T02:30:09Z

Peardian: category

[[File:C4DLogo.png|thumbnail|right|Logo]] '''Cinema 4D''' (aka C4D) is a professional 3D modeling and animation software developed by Maxon. It is capable of importing various, pre-existing 3D models, including game models.

== Basics ==
One of the features that sets Cinema 4D apart from other 3D modeling programs is its easy-to-use interface. Camera controls are available in the top right corner of every model view port and can be used at any time, regardless of the currently selected tool. Most actions can be achieved through drag-and-drop or simply dragging. For example, materials can be applied to a mesh by dragging it from the Material list to the model. Textures can be imported into the scene by dragging them directly from the folder on your computer onto the model or Material.

For actions that use the mouse to control an object or input field (such as moving a model or using a value slider), the cursor's current position will not be changed while the action is being performed. This means that the mouse can be moved freely without you having to worry about hitting the edge of the screen. This can take some getting used to.

Cinema 4D's native file format is ".c4d" and is used for saving entire scenes for future use. This format is ''not'' acceptable for model submissions, as Cinema 4D is the only program that can open this type of file.

=== Interface ===
In the default layout, the section in the upper right-hand corner displays a list of the entire contents of the scene and is called the Objects panel. This is how you manage the models, lights, and cameras that make up the scene. The two small gray dots next to every object controls whether the model will appear in the editor (top dot) and in renders (bottom dot). Clicking them toggles between default, on, and off.

The panel in the bottom-right corner displays information about the current object or tool. This includes things like a model's coordinates, tool settings, and material properties.

[[File:MatExample1.png|thumbnail|center|Each material is assigned to a particular part of the model]]
The wide panel below the model view port is the material list. Clicking the material will bring up its information in the info panel. Double-clicking the material will bring up this same info in a new window. Materials can be assigned to models in the scene by dragging them from this panel to the mesh in the view port, or by dragging them to the mesh's name in the Objects panel.

The entire layout of Cinema 4D can be rearranged and customized, and these custom layouts can be saved for later use. Drop-down menus can be separated into small pop-up windows by clicking the dotted area of the menu. Layouts can be selected from menu in the top right (or button on the top left in older versions).

== Importing Models ==
To a view a model file in Cinema 4D, simply use the standard file open dialog (ctrl+O/command-O) or drag the model into C4D's view port. Depending on your installation settings, you may also be able to open models files by double-clicking them. Models that are not in the native .c4d format are automatically imported into a new blank scene. An import setting dialog will appear before importing a model, with the settings available depending on the model's format.

Keep in mind that changing the imported model in Cinema 4D does not affect the original model.

=== [[OBJ]] and [[MTL]] ===
Unfortunately, Cinema 4D has poor support for the [[OBJ|.obj model format]]. The actual meshes will load fine, but the textures will not. This is because Cinema 4D completely ignores [[MTL|.mtl files]], which are necessary for .obj models to load textures and set up material colors. Because of this, all textures will have to be assigned to the model manually. Plugins and scripts exist for loading .mtl files and automatically assigning textures, though some of them do not work with the latest versions.

=== [[DAE]] ===
Cinema 4D has a very strict [[DAE]] importer. Models with a structure that violate the COLLADA DAE schema will usually fail to load, either partially or entirely, even if the model seems to load fine in other programs. Advanced users may be able to correct the flaws in the DAE structure to fix the model loading.

Problems caused by an improper DAE format include crashing Cinema 4D, loading with blank materials, loading with no model [[UV Map|UVs]], model skeletons using the wrong scale, and model pieces being misplaced. The latter two problems usually occur with models that were tampered with in 3DS Max and re-exported.

=== [[FBX]] ===
If there are any problems with the model's structure, it will crash Cinema 4D upon loading.

=== [[3DS (model format)|3DS]] ===
Materials that are supposed to have the Alpha channel enabled usually have the Transparency channel enabled instead. This most notably affects model exports from bmdview2.

=== [[VRML]] ===
Cinema 4D does not directly support [[vertex coloring]], so it will not be able to load this information even though the format supports it. It will only load the material's standard color.

== Exporting Models ==
Cinema 4D can export models in 15 different formats, including all of the acceptable formats. However, its exports are not always perfect. Additionally, shaders will not export on the model, so keep this in mind if you use shaders on your models for the sake of rendering.

=== OBJ ===
Like with exporting, Cinema 4D has poor support when it comes to exporting OBJ models. The created models will have all of their polygons and [[UV Map|UVs]] intact, but no MTL file will be created. This means that a MTL file will have to be created manually in order for the model to be acceptable as a submission. Alternatively, plugins are available for better OBJ exporting.

=== DAE ===
For whatever reason, DAE models created by Cinema 4D have an extra material defined. The material is empty and is not applied to anything. Additionally, the order of meshes in the scene is reversed. Any hierarchies remain the same.

It should be noted that Cinema 4D can export in two versions of the DAE format, 1.4 and 1.5. In general, these formats are practically identical, but some older programs (including older versions of Cinema 4D) may not support models using the 1.5 schema.

== Guides ==
TODO
=== Texturing a Model ===
For models that do not import with textures already applied, they will have to be assigned manually. This section gives the basics of creating a material and applying it to a mesh.

To upload the models, double click on a material, or right click and choose Edit to open the Material Editor box:
[[File:MatEditorExample.png|thumbnail|center|Material Editor]]
Highlight "Color" and click the Ellipses button to open your OS system's file window and locate the textures needed to replace the standard gray material.

[[File:ModelExample1.png|thumbnail|center|Model used is Ryuta Ippongi from Osu! Tatakae! Ouendan]]
You soon notice that the model is shining which, for most models, never shows up in the games they were ripped from. Even if the models come with the texture pre-installed, the shine is still present. This is because Cinema 4D automatically checks "Specular" when a new Material is created.

The problem is easily rectified by either double clicking a material and unchecking Specular, or highlighting all materials used in the model and unchecking Specular on the bottom right corner of the layout.

Be aware that, like any other program designed for 3D viewing or animation, what you download is what will be displayed onscreen. There is no known way of smoothing low-resolution polygons such as PSX, N64, or NDS models, and attempting to do so without properly understanding the mechanics of the software could ruin the original appearance of the models being viewed.

{{Editing Software}}

Cinema 4D

2014-08-15T02:25:43Z

Peardian: exporting info

Cinema 4D

2014-08-14T04:59:36Z

Peardian: Here is this. The guide section needs to be redone still...

[[File:C4DLogo.png|thumbnail|right|Logo]] '''Cinema 4D''' (aka C4D) is a professional 3D modeling and animation software developed by Maxon. It is capable of importing various, pre-existing 3D models, including game models.

== Basics ==
One of the features that sets Cinema 4D apart from other 3D modeling programs is its easy-to-use interface. Camera controls are available in the top right corner of every model view port and can be used at any time, regardless of the currently selected tool. Most actions can be achieved through drag-and-drop or simply dragging. For example, materials can be applied to a mesh by dragging it from the Material list to the model. Textures can be imported into the scene by dragging them directly from the folder on your computer onto the model or Material.

For actions that use the mouse to control an object or input field (such as moving a model or using a value slider), the cursor's current position will not be changed while the action is being performed. This means that the mouse can be moved freely without you having to worry about hitting the edge of the screen. This can take some getting used to.

Cinema 4D's native file format is ".c4d" and is used for saving entire scenes for future use. This format is ''not'' acceptable for model submissions, as Cinema 4D is the only program that can open this type of file.

== Interface ==
In the default layout, the section in the upper right-hand corner displays a list of the entire contents of the scene and is called the Objects panel. This is how you manage the models, lights, and cameras that make up the scene. The two small gray dots next to every object controls whether the model will appear in the editor (top dot) and in renders (bottom dot). Clicking them toggles between default, on, and off.

The panel in the bottom-right corner displays information about the current object or tool. This includes things like a model's coordinates, tool settings, and material properties.

[[File:MatExample1.png|thumbnail|center|Each material is assigned to a particular part of the model]]
The wide panel below the model view port is the material list. Clicking the material will bring up its information in the info panel. Double-clicking the material will bring up this same info in a new window. Materials can be assigned to models in the scene by dragging them from this panel to the mesh in the view port, or by dragging them to the mesh's name in the Objects panel.

The entire layout of Cinema 4D can be rearranged and customized, and these custom layouts can be saved for later use. Drop-down menus can be separated into small pop-up windows by clicking the dotted area of the menu. Layouts can be selected from menu in the top right (or button on the top left in older versions).

== Importing Models ==
To a view a model file in Cinema 4D, simply use the standard file open dialog (ctrl+O/command-O) or drag the model into C4D's view port. Depending on your installation settings, you may also be able to open models files by double-clicking them. Models that are not in the native .c4d format are automatically imported into a new blank scene. An import setting dialog will appear before importing a model, with the settings available depending on the model's format.

Keep in mind that changing the imported model in Cinema 4D does not affect the original model.

=== [[OBJ]] and [[MTL]] ===
Unfortunately, Cinema 4D has poor support for the [[OBJ|.obj model format]]. The actual meshes will load fine, but the textures will not. This is because Cinema 4D completely ignores [[MTL|.mtl files]], which are necessary for .obj models to load textures and set up material colors. Because of this, all textures will have to be assigned to the model manually. Plugins and scripts exist for loading .mtl files and automatically assigning textures, though some of them do not work with the latest versions.

=== [[DAE]] ===
Cinema 4D has a very strict [[DAE]] importer. Models with a structure that violate the COLLADA DAE schema will usually fail to load, either partially or entirely, even if the model seems to load fine in other programs. Advanced users may be able to correct the flaws in the DAE structure to fix the model loading.

Problems caused by an improper DAE format include crashing Cinema 4D, loading with blank materials, loading with no model UVs, model skeletons using the wrong scale, and model pieces being misplaced. The latter two problems usually occur with models that were tampered with in 3DS Max and re-exported.

=== [[FBX]] ===
If there are any problems with the model's structure, it will crash Cinema 4D upon loading.

=== [[3DS (model format)]] ===
Materials that are supposed to have the Alpha channel enabled usually have the Transparency channel enabled instead. This most notably affects model exports from bmdview2.

== Guides ==
TODO
=== Texturing a Model ===
For models that do not import with textures already applied, they will have to be assigned manually. This section gives the basics of creating a material and applying it to a mesh.

To upload the models, double click on a material, or right click and choose Edit to open the Material Editor box:
[[File:MatEditorExample.png|thumbnail|center|Material Editor]]
Highlight "Color" and click the Ellipses button to open your OS system's file window and locate the textures needed to replace the standard gray material.

[[File:ModelExample1.png|thumbnail|center|Model used is Ryuta Ippongi from Osu! Tatakae! Ouendan]]
You soon notice that the model is shining which, for most models, never shows up in the games they were ripped from. Even if the models come with the texture pre-installed, the shine is still present. This is because Cinema 4D automatically checks "Specular" when a new Material is created.

The problem is easily rectified by either double clicking a material and unchecking Specular, or highlighting all materials used in the model and unchecking Specular on the bottom right corner of the layout.

Be aware that, like any other program designed for 3D viewing or animation, what you download is what will be displayed onscreen. There is no known way of smoothing low-resolution polygons such as PSX, N64, or NDS models, and attempting to do so without properly understanding the mechanics of the software could ruin the original appearance of the models being viewed.