PDE — Packaging Dieline Editor with 2D/3D Live Preview

Background

Packaging design for折叠 cartons (folding cartons) involves working with dielines — flat layouts that show where cuts, folds, and glue areas will be before the box is assembled. Traditionally this is done in Illustrator or specialized CAD software. I wanted to see if I could build a web-based tool that lets designers edit dielines visually and see the finished 3D box fold in real time.

The project is a live proof of concept: github.com/haku-d/pde

Note: All source code in this project was AI-generated by different models. I’m treating this as an experiment — I’ll share what worked, what didn’t, and what I’d do differently.

What PDE does

PDE has two editor surfaces:

1. Parametric Dieline Editor

The default route. Feed it dimensions and closure parameters — length, width, height, flap types, tuck flap geometry, dust flaps, glue flaps, material thickness, fold allowance, bleed, safe area — and it generates a complete card-box dieline from the card-box-basic model.

From a single set of parameters you get:

• Stable panel IDs, cut lines, fold lines, bleed paths, safe-area paths
• Validation issues if the geometry is invalid
• A compiled shape that the shared renderer can preview in both 2D and 3D

Editor controls include unit switching (mm, cm, in), debounced live regeneration as you edit fields, per-guide visibility and color toggles, and a JSON or SVG export.

2. Dieline-to-3D Editor

Loads fixed template JSON files or imports annotated SVGs, then renders the same 2D canvas texture onto a foldable 3D preview. The SVG importer recognizes common dieline line classes — cut, fold/crease, bleed, safe-area, dimension, construction, glue-area — from the SVG metadata.

The 2D/3D renderer pipeline

Both editors share a renderer pipeline I built as part of this project:

• Canvas-based 2D rendering — renders trim, crease, bleed, safe-area, dimensions, panels, and demo artwork onto a <canvas>
• Texture canvas generation — builds the material texture for 3D panels from the same 2D data
• Three.js panel meshes — UV-mapped panels with material thickness
• Fold graph construction — builds the fold order graph so the 3D animation knows which panel folds into which
• Fold animation — open/close controls with a fold progress slider
• Viewport — pan, zoom, fit, and keyboard navigation in both 2D and 3D views

Project structure

src/app/                  Next.js App Router pages and template API
src/components/           Shared editor layout and canvas UI
src/editors/             Client-side editor orchestration
src/core/models/         Parametric model registry and field definitions
src/core/parameters/     Parameter and dimension helpers
src/core/structure/      Fold graph and structural validation
src/core/template/       Template compiler, schema, serializers, SVG importer
src/core/units/          Unit conversion utilities
src/render2d/           Canvas renderer, hit testing, viewport, SVG export
src/render3d/            Three.js scene builder, preview, fold animation

Running it locally

git clone https://github.com/haku-d/pde.git
cd pde
npm install
npm run dev
# → http://localhost:3000 redirects to /editors/parametric-dieline

Available routes:

• / → redirects to parametric editor
• /editors/parametric-dieline → parametric folding carton editor
• /editors/dieline-to-3d → fixed-template and SVG-import editor
• /api/templates/[templateId] → serves bundled template fixtures

What the AI-generation experiment taught me

This whole project was generated by AI — different models for different parts. Here are a few honest observations:

What worked well:

• Boilerplate-heavy modules (parameter engines, unit converters, test suites) were generated quickly and mostly correctly
• The Three.js scene/fold animation was cleaner than I expected given how much boilerplate it requires
• Test scaffolding for core geometry was solid enough to build on

What needed heavy manual correction:

• SVG import heuristics — the “recognize common dieline line classes” logic required significant manual tuning
• The fold graph construction had edge cases around multi-panel folds that required rethinking the data model
• The parametric model’s validation logic had boundary condition bugs that only surfaced when testing with real-world dimension ranges

What I’d do differently:

• Start with the data model for the fold graph before any rendering code — it’s the foundation everything else builds on
• Treat the 2D canvas renderer and the texture generator as one module, not two — keeping them in sync manually is error-prone
• The 3D panel mesh UV mapping was the hardest part — I’d invest in a dedicated UV-atlas step instead of trying to share canvas coordinates directly

Current state and next steps

PDE is an active proof of concept, not production software. The current limitations:

• Only one registered parametric model: card-box-basic
• The 3D preview is an MVP renderer, not a manufacturing simulator
• SVG import is deterministic for controlled/annotated SVGs and best-effort for arbitrary SVGs
• Production-grade CAD operations, artwork persistence, and multi-format export are still future work

The immediate next piece I’m working on is improving the hinges surface in the 3D preview — getting the fold animation to feel more physically accurate rather than just geometrically correct.

Source

github.com/haku-d/pde