Skip to main content

Raw Art Asset Foldering & File Naming Convention

Status: Draft
Owner: FSKU Art Department
Audience: Art Teams (Internal & External)
Last Updated: 20260120

1. Purpose & Principles

Repository & Version Control Context
Agate uses SVN (Subversion) repository to manage all raw assets for live projects.

SVN is used as the source-of-truth versioning system for raw art assets, providing:

  • Historical version tracking
  • Change traceability per asset
  • Controlled collaboration between internal teams and external vendors

This document is designed to work in conjunction with SVN and does not replace SVN version history. Instead, it defines human-readable structure and naming to make SVN usage predictable, reviewable, and scalable for art production.

This document defines a standard folder structure and file naming convention for managing raw art assets in Agate.

Goals

  • Ensure consistency across projects and teams
  • Make assets easy to find, review, and hand over
  • Reduce miscommunication between artists, leads, tech, and production
  • Support scalability for outsourcing and multi-project workflows

Core Principles

  • Clarity over cleverness – names should be readable without context
  • Predictable structure – same logic across all projects
  • Tool-agnostic – works for DCCs (Blender, ZBrush, Substance, Photoshop, CSP, etc.)
  • Version-safe – avoids overwriting and ambiguity

2. Scope

Included

  • Raw production files (e.g. .blend, .ma, .psd, .spp, .ztl)
  • Work-in-progress (WIP) assets
  • Assets created by internal and external artists

Excluded (Handled by Other Docs)

  • Engine/exported assets
  • Build/package files
  • Version control system rules (Git)

3. High-Level Folder Structure

/[PROJECT_CODE]/
  /[ASSET_TYPE]/
    /[ASSET_NAME]/
      /_brief/
      /_review/
      /_wip/
      /01_CONCEPT/ -> PSD, CSP, etc
      /02_STATIC/ -> ZPR, BLEND, FBX, TOOLBAG, PAINTER, PSD, CSP, etc
      /03_ANIMATION/ -> BLEND, FBX, SPINE, etc
      /04_VFX/ -> PSD, HIP/HDA, FBX, BLEND, etc
      /05_PUBLISH/ -> FBX, SKEL, TEXTURES, etc game ready

Placeholder Definitions

  • PROJECT_CODE → Project identifier (e.g. BOM, RED)
  • ASSET_TYPE → Characters, Props, Environments, UIs, Cinematics, Marketings
  • ASSET_NAME → Unique, human-readable asset identifier

(We will refine and lock these values later)

4. Asset-Type Folder Breakdown

4.1 Characters

/Character/
  /CHR_[CharacterName1]/
  /CHR_[CharacterName2]/

4.2 Props

/Prop/
  /Interactive_PRP_[PropName]/
  /Weapon_PRP_[PropName]/
  /Armor_PRP_[PropName]/
  /[PropContext]_PRP_[PropName/

4.3 Environments

Environment art-related props should be placed here

/Environment/
  /Biome/ -> terrain data, lookdev data, or anything high level regarding env assets
  	/ENV_[BiomeName]/
  /ModularKit/ -> modular prop for certain biome/context
  	/ENV_KIT_[ModularKitSetName]/
  /Hero/ -> hero prop for environment assets
  	/ENV_HERO_[HeroEnvObjectName]/

4.4 UIs

/UI/
  /UI_Screen_[ScreenName]/
  /UI_IconKit_[IconKitName]/

4.5 Cinematics

/Cinematic/
  /CUTSCENE_[CutsceneName1]/
  /CUTSCENE_[CutsceneName2]/

4.6 Marketings

/Marketings/
  /SteamStoreCapsule/
  /CinamaticTrailer/
  /MarketingReadyImages/
  /MarketingReadyVideos/
  /[MarketingArtContexts]/

(Tech Art handled as supporting discipline, not top-level asset type)

5. Asset Development Stages (Locked Vocabulary)

To keep folder names readable while aligning with industry-recognized shorthand (including Unreal Engine standards), the following stage vocabularies and codes are locked.

Stage Folder Stage Code Meaning
CONCEPT CPT Concept art, visual exploration
STATIC SM Static mesh development (model, sculpt, textures), Static image (illustration, icon)
ANIMATION SK Skeletal mesh, rigging, skinning, animation clips
VFX VFX Asset-specific visual effects
PUBLISH PUB Approved, signed-off handoff files

Rationale

  • CPT is more recognizable than CON and avoids collision with config/console shorthand.
  • SM / SK follow Unreal Engine conventions and are immediately readable by tech art and engineers.
  • Folder names remain semantic; codes are optimized for filenames and engine adjacency.

6. Stage Applicability Matrix

This matrix defines which development stages are applicable per ASSET_TYPE. Stages not listed should not be created unless explicitly approved.

ASSET_TYPE _brief CPT SM SK VFX
Characters ✓ ✓ ✓ ✓ ✓
Props ✓ ✓ ✓ △ △
Environments ✓ ✓ ✓ △ ✓
UIs ✓ ✓ ✓ ✕ △
Cinematics ✓ ✓ ✓ ✓ ✓
Marketings ✓ ✓ ✓ △ △

Legend

  • ✓ = Standard / expected stage
  • △ = Optional, asset-dependent
  • ✕ = Not applicable

7. Asset-Level Folder Structure

/[ASSET_NAME]/
  /REFERENCES/
  /CONCEPT/
  /STATIC/
  /ANIMATION/
  /VFX/
  /REVIEWS/
  /WORK/
  /PUBLISH/

Folder Intent

  • REFERENCES → Briefs, paintovers, moodboards, external refs
  • CONCEPT → Concept art, exploration, silhouettes, color keys
  • STATIC → Static asset development (model, sculpt, textures)
  • ANIMATION → Rig, skinning, animation clips
  • VFX → Asset-specific visual effects (if applicable)
  • REVIEWS → Time-based progress previews and feedback records
  • WORK → Misc WIP, temporary or cross-stage files
  • PUBLISH → Approved handoff files per stage

7.1 Reviews Folder Structure & Rules

Progress updates and feedback must be stored under the REVIEWS folder to ensure clear historical tracking and auditability.

/REVIEWS/
  /[YYYYMMDD]_[STAGECODE]_update/
  /[YYYYMMDD]_[STAGECODE]_feedback/

Naming Rules

  • YYYYMMDD uses calendar date of the review or submission

  • STAGECODE must match the asset stage being reviewed (CPT / SM / SK / VFX)

  • One update folder may have multiple preview files (screenshots, playblasts, turntables)

  • Feedback folders may contain:

    • Annotated images
    • Written feedback (PDF, TXT, MD)
    • Call notes or screenshots from review tools

Example

/REVIEWS/
  /20260120_SM_update/
    ASTRA_HeroKnight_SM_turntable.mp4
    ASTRA_HeroKnight_SM_view01.png
  /20260121_SM_feedback/
    ASTRA_HeroKnight_SM_feedback_v01.pdf

Feedback File Naming Hint (Recommended)

[PROJECT]_[ASSET]_[STAGECODE]_feedback_v##.[ext]

Suggested Best Practices

  • Use one update folder per milestone or daily check-in

  • Feedback should always reference the corresponding update date and stage

  • Do not overwrite previous update or feedback folders

  • If multiple review cycles happen in one day, append an index:

    • 20260120_SM_update_a
    • `20260120_SM_update_b``

8. File Naming Convention (General Format)

[PROJECT]_[ASSET]_[ASSET_TYPE]_[STAGECODE]_[DESC]_[VERSION]

Example

ASTRA_HeroKnight_Characters_STA_Model_v03.blend


### Field Definitions

- **PROJECT** → Project code
- **ASSET** → Asset name (matches folder name)
- **ASSET\_TYPE** → Characters / Environments / Props / UIs / Cinematics / Marketings
- **DESC** → Purpose or content (Model, Sculpt, Rig, Tex, Blockout)
- **STAGECODE** → CON / STA / ANI / VFX / REF / WRK / PUB
- **VERSION** → `v01`, `v02`, `v03`, etc.

*(Exact abbreviations to be finalized)*

---

## 9. Versioning Rules (Draft)

- Always increment version numbers, never overwrite
- Use two-digit versions: `v01`, `v02`, `v10`
- Do **not** use `final`, `final2`, `latest`, etc.
- Published files must reference a specific version

---

## 9.1 Publish Folder – Approval & Sign-off Rules

The **PUBLISH** folder represents an official, approved state of the asset. Files placed here are considered **production-valid**.

### Rules

- Only **approved versions** may exist in `PUBLISH`
- Each published file must:
  - Match an approved review cycle in `/REVIEWS`
  - Reference a specific version number
  - Correspond to a clear development stage (CPT / SM / SK / VFX)

### Authority

- Assets may only be moved or copied into `PUBLISH` by:
  - Art Lead / Art Director
  - Or delegated owner defined per project

### Non-Rules

- `PUBLISH` is **not** a backup folder
- `PUBLISH` is **not** a place for iteration or WIP

### Approval Traceability (Recommended)

For every published asset, at least one of the following must exist:
- A corresponding `[YYYYMMDD]_[STAGECODE]_feedback` folder indicating approval
- A signed-off feedback file (PDF or annotated image)

> If it’s not in **REVIEWS**, it’s not approved.

---

## 10. Naming Examples by Asset Type

### Character – Modeling

ASTRA_HeroKnight_Char_Model_v05.blend


### Prop – Texture

ASTRA_BarrelA_Prop_Texture_v02.spp


### UI – Screen Design

ASTRA_Inventory_UI_Screen_v04.psd


---

## 11. Common Do & Don’t

### Do

- Match file name with asset folder name
- Use English, no spaces
- Use PascalCase or snake\_case consistently

### Don’t

- Use personal initials in file names
- Use ambiguous terms ("test", "new", "fix")
- Store final work only in WORK folder

---

## 12. Vendor Delivery Checklist (One-Page)

This checklist must be completed by **external vendors** before any asset delivery or milestone submission. Deliveries that do not meet this checklist may be rejected without review.

---

### 12.1 Folder & Structure Compliance

- [ ] Asset is placed under correct `PROJECT_CODE/ART/RAW/ASSET_TYPE/ASSET_NAME/`
- [ ] Folder structure matches studio standard exactly:
  - REFERENCES / CONCEPT / STATIC / ANIMATION / VFX / REVIEWS / WORK / PUBLISH
- [ ] No extra or custom folders added without approval
- [ ] Asset name matches folder name exactly (case-sensitive)

---

### 12.2 File Naming Compliance

- [ ] All files follow naming format:

[PROJECT][ASSET][ASSET_TYPE][STAGECODE][DESC]_[VERSION]

- [ ] Correct **STAGECODE** used (CPT / SM / SK / VFX / REF / WRK / PUB)
- [ ] Version numbers incremented correctly (`v01`, `v02`, etc.)
- [ ] No use of `final`, `latest`, `new`, or personal initials

---

### 12.3 Reviews & Feedback

- [ ] Latest progress preview is submitted under:

/REVIEWS/[YYYYMMDD]_[STAGECODE]_update/

- [ ] Preview includes appropriate media:
- Screenshots / turntables (static)
- Playblast or animation preview (animation)
- [ ] All received feedback is stored under:

/REVIEWS/[YYYYMMDD]_[STAGECODE]_feedback/

- [ ] No feedback or approvals are referenced only via chat or email

---

### 12.4 Publish Folder Rules (Critical)

- [ ] `PUBLISH` contains **only approved files**
- [ ] Each published file:
- References a specific version number
- Matches an approved review cycle
- Uses correct STAGECODE
- [ ] No WIP, test, or backup files exist in `PUBLISH`
- [ ] Vendor has **not self-approved** files unless explicitly authorized

---

### 12.5 Content & Technical Hygiene

- [ ] No broken links, missing textures, or external file dependencies
- [ ] Scene files are clean (no unused test meshes, cameras, lights)
- [ ] Scale, orientation, and unit setup follow project brief
- [ ] Texture sources are included where applicable

---

### 12.6 Final Confirmation (Required)

Before submission, vendor must confirm:

- [ ] All checklist items above are completed
- [ ] Delivery reflects **latest approved feedback only**
- [ ] No additional changes are pending or hidden

> **Reminder:** Assets that do not comply with this checklist may be returned without review or payment delay may apply depending on contract.

---

## 13. Open Questions / To Be Defined

- Final asset naming grammar (singular/plural, numbering)
- Engine-export folder structure alignment
- Automated validation possibilities for vendors

---

**Next Step:** Iterate section-by-section and lock rules once agreed by Art Direction, Tech Art, and Production.
Back to top