diff --git a/README.md b/README.md index e5f5854..68f52f7 100644 --- a/README.md +++ b/README.md @@ -4,10 +4,18 @@ Asset/art files for Hook, Line and Axe ## Naming Conventions Naming conventions are important for project organization and tooling. -### Material Maps -[IronPress](https://github.com/arocull/IronPress) requires naming conventions for texture maps to be properly used. IronPress is important as it enforces proper bit-depth, performs channel-packing, and for allows bulk texture resizing. +For automation, **it is heavily preferred that all folders and file names are kept lowercase with no spaces**. -All materials and material maps should start with the prefix `mat_` and followed by the material name, such as `mat_stone`. Lowercase is required. +- **Characters** - Please store all character models, textures, rigs, etc in its relevant subfolder within the `characters` directory. +- **Props** - Please store all within the `props` folder, within its relevant subfolder. + - When uploading models, please use either FBX or OBJ formats. +- **Animation** - Character *animations* should instead be stored in the `animations` directory, within its relevant subfolder. + - Depending on who is animating, please start your filename with `anims-alan` (or `anims-tommy` or `anims-shelby`, etc) for batch-export automation purposes. Iterative saves are okay. + +### Material Maps +[IronPress](https://github.com/arocull/IronPress) requires naming conventions for texture maps to be properly used. IronPress enforces proper bit-depth, channel-packing, and enables batch-resizing of textures. + +All materials and material maps should start with the prefix `mat_` and followed by the material name, such as `mat_stone`. **Lowercase is required**. Texture maps should be followed with specific names. Examples are provided - `mat_example_basecolor` - Basecolor/diffuse/albedo of material. If the material is transparent, alpha is stored on this as well @@ -19,8 +27,29 @@ Texture maps should be followed with specific names. Examples are provided - `mat_example_opacity` - Opacity map, only use if necessary - `mat_example_mask` - Mask, only use if necessary -## Animations +Please store all textures under one folder in the relevant directory, named `textures` (in all lowercase). + +Additional notes: +- If multiple materials use the same textures maps, please only store one copy of said texture map. +- Export normal maps to 16-bit if possible for maximum quality +- IronPress can be avoided with a customized Substance export setup + +## Animation Guides Guides for animation: - [Setting Up a New Animation](docs/animation.md/#setting-up-a-new-animation) - [Finalizing an Animation](docs/animation.md/#finalizing-an-animation) - [Editing Existing Animations](docs/animation.md/#editing-existing-animations) + +## Asset Guidelines +Guidelines for asset making: +- [Topology](docs/assets.md#topologydetail-density) +- [Texturing](docs/assets.md#texturing) +- [Scale](docs/assets.md#scale) + +## Automation +If you need results from an automated process, see the `pipeline` directory. Each shell script should export the corresponding textures to a folder within the `export` directory. + +For animations, please include the `pipeline/export_anims.py` script in your Blender file. This allows one-click exporting of FBX animations (may be fully automated with a script later). + +## Questions +If there are any questions or feedback on these guidelines and conventions, please poke Alan with a sharp, pointy stick. diff --git a/docs/assets.md b/docs/assets.md new file mode 100644 index 0000000..e51f834 --- /dev/null +++ b/docs/assets.md @@ -0,0 +1,52 @@ +# Asset Guidelines and Considerations + +When making assets for games, there are many technical requirements and considerations that must be factored in to making said assets. + +## Topology/Detail Density +When working on a model, there are a few questions you must ask yourself: +- How close to my camera will the model get? +- What proportion of my screen will this model take up? +- How many of these will be present at any given time? +- When, where, and in what context will this model be shown? +- Does this model need to deform? Where? +- Does the model move in-game? How fast? +- How will the topology impact shading? +- How will the topology impact the sillohouette? + +Use these answers to your advantage: +- If a prop never gets close to the camera, it doesn't need much modeled detail! + - Contrarily, if a model takes up lots of screen space, it probably needs some extra detail to properly fill it out + - If the model is static and non-deforming, Unreal Engine may make some use of LOD to hide the unnecessary stuff for you. This is not guarunteed. +- Enemies need a low polycount since many are on screen at once + - Contrarily, we only have one Insurrectionist, and he is close to the camera, so it is okay if he's a bit more detailed +- If there is topology that does NOT impact the sillohouette, it is not necessary in the low-poly +- There is no need to keep and texture topology that will never be seen. Delete it! + +## Texturing +The same questions as above also goes in for texturing. +- If a model takes up a lot of screen space, it's likely going to need a higher texture resolution to accomodate, or it'll look low-quality. +- If a prop is exceptionally small (like the size of a character's fist), you could likely use a 512px map and be fine. + +If you are uncertain what resolution you should use, go straight for 4K or 2K, and we can painlessly resize the textures with IronPress +(assuming that you followed the proper [Naming Conventions](../README.md#material-maps)). + +Ideally, even if a prop is broken into separate "parts," **keeping all related-parts on the same material map**: +- Reduces file-system overhead +- Reduces how many textures we have to import and manage +- Optimizes rendering + +## Scale +As we are working with asset packs grounded in realism, keeping scale consistent is important to the player's immersion and believability of the scene. +In some cases, however, we may be required to push this in one direction or another for gameplay purposes specifically. + +Here are cases where we would want to exaggerate scale for gameplay purposes: +- **Doorways** - Do not want the player's camera to bump against it as they move through +- **Walkable platforms** - Players may accidentally stumble off of thin platforms +- **Objectives (buttons and such)** - Player should be able to easily spot things of interest + + +Regardless of if scale needs to be exaggerated or not, doing research on what conventional sizes for objects may be helpful. +Context is key in these cases as well. + +For example, some pine trees may have an average height of 10 meters, whereas most oak varieties may have an average height of 20 meters. +What does this mean for the size of our models when we're in a taiga versus a savanna?