agentleFS
MRCalderon3DMRCalderon3D/everything-game-dev-code/skills/art-audio-content/lighting-lod-pipeline/SKILL.md

lighting-lod-pipeline

Skill105 starsChanged 8 months agoMITView on GitHub

Define lighting policy, light budgets, LOD chains, and culling rules so 3D scenes look intentional and hit frame budgets.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    every scene states which lights are dynamic and which cast shadows — defaults are decisions, not accidents

    line 39
  2. Distinctive:

    every light dynamic and shadow-casting because that was the default when it was placed

    line 45
  3. Distinctive:

    Keep this skill aligned with the relevant rules layer and current project documentation.

    line 66
  4. Distinctive:

    If engine-specific constraints materially change the workflow, hand off to the matching engine skill or engine-specific reviewer.

    line 67

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Lighting and LOD Pipeline

Purpose

Define lighting policy, light budgets, LOD chains, and culling rules so 3D scenes look intentional and hit frame budgets on the weakest target.

Use When

  • 3D scenes need a lighting approach and nothing is decided beyond defaults
  • frame cost traces to lights, shadows, or geometry density at distance
  • environments grow and need LODs, culling, and draw-distance policy

Inputs

  • art direction for mood, time-of-day needs, and dynamism (static vs day cycle)
  • target platforms and their lighting capabilities (baking, shadow budgets)
  • scene inventory: interiors/exteriors, scale, density
  • frame budget allocation for lighting and geometry

Process

  1. decide the lighting policy explicitly: what is baked (or faked with blob shadows/light textures), what is dynamic, and which single light owns real-time shadows in a typical scene
  2. budget lights per scene category: dynamic light count, shadow-casting count, and shadow resolution against the weakest target
  3. define the ambient/indirect strategy (baked GI, probes, flat ambient plus tuned materials) consistent with the art direction
  4. define LOD chains per asset category: reduction targets per level, switch distances tied to on-screen size, and whether the last level is an impostor or culled
  5. set culling and draw-distance policy: occlusion strategy for interiors, distance culling tiers for props and detail layers
  6. validate on target: light/shadow cost and LOD transitions measured on the weakest device, with popping checked at gameplay camera speeds

Outputs

  • lighting policy sheet (baked/dynamic split, shadow ownership, ambient strategy)
  • per-scene light and shadow budgets
  • LOD chain conventions per asset category with switch-distance rules
  • culling/draw-distance policy and the on-target validation checklist

Quality Bar

  • every scene states which lights are dynamic and which cast shadows — defaults are decisions, not accidents
  • lighting cost is measured within its frame-budget allocation on the weakest target
  • LOD switches are not visible at normal gameplay camera distance and speed
  • distant or occluded content is demonstrably culled, not just unlit

Common Failure Modes

  • every light dynamic and shadow-casting because that was the default when it was placed
  • LODs authored once at arbitrary reductions and never tuned to on-screen size, popping constantly
  • ambient handled by cranking material emissive or fog until baked and dynamic objects no longer match
  • interiors paying for the whole exterior because no occlusion or portal strategy was decided

Related Agents

  • technical-artist
  • level-designer
  • performance-reviewer

Related Commands

  • art-3d-pass
  • perf-budget
  • level-beat

Related Skills

  • materials-shading-pipeline
  • 3d-asset-pipeline
  • vfx-pipeline

Notes

  • Keep this skill aligned with the relevant rules layer and current project documentation.
  • If engine-specific constraints materially change the workflow, hand off to the matching engine skill or engine-specific reviewer.
  • Boundary: this skill owns lighting/LOD policy for content; engine-specific render pipeline settings (e.g. URP/HDRP configuration) belong to the engine layer.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.