Vellum — Illuminated Item Cards From Your Own Item Data (Unity 6)

Vellum — illuminated item cards, drawn from your own item data

Every item in your game draws its own card.

Not eight frames repeated across five hundred items. A different drawn card for each one, composed at runtime from the fields your item database already has: its kind, its rarity, its origin, its stats, its worth.

There is no texture in this package. No atlas, no sprite sheet, no material, no font. Forty item devices, ten provenance seals, twelve stat glyphs and seven border orders are drawn in C# by a software rasteriser that ships with the source, so a five-hundred-item game costs five hundred cards and zero import time.

What decides how a card looks

Your field	What it drives
Kind, then Name, then Tags	which of the 40 devices is struck, matched whole-word
Rarity	the palette and the border order — seven orders, not seven tints
Origin	which of the 10 provenance seals is struck, or none
ItemLevel	the device's part count — flanges on a mace, points on a diadem, pips on a rank mark
Worth	how heavily the card is gilded, logarithmically
each Stat.Label	which of the 12 stat glyphs is struck against that line

Forty devices across seven tiers is 280 distinct cards, before the seals and stat glyphs multiply it further.

Your own words always win. Write Kind = "axe" and you get an axe. Write nothing but "Ashfall Greatsword" and you still get a blade, because the name is searched next. Only when nothing matches does a stable hash choose — and it chooses the same device for that item every time, so a card never reshuffles itself between launches.

An unrecognised origin draws no seal at all. A provenance mark invented by a hash would be a claim about your item's history that your data never made.

Your text goes on top, and that is the design

The package draws no lettering. A tooltip's words have to stay selectable, localisable and set in your font, and baking them into a texture breaks all three.

So Vellum draws the sheet, the order, the device, the seal and the stat glyphs, and publishes where the words go:

CardLayout layout = CardLayout.For(item.Stats.Count, hasFlavour: true);
titleText.rectTransform.anchorMin = layout.Title.min;   // normalised, bottom-left origin
titleText.rectTransform.anchorMax = layout.Title.max;

Title, TypeLine, Stats, Flavour, Device and Seal are all published this way — and the layout reflows around what the item actually has, so an item with two stats and no flavour gives that space to the illumination instead of leaving a hole.

Determinism you can ship screenshots against

The same item always draws the same card, in the editor, in a build, on every platform. The seed comes from the item's name and kind only — so re-balancing a damage number never redraws the art, and your store screenshots do not go stale on the next balance pass.

Integration is one small function

Every project has its own item class and none of them is ours, so you map yours once:

static VellumItem ToVellum(MyItem it)
{
    var v = new VellumItem(it.displayName, it.category, MapRarity(it.tier));
    v.ItemLevel = it.level;
    v.Worth     = it.goldValue;
    v.Origin    = it.factionId;
    foreach (var s in it.modifiers) v.Stat(s.name, s.ToDisplayString());
    return v;
}
Texture2D card = CardComposer.Compose(ToVellum(myItem), 420, 596, out CardPlan plan);

The editor window (Window ▸ CSAF ▸ Vellum) shows any item's card beside a derivation panel that tells you exactly why it looks like that — which mark was chosen, whether your own word chose it or a hash did, which origin word matched the seal, and every derived scalar. A designer whose sword drew a mace gets an answer instead of guessing.

What is in the package

• Runtime/Core — Hash, Ink (the software rasteriser), Words, VellumPalette
• Runtime/Mark — GlyphKit, Corpus and the 69 hand-authored marks
• Runtime/Model — VellumItem, VellumLibrary, Derive, SampleArmoury (28 worked examples)
• Runtime/Card — CardLayout, CardComposer
• Editor — the authoring window
• Demo — a scene you press Play on

Every script sits in a named, platform-constrained assembly definition. No Resources/ folder, so nothing is added to your build unless you reference it.

Performance, measured rather than promised. Every mark is a signed-distance field evaluated per pixel on the CPU, so a card costs seconds, not milliseconds, proportional to its pixel count. On Unity 6000.5.7f1 in batch mode on a busy workstation, across three full runs of the same test on identical package bytes: 300x420 4.3 to 5.4 s, 420x596 7.4 to 10.5 s, 600x852 29 to 39 s — 30 to 77 microseconds per thousand pixels. The three runs spread by up to 40 percent on machine load alone, each slower than the last as the workstation got busier, so read the high figure as an observation rather than a ceiling. Compose ahead of the moment you need it and cache the texture, or bake the cards to PNG in the editor and ship those. It is not an on-hover operation. That is the trade that removes the atlas: no texture memory, no import time, no per-project art.

Unity 2022.3+. No third-party dependencies. No render-pipeline dependency — the output is a Texture2D, so Built-in, URP and HDRP all work.

Code and graphics in this package are AI-generated. Every mark is procedural C#; no generative image model was used anywhere in the shipped art path. Copyright (c) 2026 Core Systems Asset Factory.

More from CSAF

More Unity editor tools from the same studio:

• Assembly Warden
• GUID Warden — Unity Meta & GUID Integrity Guard
• Signet: Generated Run Result Cards for Unity
• Almanac - The Illustrated Year

Everything else we make is at csaf.itch.io.