orisys-tech/orisys-sensor-design
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

adde produce + compute texture export

Browse Source
This commit is contained in:
ykcheungab
2026-09-18 11:25:09 +08:00
parent 026f495f77
commit b1815b15ea
9 changed files with 503 additions and 161 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+28 -11
View File
@@ -113,10 +113,12 @@ build/export/finger/r01/
## Texture patches (headless)
`orisys-design texture` generates the colored patch texture headlessly. UV
unwrapping is **still an in-app Blender step**: this command consumes the UV map
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.
`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
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
mode in memory and never writes the file.
```powershell
orisys-design texture sensors/finger/r01
@@ -127,18 +129,26 @@ 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.png # colored patch texture (tracked, Git LFS)
├── _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)
```
Generated PNGs are **committed** so a revision's texture can be synced to
`produce` is the hardware-production layout and `compute` the compute/runtime
layout; they are the two UV maps authored on `sensing_surface`. Both outputs
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.
Defaults come from the `texture_patch` block in `design.yaml` — mesh, camera,
texture size, patch grid, colour separation, edge sampling, reference cross,
file name, and an optional seed. CLI flags override every value:
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:
```powershell
orisys-design texture sensors/finger/r01 `
@@ -152,11 +162,18 @@ 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`):
```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
```
Only the colored "patches" mode is reachable headlessly; the checker and dot
helpers remain in `random_patch_dd02c.py` but are not exposed by the CLI. The
default 3280×3200 grid matches the in-app script and is deliberately slow
(pure-Python rasterization) — use smaller `--width/--height/--nx/--ny` for quick
check runs, and the full default grid for the texture you actually ship.
check runs, and the full default grid for the textures you actually ship.
Collection check: