Wireframe-3D

What does Wireframe-3D do?

Turn a physical object or production process into an observable, disassemblable, and explainable 3D work. Allocate production focus based on the user's goal: structural explanation prioritizes mechanism explanation; reference reconstruction prioritizes restoring visible appearance first, then adds needed structure, motion, and interface.

The goal is accepted against two criteria: structure/interaction usability and reference appearance/visual expression match. The former does not substitute for the latter; previous case results do not automatically prove quality for a new subject.

When the user provides images and requests modeling, replication, or feedback such as "doesn't look right/unusable," read Reference Reconstruction and First Delivery before choosing a construction method, applying templates, or generating the main body. First confirm the contours, surfaces, openings, and materials that determine recognizability; do not automatically switch to a simplified explanatory style just because this skill is invoked. In a single user request, proactively complete rendering, visual review, and necessary rework, without waiting for the user to act as the first visual inspector.

When executing this branch, read Reference Modeling Tools: use source records to pin reference basis, use patch surfaces / real openings / surface attachments as needed, then generate a gray model with locked camera and material comparison. Passing tool checks does not replace visual inspection.

When a continuous shell (e.g., vehicle body) is reported as overly simplified, read Iterative Repair of Continuous Shells: first reconstruct independently controllable shapes and shared boundaries, diagnose mesh quality after cutting openings, then repair lamp cavities and continuous paint layers; keep corresponding source code and fixed views for each round.

When a reference product requires material layers, attached components, or many repeating details, read Practical Integration and Acceptance for Product Modeling: materials must take effect on the delivered mesh, geometric joints must be configured for actual checks, and static batching must not break semantics, motion, or measurement objects. Save the baseline before improvement, then preserve actual rework within the same reference task; cases already used for tuning are development validation and cannot be relabeled as independent blind tests.

When creating structural or motion explanations, read Migration Workflow from Anatomy: determine "action → component change → observable result," and refine detail on functional interfaces, guides, terminations, and negative spaces. The production method and the Three.js implementation of this skill trace separately; do not directly copy the upstream SVG sorting system.

Choosing a Delivery Route

• If the user specifies an engine, follow that. If unspecified and an interactive webpage is needed: default to Three.js, read Three.js Route.
• Choose the web delivery engine and geometry production method separately. For continuous complex surfaces, first verify the construction can express the key shapes; if necessary, make an editable mesh in the available Blender, then import it to the web. When the user requests purely procedural modeling, abide by that constraint and choose a method that can express local surfaces and openings; do not simply increase the sample count of simple extrusions.
• For editable engineering files, offline rendering, or camera animations: use Blender, read Blender Route.
• For dual delivery: share component IDs, geometry, and state semantics, validate both ends separately; a single run does not imply another engine passes.
• For ordinary product modeling without structural explanation, the installed threejs-modeling-studio may be used; this skill does not require its existence.
• When changing the subject or the model doesn't look like the reference, read Subject and Construction Methods. For architecture, first handle plans/elevations/sections, massing/openings, and site context; for machinery, first handle contours/axes/cavities; for factories, first handle workstations and material flow; choose the branch according to the actual task.

From Reference to Structure

When starting a new work or doing a full rework, first write one sentence summarizing what the audience should understand from the view, and from the user's requirements extract "must appear / must remain / must not appear / delivery format." Record the actual viewing size and default state; reuse existing requirements without repeatedly asking to fill forms. Create according to Visual Comparison and Rework; you may reuse Production and Delivery Check Record; for small changes, only update affected items.

1. From the user's question, determine the actual needs for appearance reconstruction, structural explanation, and motion demonstration. For reference modeling, first lock the shape and key visible features; for mechanism problems, then determine which internal parts must be visible. Internal mechanisms, operational animations, and control panels not requested are not automatically the focus of the first round.
2. Create a short component table: id / function / parent assembly / parameters / connected objects / motion / source. For mechanism problems, first determine ownership, connections, and causal paths, then choose cutaway, exploded, or leader-line expression; record the source verification of the mechanism principle and whether the animation can run separately. Separate real components, visual aids, and schematic particles. For factories, additionally list workstations, material paths, intra/inter-level transfers, and process conditions.
3. Prefer using drawings or real models when available; if no dimensions exist, state a schematic scale and maintain consistency of internal parameters. Do not claim original examples as the original engineering, reconstruction result, or public model of the reference work.
4. First build volume, contour, connections, and internal cavities; then add functional details. Make holes as real openings, pipes with wall thickness, and supports that show load-bearing relationships. Do not replace core mechanical structures with a set of labeled cuboids.
5. Determine modeling budget based on the actual goal, visibility, and recognizability; do not use fixed part counts or fixed man-hours. For complex surfaces, use appropriate patch surfaces, subdivision meshes, cross-section lofting, revolution, sweep, or reliable assets; first verify representative parts, then expand to the whole. Document asset sources and procedural modeling contributions separately.
6. When the user asks to reconstruct an existing work, first create a table "reference feature → source file/function → implementation → screenshot/state evidence," locking comparable cameras. Both overview and close-up views must pass; the number of source records cannot substitute for shape similarity. See Reference Fidelity and Animation Verification for specific steps.
7. First align gray model with main contours, negative spaces, and connections; then add construction, materials, and lighting; record assumptions when source data is insufficient. Record matches, differences, and unchecked items separately according to Visual Comparison and Rework; if key shape issues are found, continue repairing the model.

When migrating factory HTML, read Original Display Code and Device Restoration: recover robotSvg/toolSvg shells and cross-section orientations per workstation, verify draw() outer layer time offsets and load gating. First accept representative workstations, then expand by stable ID; assets/lib/source-frame.js provides rectangular arm segment orientation. Case-specific state and devices cannot be treated as automatic generators for arbitrary subjects.

Must-Maintain Relationships

For new subjects with interfacing fits, sliding parts, or piping, read Interface and Assembly Checks, use assets/lib/assembly.js to deliver interface coordinates, normals, diameters, relationships, and real mesh checks together. pass only covers configured rules; mark un-budgeted/unconfigured items explicitly. Test checker with counterexamples like intentionally disconnected interfaces or incorrect actual aperture.

Audit and preview must reference the same root, semantic components, and their real meshes; off-tree copies, selection boxes, or audit envelopes cannot substitute. Maintain independent references for hole/face probes; intentionally altered actual components must be detected. Whether display details are complete still requires close-up visual assessment.

• A single parameter source generates geometry, assembly position, animation, and readings. rest + explode * offset is the basic disassembly model; reset returns to the saved rest pose, avoiding accumulated translation.
• Animation first lists states and transition conditions, then rendering. Start after disassembly; wait for the assembly to actually converge before playing the operational cycle; pause freezes springs, noise, particles, and readings; if shutdown has a tail, do not directly delete effects. When staggered springs are needed, drive by independent component states, not by using slider target values as actual positions.
• Web: prioritize reusing assets/lib/motion.js and scene-runtime.js, so that UI, state sampling, and screenshot checks all go through the same setPose; complex cycles can extend pure state modules. Read Shared State and Replayable Verification to avoid rewriting clocks per case or accumulating displacement in repeated calls.
• Place pivots on the actual rotation axis or assembly interface; child parts move with their parent assembly. Name parts before making interactions; do not guess objects by creation order.
• When encountering overlapping expansion, black cut planes, thin blade backfaces, or motion misalignment, read Explosion and Motion Repairs: configure phases by semantic module, check actual mesh spacing and inject overlap counterexamples; do not just check buttons or percentages. The runtime applies expansion after setPose; avoid duplicate displacement when migrating old code.
• Process flow adheres to real paths and current state. Disconnected joints after disassembly should not continue to show "unobstructed" logistics or fluids; hide flow lines or convert them to explicit dashed annotations.
• Component hiding, transparent observation, clipping planes, and solid cutaways with caps are different functions; name them according to actual implementation. Clipping planes without caps should not be claimed as solid cut-away.
• Schematic phases and demonstration speeds can be shown; actual RPM, temperature, flow, cycle time, pressure, etc., require source or calculation. Particle flow is not CFD; gear rotation is not dynamics simulation.
• Factory scenes are organized by floor/workshop/workstation, then map process states to equipment and materials. Process descriptions come from documentation; visual grouping is an implementation choice; do not confuse them.
• For factory migration, verify draw() outer layer offsets, HOME windows, and load attribution. You may reuse the independent clock and boundary sampling from assets/lib/process-timing.js; check one frame before, at, and after each transition point; do not use equal-interval sampling to skip boundaries.

Visual and Interaction

When both original projects' visual styles must be maintained, read Unified Illustration Rendering, use illustrationPalette() and renderStyle:'anatomy-light'. Share paper surface, controlled normal shading, depth-tested fine outlines, and semantic accent colors; compare final screenshots at the same camera position; do not substitute equal color values or test pass for style acceptance.

For structural explanations without specified appearance style, inherit Anatomy's clear outlines, restrained materials, and semantic accent colors. For reference reconstruction, the style is determined by the reference and user requirements: realistic products explicitly select appropriate lit materials and renderStyle:'studio' as a starting point; use anatomy-light only when illustration expression is needed. Switching styles cannot fix incorrect surfaces; actual visual inspection is required.

For structural explanation, the first screen should show the main body, key internal structure, and understandable motion; for appearance display, the first screen should primarily show the full assembly's main body, not using fully transparent shells to show unsupported internal structure. Provide sufficient space for the main view; labels follow real part positions, filtered by occlusion and screen space; avoid dozens of leader lines on one screen.

Web typically provides rotate/zoom, disassembly/assembly, part selection, pause/reset; factories add per-floor and per-process filters as needed. Native form controls are keyboard-accessible, respect reduced-motion, and pause computation when off-screen or page hidden. Do not add dashboards unrelated to the explanation just for feature padding.

Default web starting point uses a compact top bar, label panel, persistent demo controls, and focus mode; expand complex explanations on demand. When creating or optimizing the preview interface, read Preview UI, reuse assets/web/preview-ui.css / preview-ui.js, and check model framing safety margins and narrow-screen usability. Layout can be adjusted per user style.

Runnable Starting Points

For new Three.js subjects, prefer using buildScene() independent builder and prepare_web.py --builder; default preview works by passed component IDs, no longer needs to borrow hub/rotor/cover from a pump. Read Component Library and Subject Interface, call assets/lib/ for hollow revolved shapes, variable-diameter pipes, flanged openings/floor slabs, stone wall openings/window frames, gentle slope river channels, and camera/lighting tools. These are modifiable primitive components, not automatic modelers for arbitrary objects.

--example river-pavilion / --example flanged-chamber are original building/mechanical tool verification problems; they cannot replace user-specified reconstruction targets. Existing scripts/make_demo.py, prepare_web.py --scene, and build_blender.py retain the centrifugal pump shared manifest route. New JS components and generic preview do not automatically support Blender; implement and validate separately.

--example pneumatic-press provides a new example of interfaces, actual mesh features, travel, connection diagram, and illustration rendering. New JS interface checks and shaders are not automatically migrated to Blender; do not write web verification as dual-engine verification.

--example contact-switch provides an independent 3D reconstruction of Anatomy's button mechanism: real guide holes, variable-pitch spring, six terminations, wire-to-board clearance, and actual contact gap-driven readings. This is a development example; it cannot be treated as a blind test result for all new subjects.

--example indexed-workcell is an original process development example demonstrating different device builders, independent cycles and HOME, material ownership, and multicolor dynamic cache. Reuse explicit device mapping and conditional sampling from factory-process.js; unknown devices cannot silently degrade to generic cubes. Run verify_migration.py --three <three-path> --report <JSON> to check these relationships against color/palette counterexamples, then visually inspect the page.

• Shared Data Contract: coordinates, geometry, state, and verification boundaries.
• Source and Migration Map: heuristics, re-implementations, and attributions precise to upstream files/functions.
• When the user specifies an existing open-source case, read 3D Migration of Existing Works: display geometry and audit proxy, pure state extraction, instantiation, and real browser verification.
• scripts/validate_scene.py: checks IDs, finite numbers, degenerate faces, closed meshes, and positive oriented volume. Only checks applicable closed solids; open surfaces require rule adjustments and explanation.
• After modifying interface checks, run scripts/verify_assembly.py --three <installed-three-path> --report <output-JSON>, then configure actual holes/faces/gaps and error counterexamples for the new subject; currently only Three.js checks are implemented.
• After modifying shared JS components, run scripts/verify_components.py --three <installed-three-path> --report <output-JSON>, verify openings, wall thickness, different sizes, and camera safety zones; then actually open affected examples. Numerical checks do not assess aesthetics.
• After modifying explosion or camera framing, run scripts/verify_explosion.py --three <installed-three-path> --report <output-JSON>; configure explosionChecks for the actual subject and verify with verify_scene.py; unconfigured items cannot pass. Preview using serve_preview.py --root <output-dir> --port <start-port>, binding only to localhost free ports and disabling development cache; reload to check current output after generation.
• For a new subject, run scripts/verify_scene.py --builder <subject.js> --three <installed-three-path> --report <output-JSON>; then operate and screenshot using browser tools available in the current environment. If independent browser automation is available, run node scripts/verify_preview.mjs --url <local-preview-url> --out <evidence-dir> to record screenshots, states, and errors, then manually review images. Usage, tool limitations, and scope are described in Shared State and Replayable Verification.

Do not copy the entire upstream repository into the runtime project just to use a skill. Upstream iso-kit, tube, lathe are SVG generation systems; this skill's Three.js/Blender geometry, depth testing, and interaction are independent implementations.

Acceptance and Delivery

Execute based on actual functionality and retain verifiable results:

1. Geometry: Check parameters/IDs/units/finite numbers; key holes, wall thickness, axes, contacts, and gaps have targeted verification. Data checks cannot replace image checks.
2. State: Check assembled, semi-exploded, fully exploded, and reset states; runtime readings match geometric phase; pause does not cause jumps. Collision detection only for expected non-contacting part pairs; do not flag normal assembly contacts as errors.
3. Image: At actual viewing size, check default first screen, main view, back/side views, verifying subject proportion, occlusion, interpenetration, floating, material differences, shadows, and text readability. Test one narrow screen on web; reopen .blend file in Blender to check objects, drivers, and frame state. For works with an original, add same-camera overview and functional close-up comparison; for transparency, smoke, or fire, check front/back occlusion and shutdown process. After geometry and pure-state pass, still compile shaders and observe the actual rendered image.
4. Delivery Read-Back: Reopen the entry point or file the user will receive, and in the target viewer record PASS / FAIL / NOT_RUN per the four categories of requirements. For exports, check native project, exported files, and final carrier separately; for animations, play through the complete user flow, verify actions, text, and readings; frame sampling does not replace continuous check. Inspect console or Blender logs; report performance only after measurement.

Current Three.js templates generated by prepare_web.py produce file hash manifests and build-info.js. Use verify_preview.mjs --expect-build <manifest-id> to bind screenshots to actual version, page, camera, state, and read-back viewport; images still require manual inspection. When the viewport or version cannot be read, do not reuse old screenshots as new results. After batch instance changes, update matrices and counts of faces and contours; preserve source material semantics; do not create detail by thickening all thin rods.

Deliver the entry point, editable source, necessary resources, and a few key screenshots. Report source facts, original/adapted parts, performed verifications, and unchecked items. When the user requests a reconstruction, match the actual reference; do not substitute with the bundled pump example.

When there are exports, multiple versions, or explicit delivery requirements, read Evidence and Delivery Tools: align requirements with final read-back, bind source code and screenshot hashes, prevent stale records; start local preview on exclusive ports, retain version with validated independent snapshots. Tools can only check evidence association and file integrity; they cannot automatically judge visual fidelity.

When iterating the skill itself, select independent problems and actual inputs from evals/evals.json based on the change; these are evaluation prompts to run, not pass records. Record development examples, historical regression, and new subject evaluations separately; avoid generalizing conclusions by repeatedly tuning on the same case.