added svg patch output

README.md

@@ -24,7 +24,7 @@ sensors/finger/
 ├── current.yaml              # active revision pointer
 └── r01/
     ├── design.yaml           # units, frames, object names
-    ├── source/geometry.blend # LFS: named collections + objects
+    ├── source/geometry.blend # named collections + objects
     ├── profiles/
     │   ├── compute.yaml      # → SDK bundle layout (Studio runtime)
     │   └── studio.yaml       # inputs for orisys-app compile_scene
@@ -34,9 +34,10 @@ sensors/finger/
 ## Prerequisites
 
 - Python 3.10+
-- [Git LFS](https://git-lfs.com/) on every client (`git lfs install`)
 - Blender version pinned in `blender.lock.json` (install separately)
 
+No Git LFS is required — binaries are committed as ordinary files.
+
 ### Finding Blender on Windows
 
 The CLI looks for Blender in this order:
@@ -113,8 +114,10 @@ build/export/finger/r01/
 
 ## Texture patches (headless)
 
-`orisys-design texture` generates one colored patch texture per UV map on the
-sensing surface. UV unwrapping is **still an in-app Blender step**: this command
+`orisys-design texture` generates a PNG, editable SVG, and native vector PDF for
+each UV map on the sensing surface. The SVG/PDF are built directly from the UV
+mesh and camera-space patch polygons — they do **not** embed or trace the PNG.
+UV unwrapping is **still an in-app Blender step**: this command
 consumes the UV maps already stored in `source_blend` and never creates or
 unwraps one. Unwrap the mesh in the Blender GUI, save the `.blend`, then run the
 command. A `.blend` saved in Edit mode is fine — the headless run enters Object
@@ -130,8 +133,12 @@ Output is revision-scoped, so nothing has to be copied by hand:
 ```text
 build/textures/finger/r01/
 ├── _texture_job.json           # Blender input, regenerated by texture (gitignored)
-├── patch_texture_produce.png   # from the `produce` UV map (tracked, Git LFS)
-└── patch_texture_compute.png   # from the `compute` UV map (tracked, Git LFS)
+├── patch_texture_produce.png   # raster preview/use (tracked)
+├── patch_texture_produce.svg   # editable grouped vector artwork
+├── patch_texture_produce.pdf   # vector production/print handoff (tracked)
+├── patch_texture_compute.png
+├── patch_texture_compute.svg
+└── patch_texture_compute.pdf
 ```
 
 `produce` is the hardware-production layout and `compute` the compute/runtime
@@ -140,15 +147,31 @@ share one set of settings and one seed, and both read the same camera-space
 patch grid, so a given physical patch carries the same colour in either file —
 the images differ only in how the unwrap arranges the patches.
 
-Generated PNGs are **committed** so a revision's textures can be synced to
-hardware production; `.gitattributes` already routes `*.png` through Git LFS
-(`git lfs install` / `git lfs pull` as usual). Only `_texture_job.json` is
-ignored, because it records absolute machine paths and is rewritten every run.
+Generated artifacts are **committed** so a revision's textures can be synced to
+hardware production. They are stored as real files, not Git LFS pointers, so a
+plain `git clone` yields usable images and `.blend` files; `.gitattributes` only
+marks binaries as non-text to protect them from line-ending conversion. Only
+`_texture_job.json` is ignored, because it records absolute machine paths and is
+rewritten every run.
+
+SVG imports into CorelDRAW as named groups (`background`, `mesh`, `patches`, and
+`reference-cross`) containing individual editable polygons. PDF contains the
+same filled vector paths on a correctly sized page, with no embedded bitmap.
+Seam-wrapped duplicate polygons are clipped to the page, so no stray objects sit
+outside the artwork.
 
 Defaults come from the `texture_patch` block in `design.yaml` — mesh, camera, the
-`uv_outputs` map (UV map → PNG name), texture size, patch grid, colour
-separation, edge sampling, reference cross, and an optional seed. CLI flags
-override the shared values for every output:
+`uv_outputs` map (UV map → artifact stem), raster dimensions, vector page size in
+millimetres, patch grid, colour separation, edge sampling, reference cross, and
+an optional seed. The current production page is configurable as:
+
+```yaml
+vector:
+  width_mm: 164
+  height_mm: 160
+```
+
+CLI flags override the shared rendering values for every output:
 
 ```powershell
 orisys-design texture sensors/finger/r01 `
@@ -162,11 +185,14 @@ blender -b sensors/finger/r01/source/geometry.blend -P blender/scripts/random_pa
   --job D:\orisys_ws\orisys-sensor-design\build\textures\finger\r01\_texture_job.json
 ```
 
-A single manual target is also possible (this cannot be combined with `--job`):
+A single manual target is also possible (this cannot be combined with `--job`).
+`--output` names the PNG; same-stem SVG/PDF files are generated alongside it.
+The vector page defaults to 164×160 mm and can be overridden manually:
 
 ```powershell
 blender -b sensors/finger/r01/source/geometry.blend -P blender/scripts/random_patch_dd02c.py -- `
-  --uv-map produce --output D:\tmp\produce.png --width 1024 --height 1024
+  --uv-map produce --output D:\tmp\produce.png --width 1024 --height 999 `
+  --vector-width-mm 164 --vector-height-mm 160
 ```
 
 Only the colored "patches" mode is reachable headlessly; the checker and dot
@@ -212,9 +238,17 @@ Example lock file: `examples/design-lock.json`.
 - **Objects**: `origin_sensor`, `sensing_surface`, `cam_sensor`.
 - **Matrix names** must state direction; exported pose file remains `world_to_cam.npy`
   for SDK compatibility (sensor frame → camera).
-- **Git LFS**: `*.blend`, large textures, exported `*.npz` in `build/export/`.
+- **Binary files**: `.blend`, textures and exported `*.npz` are committed as
+  ordinary files (no Git LFS). `.gitattributes` marks them `-text` only.
 
-## Git LFS on Gitea (NAS)
+## Git LFS on Gitea (NAS) — not currently used
+
+**Status: this repository does not use Git LFS.** `.gitattributes` only marks
+binaries as non-text, and real `.blend` / `.png` / `.pdf` bytes are committed
+directly. This is deliberate: LFS pointers are unusable without a reachable LFS
+server, so a plain clone or `git checkout` would hand you 131-byte files instead
+of images. The notes below are kept as a migration guide for when the NAS server
+is ready.
 
 **Short answer: not difficult.** Gitea has built-in LFS; NAS hosting is common. Plan for
 extra disk on the NAS volume that holds LFS objects, not just the git bare repos.
@@ -262,8 +296,10 @@ cd orisys-sensor-design
 git lfs pull
 ```
 
-This repo’s `.gitattributes` already tracks `*.blend` and large binaries. After
-`git lfs track`, always commit `.gitattributes`.
+This repo’s `.gitattributes` does **not** track anything through LFS today. To turn
+LFS on, add the extensions back with a filter (the file contains a ready-made
+example line), run `git add --renormalize .` so real bytes become pointers, and
+commit `.gitattributes` together with the renormalized files.
 
 ### Typical pitfalls
 
@@ -281,6 +317,6 @@ behind your NAS reverse proxy is the path of least resistance.
 
 | Phase | Goal |
 |-------|------|
-| **A** (now) | Repo + LFS + r01 + headless compute export |
+| **A** (now) | Repo + r01 + headless compute export |
 | **B** | Lock file in SDK/App + CI reproduces export hashes |
 | **C** (later) | Markers, camera metrics, simulation datasets |