KaiNinja’s Editable Parts: Inspecting Two Public GLB Files

KaiNinja is useful research to study when you want an image-to-3D result with separately selectable components. But “part-aware” needs a precise handoff contract. Our inspection of two public gallery GLBs found 15 separate mesh references in the dining chair and 5 in the ceramic teapot, with no skin or animation declarations in either file. Those are real file observations, not a model-generation test.[3][5][6]

Why native parts change the editing question

The paper extends TRELLIS.2 with two O-Voxel volumes. Its key argument concerns contact faces: one O-Voxel volume stores one surface sheet per voxel, so touching parts can lose their interface when packed together. Splitting touching parts across two volumes preserves capacity for both surfaces. The method produces parts without an input mask or a separate segmentation network.[1]

For a creator, the practical attraction is component-level work: select a lid, recolor a handle, or replace a foot without first extracting it from a fused object. That is an editing goal to evaluate. The representation alone does not tell you whether a particular lid separates cleanly or whether the resulting boundaries match your intended design.

What you can inspect today

KaiNinja was first submitted on September 14, 2026 and revised on September 15. This article examines that research and its current public artifacts; it is not an October launch announcement.[2]

At the October 3 check, the pinned repository roadmap marked inference code and pretrained weights as unfinished. The project page offered 14 curated outputs and labeled the model “Coming soon.” You can inspect the gallery, but these resources do not yet establish a released inference path for your own image.[4][3]

The gallery’s motion section explicitly describes downstream material styling and hand-authored animation. Do not treat that clip as evidence that KaiNinja automatically creates a rig or motion. This article submitted no inference request.[3]

What the two downloaded GLBs actually contain

We downloaded the gallery’s dining-chair and ceramic-teapot files and parsed their GLB headers and JSON chunks. The original report records the exact URLs, access timestamp, byte sizes, and SHA-256 hashes. A second inspection of the same bytes produced an identical report. The script does not decode compressed vertex or index data.[5][6]

Each specimen has one parent node named world and numbered children named Part 01 onward. Each child references its own mesh. The node extras also record volume and part_id values. The chair’s volume labels divide its 15 mesh nodes into 3 and 12; the teapot’s divide into 2 and 3. These are groups in two representation volumes, not a claim that the method produces only two parts.[5][6]

Those generic labels are a useful boundary: the file identifies a selectable component, but it does not name that component “lid,” “spout,” or “hinge.” The inspection also does not establish connected-component count, contact-face integrity, watertightness, or semantic correctness. A decoded visual and geometry review would be another test.

Separate meshes, rigging, and motion are different deliverables

In glTF, a node can reference a mesh and carry a transform. Skinning additionally uses skin objects, joint references, and vertex attributes; animation clips store channels and keyframe samplers. A rigid part can move through node animation without a skin. Therefore, zero skins alone would not prove an object cannot animate.[7]

Here, both files also have zero animation declarations and no nodes referencing skins. The narrow finding is that these two specimens contain separately referenced static meshes, with neither declared skinning nor embedded animation clips. External code could still move them. That possibility is different from an authored pivot, hinge constraint, or validated mechanism being supplied.

Define the edit you need before evaluating a part-aware asset

Start with one intended change, such as lifting a teapot lid. Write down which component should move, which surfaces must remain intact, and where its motion should originate. Then review the actual file against that contract. The following checks are proposed; they were not executed in a 3D editor for this article.

1. 1

   Identify the component

   Select the intended mesh and give it a meaningful local label. Check whether one numbered part contains several design elements or whether one intended component is split across several meshes.

2. 2

   Inspect the joining surfaces

   Separate the component and inspect both sides of the contact. Look for missing faces, duplicate shells, and small fragments before treating the boundary as usable.

3. 3

   Preserve placement and set the pivot

   Record the assembled transform before editing. Choose the intended rotation or translation origin explicitly; a selectable mesh does not establish a correct mechanical pivot.

4. 4

   Test one bounded edit

   Lift the lid or change one material, then restore the assembly. Check adjacent parts and save the edited version separately from the source.

5. 5

   Add the behavior contract

   For a moving prop, define joints, limits, collision shapes, and playback in the target application. Accept the behavior only after testing that specific handoff.

The paper itself reports undersegmentation, collapse into one volume, duplicated surfaces, and occasional small holes. It also describes explicit control over part count and granularity as future work. Keep the chosen edit narrower than a promise of fully controllable assembly.[1]

Reproduce the file facts and keep their limits

Download the report and inspector from the evidence links below. Save the two source GLBs using the URLs in the report, then run the command with the report’s recorded accessedAt value. The script checks hashes first and stops if a source file has changed. It uses Python’s standard library and does not install a renderer or call a model.

python3 inspect-glb.py chair.glb ceramic-teapot.glb \
  --accessed-at 2026-10-03T16:13:34.903Z

Both files require Draco mesh compression. Reading their JSON remains possible without decoding the geometry, but loading the shapes requires a compatible decoder. Our report measures declarations and references only; no importer, contact-surface test, animation playback, performance measurement, or generation-quality comparison was run.[5][6][7]

The download package contains original analysis and code, not the third-party meshes or gallery pictures. The inspected KaiNinja repository snapshot contains no root license file; a public gallery link does not settle reuse permission. Check the applicable terms for any model or asset you intend to use.[8]

The useful result is a clearer requirement: ask for the exact component, its intact boundary, a usable pivot, and the behavior your project needs. Native part meshes address the first part of that handoff. The remaining work becomes inspectable once you describe one concrete edit.