EverettFish/holo-card-studio: a Codex skill that builds holographic cards as Blender files and Three.js pages

What holo-card-studio actually produces

This is a Codex skill, not an application you install and launch. The repository ships code and text only; the README states that generated artwork belongs in the user's own output project. You describe a card in natural language inside Codex, or upload a reference image, and the pipeline returns four things: a local web link, a card.blend file, the four source PNG layers under assets/, and card-config.json. A rendered still image is also delivered.

The intended users are people who want a card they can keep editing rather than a fixed image. The README lists pet portraits, indie game character sets, team anniversary cards, personal gifts and conference giveaways. The common thread is that the card has to be re-skinned later: swap a layer, change the name or rarity in the JSON, rerun the pipeline. If you only want a single flat PNG, this is a heavier route than a drawing tool.

Four layers, parallax and a laser rainbow

The card is not one image. It is four images stacked on the same canvas: background, subject, lineart and text. Parallax pulls them apart in space. The README gives the default geometry: the subject sits at scale 1.25 with depth 0.4, and the background at depth -0.25. The subject pushes forward, the background recedes, and the lineart layer carries a glowing outline whose strength and mask density are adjustable, from a faint edge to a neon stroke.

On top of that sit the holographic effects. A laser rainbow shifts phase with the viewing angle, so the colour moves as you rotate the card. Voronoi starlight adds sparkle, with a scale and animation noise you can dial from a few points to a full field. The text layer is generated separately by generate_typography.py, which the README describes as producing a precise transparent text layer, so typography stays crisp instead of being baked into the illustration.

The browser side rebuilds the same four-layer composite in Three.js using the same UV formula, and reproduces the same kind of parallax and laser behaviour. The README is explicit that this is not a pixel match: web shading differs from Blender's offline lighting, so colour, glow and back-face decoration will diverge. Treat the web page as the interactive preview and Blender as the source of truth for final output.

Installing the skill and running a first card

There is no package manager step. The README says to place the directory into Codex's skills folder at this path:

~/.codex/skills/holo-card-studio/

Runtime requirements are Python 3 with Pillow, and Node.js with npm. Blender is deliberately not something you install yourself. The pipeline fetches the official portable build into `<project>/tools/`, verifies its SHA-256, and keeps it project-local so it does not interfere with anything else on the machine. If you already have Blender, it is reused first, and you can point at a specific executable with `--blender`. The README notes the holographic route adapts to both legacy compositor nodes and newer compositor node groups, that macOS can use Metal, and that preferences are stored in the project's `tools/blender-config/`.

With assets and configuration in place, the entry point is run_pipeline.py:

python scripts/run_pipeline.py --project <project-dir> --mode holographic

If you omit `--mode`, the pipeline reads `mode` from the configuration; if the configuration has no mode either, it defaults to `holographic`. Two flags are documented for skipping work: `--skip-render` skips the static render, and `--skip-npm` skips installing the web dependencies. The README points to references/verification.md for the scope of the run, render and browser checks.

Inside Codex you then just describe the card, for example a request for an ink-wash koi card with calligraphic text and the number No.001, or an instruction to follow an uploaded reference while keeping the subject and composition and replacing the background with a starfield. The README states that Codex first restates the card spec and the details it inferred, then draws, generates the text layer, writes the configuration, runs the pipeline, starts a local server, and opens the page to test dragging, flipping, the slider and the mobile layout before delivery.

The lenticular mode is a different card, not a filter

A second route exists alongside the holographic one. The README calls it the lenticular, flip or dual-form card. It does not split one image down the middle. It uses two complete card faces, image_a.png and image_b.png, and the whole picture switches as the viewing angle changes.

When no reference image is given, the README says the default look is a full-colour Japanese ukiyo-e composition with ink-wash anime linework. When a reference is supplied, image A is generated first, and B is then edited with A as the identity anchor, locking face shape, proportions, clothing anchors, camera and subject scale. That anchoring step is the interesting design decision: it is what keeps the two faces recognisably the same character instead of two unrelated drawings.

The Blender scene for this mode contains separate layers for the physical card base, the image layers, a cylindrical lens array, a holographic film, rim light and sparkle particles. The web viewer loads a GLB exported from Blender and drives the full-card switch with the same view-angle formula, with mouse and touch tilt supported. A lenticular project expects this set of files:

assets/image_a.png
assets/image_b.png
assets/text.png
card-config.json

Run it with the mode flag:

python scripts/run_pipeline.py --project <project-dir> --mode lenticular

Delivery for this route is card.blend, front and tilted renders, web/assets/card.glb, a white-background Three.js viewer and a verification report. The mode can also be selected automatically through the `mode` key in card-config.json.

Where the pipeline gets in your way

The biggest constraint is the Codex dependency. The natural-language front end is the whole point of the skill, and the README frames usage entirely as talking to Codex. If you want a plain command-line tool that takes a prompt and returns a card, you are using the wrong layer of this project. The scripts are there, but the orchestration that infers the spec, writes the configuration and checks the browser is described as Codex's job, not the pipeline's.

The second constraint is the Blender download. The pipeline places a portable Blender under `<project>/tools/` and verifies its SHA-256. That is good hygiene, but it means the first run pulls a large binary into your project directory, and any environment where outbound downloads are blocked or disk is tight will fail at that step. The README does not document an offline path beyond pointing at an existing executable with `--blender`.

The third is fidelity. The README does not claim the web viewer matches the Blender render; it says the opposite, listing colour, glow and back-face decoration as areas where they differ. If your deliverable is a precise final image, the browser page is a preview and you should render from card.blend.

Finally, the licence. The repository's licence is reported as NOASSERTION, which means the LICENSE file could not be matched to a standard identifier. That is a real question to resolve before redistribution, and the README does not address it.

How it differs from a general image generator

The obvious alternative is a text-to-image model used directly, or a Blender add-on that generates materials. Both differ from this project in the same way: neither hands you a structured, re-runnable card.

A general image generator gives you a picture. You cannot change the rarity number without redrawing, and you cannot move the subject forward in depth without inpainting. Here the card is decomposed. The subject, background, lineart and text are separate files under assets/, the metadata lives in card-config.json, and rerunning the pipeline regenerates the composite. That is the actual difference in approach: the output is a project, not an artifact.

A Blender material add-on sits at the other end. It gives you nodes to play with but no pipeline, no typography layer, no web export and no card configuration. The README positions card.blend as a teaching artefact as much as a deliverable, with shared node groups named in Chinese for scaling, depth and parallax, plus independently adjustable laser stripe, starlight and lineart glow nodes. If what you want is to study how a holographic effect is built, that file is the reason to look at this repository; if what you want is a card by tomorrow, the Codex conversation is the reason.

Maintenance, packaging and what to check before adopting

The repository is not archived, and the last push was on 2026-09-12. That is recent enough that the code is unlikely to have drifted far from the README, but there are no retrieved releases, so there is no versioned changelog to read and no tagged upgrade path. Upgrades mean pulling the repository again and re-reading references/verification.md, since the pipeline's checks are documented there rather than in a release note.

There is one packaging utility worth knowing about. The README describes package_skill.py as packaging only text files according to a whitelist, producing a clean ZIP you can hand to someone else:

python scripts/package_skill.py

That whitelist behaviour is also a boundary: your generated artwork, .blend files and models are not in the package. The skill stays small, and the outputs stay in your project.

The licence situation is the item to settle first. NOASSERTION is not a licence, it is the absence of a recognised one, so the terms under which you may redistribute the scripts are not stated in the README. For internal use that may not matter. For shipping the skill inside a product, read the LICENSE file in the repository root before you build on it. This is not legal advice, just the one file to open before anything else.

Editorial conclusion

Adopt holo-card-studio if you already work inside Codex and want an editable Blender scene plus a browser viewer from one description, and you accept that the web shader is an approximation of the Blender render. Skip it if you need a standalone CLI with no Codex dependency, a hosted service, or a card generator that runs without Blender being fetched into the project. Before committing, read references/verification.md to see what the pipeline actually checks, and open references/config.example.json to confirm the mode and rarity keys match the cards you plan to produce.

Frequently asked questions

Official sources

1. EverettFish/holo-card-studio on GitHub
2. Issues
3. README