Experiment notebook / Internal review
Keep the failures.
Reuse the lessons.
These are actual rejected outputs from our tests. They explain why we changed direction—not why a tool could never work. Historical screenshots contain superseded demonstration dates and numbers.
01 / Generated geometry and photo projection
TRELLIS.2: more detail did not repair the body.
The first attempt timed out during decoding. A later shape-only retry completed after temporarily unloading the local language model. That was a runtime success—not a finished person.
Later photographs projected onto the TRELLIS-derived mesh still showed patchy hair, overlapping arm surfaces and broken texture continuity inside the app.
Lesson: approve the plain 3D shape from every angle before investing in its texture.
This is surface-bake candidate r9, a combined reconstruction and photo-projection experiment. Do not attribute every defect to TRELLIS itself. The original timeout was not a confirmed OOM.

02 / Geometry-guided texture generation
Hunyuan: the front passed a glance.
The rear lost its clothes.
Four generated views used the same body and its shape guides. The front retained a bra and pink shorts; the rear lost both. A second test with front and rear references still failed and misplaced fabric on the front shorts. We stopped before another full texture bake.
Show the rejected front and rear outputs (unintended missing clothing)
Lesson: test clothing continuity around one difficult region before generating a whole texture. Preserving UVs—the map connecting the image to the body—does not guarantee consistent clothing.
These are generated texture views, not final app captures. The installed wrapper did not explicitly assign front/rear reference camera IDs; this test does not rule out better-controlled multiview methods.
03 / Editable licensed human
Human Generator: a stronger base still needed app QA.
The rigged body and editable proportions made revisions repeatable. But the early app capture still had speckled hair, eye artifacts and flat-looking skin.
Lesson: a good source model is only half the job. Check its materials, hair and eyes after export into the real app.
Right: male trial model. Left: an older female fixture. This mixed diagnostic screen is not a before/after transformation. TRIAL marks belong to the license; they are not visual defects. Later commercial iterations improved the result.
Import and tape failures were separate
A GLB compatibility fix made a rejected body load successfully. It did not improve the body. A small outward tape offset also failed to fix segmentation; more offset was not an established solution.

04 / Proposed test, not a demonstrated improvement
Could the viewer show more of the detail we already have?
Yes, potentially. In the local app code we inspected, one scan-loading path halves the color texture's width and height. A controlled full-resolution comparison is the simplest useful next test. It could help existing scans whose stored textures contain more detail, without a new scan.
- Hold the scan fixed. Same body, source texture, camera and measurements.
- Compare half and full texture resolution. Check whether that code path runs, and verify texture proportions.
- Watch a matching rotation. Inspect detail and measure memory, frame time and loading on an iPhone.
- Then test materials separately. Hair, eyes and skin may need different treatment for synthetic people versus fused real scans.
Limit: display improvements cannot create detail the scanner never captured. Full-size textures use about four times the texture's uncompressed pixel storage. Baked lighting also makes extra lighting a potential regression.
Estimate: hours for a focused resolution comparison once a test build is ready; days for broader material work and device checks. This is a proposal, not a completed test or a promise that every scan improves.
Back to the nine steps
