🏗 Snap Studio Pro – Architecture Overview¶

Snap Studio Pro is a modular Unity Editor tool built around: - clear ownership boundaries - editor workflow orchestration - render-pipeline isolation - maintainable territory separation - long-term editor scalability

The architecture intentionally separates: - editor UI - workflow coordination - rendering implementation - preview lifecycle - infrastructure support systems - pipeline-specific behaviour

This document explains the high-level architectural model used throughout the project.

📁 High-Level Territory Structure¶

Each major territory contains its own README.md explaining: - ownership - dependency direction - architectural intent - non-goals - future boundaries

🧠 Architectural Philosophy¶

Snap Studio Pro is intentionally built around: - explicit composition - practical separation - editor-first workflows - maintainable orchestration

The goal is not: - framework theatre - abstraction for aesthetics - unnecessary indirection - over-engineering

The goal is: - predictable ownership - understandable workflows - safe extensibility - long-term maintainability

🧱 Key Architectural Principles¶

✅ Territory Ownership¶

Every major system has a clearly defined ownership boundary.

Examples:

This prevents: - utility dumping - hidden ownership - accidental orchestration spread - giant god systems

✅ Orchestration Is Allowed¶

Some systems are intentionally coordination-heavy.

Examples: - PrefabPreviewWindow - RightPanel - MiddlePreviewPanel - PrefabPreviewManager

These are not architecture failures.

They exist because editor tooling naturally requires: - workflow coordination - panel composition - repaint routing - lifecycle management - multi-system orchestration

The architecture intentionally separates: - orchestration layers from - implementation layers

✅ Render Pipeline Isolation¶

Snap Studio Pro supports: - Built-in Render Pipeline - Universal Render Pipeline (URP) - High Definition Render Pipeline (HDRP)

Each pipeline owns its own: - camera logic - lighting logic - volume handling - rendering integrations - fallback implementations

The architecture intentionally avoids forcing fake “one-size-fits-all” rendering abstractions where Unity pipelines behave fundamentally differently.

✅ Editor-First Architecture¶

The capture pipeline is Editor-only. The architecture intentionally isolates: - editor UI - editor workflows - editor rendering - editor-only utilities

No runtime gameplay framework is shipped, and nothing in the capture pipeline runs at runtime.

Four assemblies are nonetheless not Editor-gated, and are listed here so the policy below is read accurately:

Earlier revisions of this document stated the tool was Editor-only without qualification. That was inaccurate — RuntimeKit has shipped since 1.1.0 — and the correction is recorded here rather than silently applied.

✅ Assembly Granularity (asmdef policy)¶

The tool is split into ~35 assembly definitions to enforce layering at compile time (Panels physically cannot reach Pipelines internals) and to make the render-pipeline stub/impl split work.

Policy for adding assemblies: - Do not create a new .asmdef for a folder under ~500 LOC unless it is a genuine compilation boundary — a render-pipeline stub/impl pair (defineConstraints), optional-dependency isolation, or a test assembly. Small art/util folders belong in an existing assembly. - Every assembly is a node in the compile graph with its own compilation overhead; a proliferation of tiny assemblies slows iteration without buying real isolation. - The existing small assemblies (Enums, Attributes, Presets, Thumbnails) are grandfathered — don't add more of that shape.

The big splits (Pipelines, Logic, Abstractions, Features/Panels/Preview) earn their keep; further subdivision generally does not.

✅ Diagnostics & Logging¶

Editor logging goes through MyLogger (in the Diagnostics assembly), which is category-gated and quiet by default — a message only surfaces when its category toggle is enabled (support enables categories when investigating a report). This keeps a shipped asset from spamming the user's console. Use MyLogger.Log/LogWarning/LogError("<Category>", msg) with a category from the MyLogger dictionary (unknown categories are dropped); ForceLog bypasses categories for critical always-visible breadcrumbs.

Two hard boundaries — these must never use MyLogger; they stay on UnityEngine.Debug: - RuntimeKit — it is runtime gameplay code and must not reference the editor-only Diagnostics assembly at all. - Core and UI — Diagnostics depends on them, so referencing back would be an assembly cycle.

Everywhere else in the editor tool, prefer MyLogger over raw Debug.* for consistency and filterability.

🎛 Core Workflow Model¶

The editor architecture roughly flows like this:

Window
  ↓
Panels
  ↓
Features / Preview
  ↓
Rendering / Infrastructure / Pipelines

Window¶

Owns: - application shell - layout - lifecycle - composition

Panels¶

Own: - user interaction - request construction - editor workflow UI

Features¶

Own: - workflow behaviour - export coordination - animation systems - lighting systems - capture systems

Preview¶

Owns: - live preview scenes - preview lifecycle - preview coordination

Rendering¶

Owns: - image generation - compositing - texture processing - capture implementation

Infrastructure¶

Owns: - runners - prefs - file IO - progress - support utilities

🖼 Preview Architecture¶

Preview is intentionally separated from Rendering.

Preview owns:¶

• preview scene lifecycle
• prefab instance management
• camera coordination
• preview state
• interaction state

Rendering owns:¶

• image generation
• compositing
• low-level rendering
• texture processing

This separation allows: - reusable rendering systems - cleaner preview lifecycle management - safer export workflows - pipeline isolation

🧩 Panel Philosophy¶

Panels are intentionally allowed to: - coordinate UI - gather state - build request objects - route workflow actions

Panels are NOT expected to be “tiny.”

Complex editor workflows naturally require: - grouped UI - orchestration - multi-system interaction

The architecture focuses on: - ownership clarity - implementation separation

—not artificially shrinking every class.

🎨 UI & Theme System¶

The UI system is fully theme-aware and centralized.

It includes: - reusable IMGUI controls - GUIStyle factories - theme persistence - texture/style caching - preset-driven themes - live style refresh

The UI architecture intentionally separates: - presentation from - workflow logic

🧪 WIP / Labs Philosophy¶

Experimental systems are intentionally isolated under: - Features/WIP - Panels/WIP - Labs Mode

WIP systems are allowed to: - evolve quickly - remain unstable internally - experiment with workflows

They should NOT: - leak unstable dependencies outward - become hidden production dependencies

🔧 Thumbnail Architecture¶

Thumbnail systems are intentionally separated into: - generation infrastructure - caching - browser presentation - rendering workflows

This prevents the prefab browser from becoming coupled directly to rendering or preview lifecycle ownership.

Thumbnail caches also explicitly own texture cleanup responsibilities to avoid long-session memory leaks.

📦 Shader Generation¶

Snap Studio Pro contains shader template systems used to generate pipeline-specific shader assets.

This exists to safely support: - Built-in - URP - HDRP

without requiring all pipelines simultaneously.

Generated shaders are considered disposable artifacts. Source templates should be edited instead of generated outputs.

📚 Documentation Philosophy¶

Snap Studio Pro uses: - XML documentation - folder-level READMEs - territory documentation

to explain: - ownership - architectural intent - dependency direction - orchestration boundaries

The goal is: - future maintainability - onboarding clarity - predictable extension - readable architecture

—not documentation theatre.

💬 Final Notes¶

Snap Studio Pro evolved organically over time, but now follows a clearly structured editor architecture focused on: - maintainability - explicit ownership - editor workflow clarity - long-term sustainability

The architecture intentionally balances: - practical Unity editor development with - disciplined separation and modularity

without sacrificing usability or iteration speed.

Built by Rev (and Rab).