Skip to content
The Technical ArtistArt. Code. Pipelines. Games.
Home/Engines/Unity for TAs
engines - reference
unity
concepts transfer

Unity For TAs

Workingguide~4 min read

If you know Unreal, much of your technical art experience will transfer to Unity. The asset, material, and component concepts are familiar, but the workflows and scripting language differ. This page maps the common terms and gives you a small C# editor tool to try.

On this page The Concept Map Render Pipelines Scripting: C# Instead Of Python The Importer Is The Pipeline Gotchas From The Ue Side

The Concept Map

You know it as (Unreal)Unity calls itWorth knowing
Actor + ComponentsGameObject + ComponentsSame idea; Unity is purer about it - everything is components
Blueprint classPrefab (+ C# scripts)Prefabs are data, not logic - behaviour lives in attached scripts
Level / .umapSceneAdditive scene loading ~= level streaming
Material instanceMaterial (asset)Every Unity material is instance-like; the "master" is the shader itself
Material editor graphShader GraphSame node vocabulary; your HLSL works in both (Custom Function node)
Content Browser / uassetsProject window / .meta filesThe .meta sidecar files ARE the asset identity - never lose them (see gotchas)
Blueprint scriptingC# (MonoBehaviour)C# is widely used for gameplay and editor tooling; check the project’s scripting approach
Data Asset / Data TableScriptableObjectThe TA workhorse for tool configs and pipeline data
Editor Utility Widget / PythonEditor scripts (C#), [MenuItem]Editor tooling is a first-class, genuinely pleasant workflow
NiagaraVFX Graph (HDRP/URP) or Shuriken (legacy)VFX Graph is the Niagara-alike; Shuriken still ships most mobile FX

Render Pipelines: The First Question On Any Unity Project

Unity has three render pipelines, and everything visual depends on which one the project uses - shaders, materials, and half the tutorials on the internet are pipeline-specific. URP (Universal) is the modern default: scales from mobile to PC, where most new projects live. HDRP is the high-end path - closest to Unreal's out-of-box look, PC/console only. Built-in is the legacy pipeline still running many live games; its materials don't port forward automatically. First thing you do on joining any Unity project: find out the pipeline, because a shader authored for the wrong one renders magenta - Unity's version of a compile error, and your first debugging classic.

Scripting: C# Instead Of Python

The honest adjustment: Unity's automation language is C#, not Python. The good news - editor tooling in C# is less ceremony than you fear, and your pipeline instincts port directly. The batch-renamer, in Unity dialect:

C# - Editor/BatchRename.cs
using UnityEditor;
using UnityEngine;

public static class BatchRename
{
 [MenuItem("TA Tools/Rename Selected To Convention")]
 static void Run()
 {
 foreach (var obj in Selection.objects)
 {
 string path = AssetDatabase.GetAssetPath(obj);
 string name = obj.name.Replace(" ", "_");
 if (!name.StartsWith("SM_")) name = "SM_" + name;
 AssetDatabase.RenameAsset(path, name); // refs update, like UE
 }
 Debug.Log($"renamed {Selection.objects.Length} assets");
 }
}

Drop that in any folder named Editor/ and a menu item appears - no build step, no plugin registration. That folder-name-is-behaviour convention is very Unity: learn the magic folders (Editor, Resources, StreamingAssets) early. Python does exist via packages for offline pipeline work, but in-editor, C# is the language of the land. Start with one small editor task and compare it with the Python equivalent you already know.

Use AssetPostprocessor For Shared Import Rules

Unity's import pipeline is scriptable per-event: hooks that run on every asset import, project-wide. This is where naming conventions, texture settings, and metadata get enforced automatically - the pattern our whole pipeline philosophy points at:

C# - Editor/TAImportRules.cs
using UnityEditor;

class TAImportRules : AssetPostprocessor
{
 void OnPreprocessTexture()
 {
 var importer = (TextureImporter)assetImporter;
 string name = System.IO.Path.GetFileName(assetPath);

 if (name.Contains("_N")) // normal maps: by convention
 importer.textureType = TextureImporterType.NormalMap;
 if (name.Contains("_ORM") || name.Contains("_Mask"))
 importer.sRGBTexture = false; // data is linear. always.
 }

 void OnPreprocessModel()
 {
 var importer = (ModelImporter)assetImporter;
 importer.useFileScale = true; // trust the FBX units
 importer.importCameras = importer.importLights = false;
 }
}

Every texture named *_ORM imports linear, forever, for everyone, with no human remembering anything. If you write one piece of C# as a Unity TA, write this one.

Things To Check When Moving From Unreal

  • Y is up and the handedness differs. Unity: Y-up, left-handed, metres. Full conversion table on Units & Axes - your Blender export preset needs a Unity variant, not a copy.
  • .meta files preserve asset identity. Every asset has a sidecar .meta carrying its GUID - references point at the GUID, not the path. Move a file without its .meta (in Explorer instead of the editor) and every reference to it dies. Commit .meta files to version control, always; this is the Unity equivalent of redirectors, except less forgiving.
  • Linear vs gamma colour space is a project setting (older mobile projects sometimes still gamma). All the sRGB debugging knowledge applies, with one extra "which mode is this project in" question on top.
  • No material instances hierarchy. Coming from UE's master/instance discipline, Unity's flat materials feel loose - the equivalent structure is fewer shaders with well-designed properties, plus Material Variants (newer Unity) for the override chain.
  • The frame debugger is your shader-complexity view. Window -> Analysis -> Frame Debugger steps through draw calls one by one; RenderDoc integrates cleanly for the deep dives.