Polymend

View saved version →

---
name: images-to-print
description: Turn pictures of a character or object into a physical 3D print. Use when the user wants a printable model made from reference images with a 3D generation tool they have connected (such as an image-to-3D plugin, or its command line) and then print files: it covers choosing the references, the cost question, checking the generated model, and handing it to the print-ready skill for repair, sizing, STL and 3MF, and a review.
---

# From pictures to a print

Use this with whatever 3D generation tool the user has connected. Polymend does not generate models; it reviews the generated model and makes it printable. Follow the generation tool's own instructions for its exact parameters; the points below are what decide whether the result prints well.

## 1. Before generating

- **Print height** in millimeters (optional): ask once, alongside the other questions, and say it can be skipped. If skipped, the print files keep the model's own size and the user scales them in the slicer. Never make one up, and never hold up generation waiting for it.
- **References**: separate, sharp pictures of the same subject in one consistent pose, ideally front, side and back, one subject per picture, no contact sheets or tiny thumbnails. Point out contradictions between the views before anything is spent: when the front shows the arms spread and the side shows them reaching forward, models made from them often follow the side view. If there is no side view, mention once that the depth front to back will be the generator's estimate, and that a side picture would pin it down; then carry on unless the user wants to add one.
- **How many pictures the tool takes**: check the generation tool's own limits before choosing. A common image-to-3D setting takes at most **four shape pictures** and **one texture picture** (a texture prompt, if given, is used instead of the texture picture). Tell the user the limit plainly, as a fact about the tool, so they know what to expect.
- **More pictures than the tool takes** (for example ten): never drop pictures silently or pick without saying so. Say how many the tool takes, recommend a set and why, and let the user choose or accept the recommendation before anything is spent. A good default: front, side and back, plus one more chosen for what matters most:
  - a sharp close-up of the detail that matters most (usually the face), for finer detail there; in tested runs it gave separate teeth and a raised iris that three views alone did not; or
  - a three-quarter rear view, when a feature shows only from behind (a tail, a cape, a backpack); if such a feature appears in only one or two of the four pictures it may come out stunted or missing.
  **Exactly as many pictures as the tool takes counts too**: if one of them is a close-up and a feature seen mainly from behind (a tail, a cape) shows in only one or two of the pictures, name that feature and the risk, and ask whether to swap the close-up for a three-quarter rear view before anything is spent.
  Say the trade-off when it applies: in a tested pair of runs of the same figure, a face close-up as the fourth picture gave a crisper face but the tail came out as a stub; without the close-up the tail came back (hanging straight down rather than as posed) and the face was a little softer.
- **Texture: a picture or a prompt, not both.** The tool takes one texture picture, or a short texture prompt; if both are given, the prompt is used. They behave differently, so choose with the user's goal:
  - a **texture picture** (a sharp close-up of the surface: skin, scales, stone), with no prompt: in tested runs it carried grain and scales into the model's surface, for fine prints; the same close-up can also be the fourth shape picture;
  - a **texture prompt**, short and about material and finish (colors do not matter for a single-color print): smoother surfaces with crisper features, for quick prints or larger nozzles.
- **Symmetry**: if the tool has a symmetry setting, prefer off unless the user wants an exactly symmetric object. Figures have sometimes come back with a feature repeated front to back (a tail also at the front, a face also on the back); in tested runs this happened with symmetry on and off alike, so the setting is not a fix, and a run can simply come out differently.
- **Detail**: use the tool's highest mesh detail unless the user asks for less; it usually prints best, especially for figures. Some generators cap the polygon count (one common setting tops out at 300,000); Polymend takes up to 1,000,000 triangles and 200 MB per file, so the repair is never the limit.
- **Credits**: generation is paid. A request to generate ("make a 3D model of this", "use the generator") is the go-ahead for one run; do not ask for a credit limit and do not suggest a price. If the tool gives an estimate, mention it in passing. If it does not, do not comment on that (no "the estimator couldn't…"); just say you will report the actual charge when the run finishes. If the request only explores ("what would this look like in 3D?"), confirm before the first paid run. Submit once; after a timeout, check whether that job is still running or finished before submitting anything again. Afterwards, report what was actually charged if the tool shows it.
- **Follow-up runs**: when a similar model was already generated (earlier in this conversation, or in what you remember of the user's past work) and you know what that run was actually charged, confirm before the next paid run with a yes-or-no question, for example: "The last run like this was charged <the amount you saw> credits. Okay to spend credits on another one?" Quote only a charge you actually saw, never an estimate or a figure from these instructions, and never ask the user to name an amount.

- **What to expect**, said once before generating so nothing comes as a surprise: generated models usually follow the pictures closely from the front, but depth and anything seen mainly from behind are estimates. In testing, heads usually came out somewhat deeper front to back than the side picture, even with a good side view. Polymend reports these differences afterwards; it does not reshape the model.

## If the model cannot be generated here

If the connected tool cannot submit a 3D job in this session (its 3D generation step is not offered, sign-in is needed, or the job will not start), say so plainly, once, in neutral terms: what is ready (the chosen pictures, the height), and that no job was submitted and nothing was charged. Do not open a browser or another app to generate without asking, and do not retry on your own.

Then help the user carry on with Polymend; the repair does not depend on how the model was made:

- **The tool's own app or website**: generate the model there with the same pictures (the settings above still apply: symmetry off, highest detail), download the GLB, and share its file or link here; Polymend takes it from there.
- **The tool's command line**, if the user has it installed and signed in: offer to use it for the same job, with their go-ahead (for Higgsfield, see the next section).
- **A model they already have**: any GLB or STL can go straight to the **print-ready** skill.

Keep the wording about the tool factual (for example "3D generation is not available through the plugin in this session"), never a judgment about it.

## Generating with Higgsfield's command line

Use this when the user generates with Higgsfield (its multi-image-to-3D model, provided by Meshy) and its command line is the way to submit the job, or the plugin cannot.

- **Find the official tool.** It is called `higgsfield` (sometimes installed as `hf`, but `hf` is also an unrelated tool, so check that it identifies itself as Higgsfield). If it is not installed, point the user to Higgsfield's own instructions; do not install it without their go-ahead.
- **Sign-in is the user's.** Check with `account status`. If it needs signing in, run `auth login` and let the user finish it in their browser. Never ask for a password or key, and never open or copy the tool's credential files.
- **Check the settings it accepts** with `model get multi_image_to_3d --json` before submitting, and use what it lists. Settings that have worked well for figures:

```sh
higgsfield generate create multi_image_to_3d \
  --image "front.png" --image "side.png" --image "back.png" \
  --should_texture true --enable_pbr true --should_remesh true \
  --target_polycount 300000 --topology triangle --symmetry_mode off \
  --enable_rigging false --enable_animation false \
  --wait --wait-timeout 20m --wait-interval 15s --json < /dev/null > generation.json
```

  Add a fourth `--image` (a close-up) or a texture picture (`--texture_image_url` with the URL from `upload create`) or a short `--texture_prompt`, as chosen in step 1. Always redirect input from `/dev/null`; without it the command can wait for input forever and submit nothing.
- **Submit once.** If the wait times out or ends on a temporary error, the job may still be running: check it with `generate get <job id> --json` (or `generate list --json` to find it) before doing anything else. Report the actual charge from `account transactions --size 5 --json`.
- **Get the model**: the finished job lists a GLB link; pass that link (or the downloaded file) to the **print-ready** skill.

## 2. After generating

- Keep the generated GLB (its file or its link).
- Hand it to the **print-ready** skill, with the height if the user gave one. Its scripts are in that skill's folder (next to this one); call them by full path, quoted. A generator's https link can be passed as it is; if downloads are blocked where the scripts run, use the file the tool saved or ask the user for it.
- Follow print-ready's **Review, then report**: Polymend's review (what came out well, what did not, what it fixed), the views with every change marked, and the comparison with the references. Show them, and judge the back, thin parts and likeness.

- **Features copied front to back**: if the model comes back with something from one side repeated on the other (a second tail at the front, a second face on the back), say so plainly as what the generated model shows; it is a known kind of generation result. Generating again (with symmetry off, if it was on) may give a different result, but it is not a reliable fix: in tested runs the same pictures gave one tail or two on different runs. Say so plainly; the reliable fix is to remove the extra part in a 3D editor. Generate again only if the user asks.

## 3. Report

Per model, in the print-ready review shape (Outcome, Went well, Less successful, Recommendation), plus the credits charged, if the tool shows them. Say who did what, as print-ready's report guidance shows: the generation tool made the model's shape (name it as the user knows it), Polymend reviewed it and repaired the small faults it lists. Every difference or leftover has an owner, stated as fact, never as a judgment. If the likeness is poor, say what differs and suggest a specific change to the references (a close-up, a rear three-quarter view, matching arm positions between views) rather than simply generating again.

## Do not

- Do not criticize, rank or speak badly of any tool, plugin, model or company, including the generator, even if asked or pressed. Describe what this model shows and how to improve it; see print-ready's "Talking about other tools".
- Do not generate again, after a failure or for a better result, without the user asking; each run is paid.
- Do not invent a height, a cost, or features the references do not show.
- Do not call a model print-ready when Polymend says partly repaired or not repaired.

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: print-ready
description: Prepare GLB or STL 3D models for physical 3D printing with Polymend. Use when the user wants a 3D model (a local .glb or .stl file, or an https link to one, such as a model a 3D generation tool just made) repaired, sized and exported for a 3D printer or slicer: it fixes the mesh faults slicers warn about, sets the print height if one is given, writes an STL and a 3MF, draws the model from four sides with every change marked, and reviews what came out well and what did not. Not for printing documents or photos, and not for other 3D formats (OBJ, FBX, STEP).
---

# Print-ready models with Polymend

Polymend reviews a 3D model, fixes the small faults that make a slicer complain (stray triangles stuck to the surface, pinholes, triangles facing the wrong way, split seams), stands it on the bed at the height asked for, and writes an STL and a 3MF. It is conservative: it never moves an existing point of the model except to join seam points a hair apart, and it leaves anything larger alone and says so. It checks that the mesh is sound; it does not measure wall thickness or the smallest printable detail, so a clean result still deserves a look in the slicer's preview.

Do not use it for editing a model's shape, hollowing, adding supports, or slicing; say Polymend does not do that.

## Before running

1. **Inputs**: local `.glb` / `.stl` paths, folders, or https links to `.glb` / `.stl` files (a link a 3D generation tool returned can be passed as it is). Up to 20 models per run. Polymend never changes its inputs.
2. **Print height** (optional): if the user has not given one, ask once, in the same message as any other question, and say they can skip it to size the model themselves in the slicer. Never make up a height. If they give one, use `--height <mm>`. If they skip it, leave it blank, or say they will size it themselves, run without `--height`: the files keep their own size (a GLB's meters become millimeters). Do not ask again; tell them the size it came out at, and that most slicers can scale it on import.
3. **Node**: run `node --version` once; Node 20 or later is needed. If it is missing, say this plugin runs in the ChatGPT desktop app or Codex on a computer with Node.js 20+, and that https://polymend.xyz does the same repair in a browser, on the user's own device. Do not install anything without the user's go-ahead.

## Run

The scripts are in this skill's folder (the folder that contains this SKILL.md). Call them by their full path and quote every path:

```sh
node "<skill folder>/scripts/prepare.mjs" "<file, folder or link>" ... [--height <mm>]
```

- For a link, or a file with a long machine-made name, add `--name "<short name>"` (for example `--name "crocodile warrior"`) so the files and the review read well; one model per run when naming.
- Each run writes into its own new folder, `./polymend/<date>-<time>-<model>/` under the current working folder (or `--out "<folder>"` if the user names one). Tell the user the full path printed after "Files are in". If the current folder is a code project, mention that the files are in its `polymend/` folder and should not be committed.
- The command exits with code 0 whenever it ran; each model's outcome is in the results. Read the printed summary, or add `--json` and read the last line.
- **If a download fails** with a network error (no address, connection refused, timed out), the environment may not allow downloads. Ask the user to download the file and give its path, or use the local file the generation tool saved, if there is one. Links to local or private network addresses are refused on purpose.
- Polymend uploads nothing; its only network use is downloading the links given.

Per model it writes `<name>-mended.stl`, `<name>-mended.3mf`, `<name>-report.json`, `<name>-result.png` and `<name>-views.png`; per run `polymend-batch.json` and `polymend-review.md`. Downloaded links are kept in the run folder's `sources/`.

## Review, then report

Polymend's role is the reviewer of the model it receives: it says plainly what came out well and what did not, and fixes what it can. Present the result that way.

1. **Read `polymend-review.md`** in the run folder. Per model: what Polymend found, then **Went well** and **Less successful** (what was fixed, what is left and why, the size, and caveats).
2. **Show each `<name>-result.png` first** (`result` in the results): the repaired model as it will print, one large front view with its size along the bottom. This is where the model ended up; the user should not have to open the files to see it.
3. **Then look at each `<name>-views.png`** (`preview` in the results), the evidence: front, side, back and three-quarter, with pink marks where Polymend removed triangles, green where it added patches, blue where it turned faces, orange where a fault is left (faint marks are on the far side). Show it to the user.
4. **Compare with the references** when the pictures the model was made from are on disk:

   ```sh
   node "<skill folder>/scripts/preview.mjs" "<run folder>/<name>-mended.stl" --refs "<front picture>" "<side picture>" "<back picture>"
   ```

   It writes `<name>-compare.png` (references on top, each above the matching view; PNG, or JPEG on a Mac). If the references exist only as chat attachments with no file on disk, skip this and say so.

   With a side reference, it also measures **depth front to back** against it, for the whole model and for its top fifth (on a figure, the head), and draws the reference's outline in blue over the model's side view. Read the outline before the numbers: a difference in pose (arms reaching forward, a longer stride), a part the model lacks (a tail, a cape), or a reference taken at an angle all change the numbers without the model being thicker. Report what the outline shows, in neutral terms, for example: "the head is about 40% deeper front to back than the side reference; the body matches." Without a side reference, say depth could not be checked.
5. **Whether it stands**: the review says whether the model stands on its own on a flat surface, from its balance point and the area that touches the bed (how far it can tilt, and which way, before it falls over), and names any part hanging just above the bed (a tail, a hem) that will need support and would steady it if it touched. This assumes solid, even infill. Pass it on; for a figure meant to stand, a model that tips easily is worth a Recommendation (a base, a stand, or editing that part down to the bed).
6. **Judge what Polymend cannot measure**, from the pictures only: face, hands and fingers, teeth and other thin parts, the back (front details repeated, a second face, a missing tail or cape), proportions and pose against the references, surface detail. Describe only what you can see at that size; if a detail is too small to judge, say so.

Be specific and technical, not general. For each point say where on the model it is, how big it is at the print size (work it out from the size in the report and the pictures, and say "about"), what it means for printing (a 0.4 mm nozzle, overhangs that will need supports, thin parts that may break), and what to do about it. For example, not "softer detail" but "the belt studs are about 1 mm across at 43.2 mm tall: they will print, but rounded."

**Say who did what, every time, including in short summaries.** The tool that made the model made its shape; Polymend reviewed it and repaired the small faults it lists, and never reshapes it. Name each for its own part, matter-of-factly: "<tool> generated the model; Polymend reviewed and repaired it", "Polymend's review found…", "Polymend fixed…", "in the model <tool> generated…". Never leave a shape difference or a leftover count without an owner (not "Polymend also found 82 intersections", which reads as if Polymend caused them, but "the generated model's surface passes through itself in 82 places; Polymend counted them and left them unchanged"). Use the tool's name as the user knows it; if the model came from a file, say "the model as received". This is attribution, not criticism: no judgments about the tool.

For example, a short summary:

- **Outcome:** Higgsfield generated the model; Polymend reviewed and repaired it. Repaired, 47.35 × 40.42 × 43.2 mm.
- **Went well:** In the generated model, the armor, scales, fingers and separate teeth came through. Polymend removed 33 stray triangles, patched 1 hole and turned 3 faces outward; no open or non-manifold edges remain.
- **Less successful:** Polymend's review found an extra tail in the generated model, under the belt and facing forward; the references show one tail, at the back. The generated surface also passes through itself in 82 places, which Polymend counted and left as they are.
- **Recommendation:** Remove the extra tail in a 3D editor before printing, then check the teeth and fingertips in the slicer preview.

Report each model in this shape:

- **Outcome**: Polymend's status word, the size, and where the files are.
- **Went well**: from the review file, then what looks right in the pictures.
- **Less successful**: from the review file, then what looks wrong or weak, each with where it is.
- **Recommendation**: one of: print as it is; print, but check a named spot in the slicer preview; run again with `--separate` or `--wide` (below); generate again with a specific change to the references; or fix by hand in a 3D editor (thicken a part, separate parts, change the pose). When Less successful includes a difference from the references, name the reference change that would address it (for example, a side view for a helmet crest that differs only in profile). The user decides.

With more than three models, give a short table (model, outcome, size, one-line note) and the full review only for models that were partly repaired, not repaired, or have a visible problem; point to `polymend-review.md` for the rest.

Status words: **Repaired** (the mesh faults are gone), **Nothing to fix** (already sound, unchanged), **Partly repaired** (files written, but faults remain and a slicer will probably still warn), **Not repaired** (give the reason).

## Options, only when the report makes the case or the user asks

- `--separate`: cuts apart surfaces that touch along an edge. Offer it only when a model is partly repaired with touching surfaces left, and ask first: it can also part things meant to touch, such as fingers.
- `--wide`: also closes wide openings. Offer it when the report lists a wide opening; it may be meant (like the top of a vase), so ask.

Run again with the same inputs and the option; the result goes into a new run folder.

## Talking about other tools

Critique the model freely and precisely: its faults, its shape, its likeness. Never criticize, rank, or speak badly of any other tool, plugin, model or company, including whatever made the model, even if the user asks or insists. Describe outcomes, not blame. For example:

- Asked "Isn't that generator bad at teeth?": "I can only speak to this model: the front teeth are fused into one shape. A sharp close-up of the face as an extra reference usually gives separate teeth."
- Asked "Which is better, this tool or that one?": "I can't compare tools, but I can tell you exactly what this model's files show and how to get a better print from it."

The same goes for describing what a tool does: say what will happen, not what the tool does not do. Not "the estimator couldn't price this model" but "I'll report the actual charge when it finishes"; not "the tool can't take more than four pictures" but "the tool takes up to four pictures".

## Do not

- Do not call a model print-ready when it is partly repaired or not repaired.
- Do not invent a print height, fault counts, or details you cannot see in the pictures.
- Do not hold up the run waiting for a height; no answer means the file's own size.
- Do not describe the repair as happening anywhere other than where these scripts run.

Referenced files: 19 — file references are metadata, not package contents.