The name of the asset , It’s materials and its files must appear in lowercase and must not contain spaces or punctuation. This includes the extension/format.
Examples (only the first option is acceptable):
- marble_bust_01_diff_4k.png (good)
- Marble_Bust_01_Diff_4k.PNG (bad)
- marble bust 01 diff 4k.png (bad)
We call the name of an asset the slug. (e.g. marble_bust_01)
Only latin characters (a-z), numbers (0-9) and underscores (_) may be used for the slug.
It must be unique, no asset (even of a different type) can have the same slug as another asset. The slug is basically an asset’s unique ID.
The naming of the asset and its files should follow the General standards mentioned above.
Texture name example: slug_map.format - E.g: marble_bust_01_diff.png
If there are multiple materials and corresponding textures, Make sure to name the textures to match the materials. E.g marble_bust_01_wood_diff.png
The image format should always be 16 bit PNG at 4K resolution minimum, but preferably 8K. For large assets (more than 1 meter cubed), 8K is the minimum.
If possible please provide both the GL and DX normal maps.
Inside blender the models should all be in a collection that shares the same name as the slug.
This collection should not include any unnecessary objects (e.g. camera & lights).
If the asset has only a single material or mesh, the material and mesh names should be the same as the slug. If there are multiple materials or meshes, prefix their names with the name of the asset. (E.g marble_bust_01_wood).
- Our primary format is a Blender file (.blend), but FBXs or OBJs will be accepted though in these versions you will need to apply all the necessary modifiers before exporting to these formats, and then re-import them into a new scene to check that everything still looks correct.
- Aim to make the model subdivision-friendly. Avoiding triangles/Ngons/weird geometry as much as possible is important to make sure the model holds up when smooth subdivided.
- Models should be as light as possible but still allow for adding further subdivisions. You may keep some supporting edge loops to help the model retain its shape when being smooth shaded. Having good flowing topology where possible will help this too. This will make them easy to use out-of-the-box, but also easy to export, or add additional subdivisions or modifiers.
- All models should be fully UV-uwrapped with no mirrored or stacked UV’s unless in some specific cases where stacked or mirrored UV’s is required. - E.g: Plant leaves and Modular assets using a Trim sheet method.
- To ensure correct UVs, be sure to apply modifiers that add new geometry (solidify, mirror, etc)
- Model needs to be placed naturally at the world origin facing -Y with rotation and scale applied.
- Scene needs to be completely clean with no other objects present other than the ones that are intended to be shared.
- It is important that we get the dimensions as correct as possible. We primarily use the metric system for our measurements. Use a human-sized scale reference to import and use as a visual comparison to ensure all assets are being made with the same scale. We’re not doing precision CAD work, but still good to check that our asset proportions are realistic.
- Small shapes can be done with normal maps/displacement. As a general rule of thumb: if it’s a small detail and it doesn’t affect the silhouette, it can be done with a Normal map. One exception to this is bevels, chamfers and fillets: sometimes these can be done with a normal map, but for the most part we want most of them on the model itself.
- Use the latest official Blender release.
- The poly count value should be based off of the number of triangles.
- Though it is important that we keep the model light, It should not come at the cost of quality or the potential to subdivide.
- We treat each asset as a hero asset that can be used for many purposes from real time engine use up to high quality VFX. We aim to create an asset that sits in the middle of these two points, but err on the side of higher quality in order to remain future-proof when hardware improves.
- Overall polycount will come down to many factors such as complexity, size and most often the curvature involved in the model. There is no consistent way to regulate how many triangles to use, so use your own discretion but included below is a list for some points of reference.
- Make sure there are enough polygons to hold up rounder surfaces like wheels, rings and circles.
- For some point of reference standard props at the sizes of 20 - 60 cm = +-7000 tris, 60cm - 1m = +-15000 tris.
If you require clarification or would like to discuss some of these aspects feel free to join our discord and ask there.
Assets are not required to be rigged, but if you want to rig your asset, we have some standards to keep all our rigs somewhat consistent.
The goal is mainly to strictly separate deform bones and control bones, so people can change the latter for their own need without having to redo the weight deform work. The rig should be a "one to fit them all" solution, and should aim to be easy to modify for specific needs.
- Drivers are ok, but do not use any scripts as they will not be imported for security reasons.
- Use only one armature for each object.
- All the objects involved in the rig should be parented to the armature.
- Save the file in pose mode and Viewport Display without "In Front" checked.
- The armature should be named with the
- The first layer is for deformation bones only.
- The objects deformed by the rig must be handled through an Armature modifier and a proper Vertex group and not with the parenting to bone workflow. It will help prevent messing with the armature in the case that later objects are joined or some of its parts separated.
- The master deformation bone should be called
def_root and should be placed with its axis aligned with the world.
- Deformation bones names should begin with
- Deformation bones should be parented to the root bone
- Deformation bones should be constrained with "Copy Transforms" to a target, a similarly named bone in layer 2, named with
tgt instead of
def at the start. For example,
def_head will be constrained to
- The last layer is for control bones only.
- IK controller bones should be aligned with the global axis or be a child of a bone aligned like this (i.e., like
def_root), and if the latter, with the "Local location" of Relations section left unchecked.
- Control bones names should begin with
- Control bones should be limited in translation, rotation, and scale according to the proper use of their influence on the rig.
- Control bones should have custom shapes that make it clear what they are used for.
- The custom shapes should have arrows to indicate possible axis of rotation/movement if there are some limitation constraints on them.
- Control bone custom shapes should be kept in a separate deactivated collection called
wdg_widgets (>> question to see if they should have Geometry nodes modifier applied or not if it is needed for simple editing) and have their names beginning with
- All bones that are not deformation bones, target bones, or control bones should be prefixed with
tech_ and put in any layer except the first (for deformation bones only) and last (for control bones only).
- Any helpers for the rig (i.e., empties) should be kept in a separate deactivated collection called
hlp_helpers and have their name beginning with
The folder name should match the asset name exactly. We have a lot of similarly named assets, so this is important to avoid confusion.
No file or folder names can contain capital letters. This is because Windows doesn't care about whether text is upper-case or lower-case, but Linux does. Best to stick to lower-case only.
All texture files should start with the asset name and be placed in a
There should be a top-level collection that matches the asset name and contains all objects intended to be imported. If your asset has only a single object, then the object name should match the asset name too.