Animated Mascot Character: 2D Widget & 3D Model

01Executive summary

We propose to build the apple mascot as two deliverables that share one character design: an embeddable 2D animated widget for the web, and a rigged 3D model with playable animation clips. Both are delivered as production assets plus full source, with no runtime dependency on any third-party AI service.

The prototype we built and deployed at apple-agent.6iang.dev is not a mock-up: it renders a live character with blending expressions, randomised blinking and continuous idle motion, and it loads a real compressed 3D model in the browser. Building it answered the two questions that decide how this project has to be run — and one of the answers is a genuine constraint on scope, which we set out in full in section 2 rather than discovering it mid-build.

In short: the animation runtime works and is cheap; the character artwork must be authored by hand. Automated image-to-layers and automated 3D rigging both failed on this specific character, for structural reasons that will not change with more attempts. Our proposal therefore puts real illustration and 3D-rigging effort in the plan, and reuses the prototype's runtime engineering rather than rebuilding it.

Proposed duration is 6–8 weeks across five phases, with sign-off gates between them. Cost is presented per phase in section 6 for you to review against budget.

02What the prototype established

The prototype's purpose was to de-risk the expensive parts before anyone committed a budget. It did that. Two findings are load-bearing for everything below.

Finding 1 — AI cannot produce rig-ready layers for this character

We ran an automated pipeline that asked an image model to separate the mascot into 12 posable layers: body, two eye states, cheeks, four mouth shapes, two arms and two legs. The pipeline reported success on all 12 with zero failures. In practice only 4 of the 12 are usable — the four mouth shapes.

• The generated body layer came back photorealistic, on an opaque background, with no face and no limbs — off-model and unusable. The prototype quietly falls back to your original artwork with the background removed, which is the character you see on this page and in the live demo.
• The arms, legs, eyes and cheeks were generated, cleaned and shipped — and are never actually drawn, because they do not register against the body. The prototype substitutes procedurally drawn eyelids and cheeks instead.
• This is why the prototype's “wave” button leans and bounces the whole character rather than raising an arm: no limb exists as a separate, movable piece. The arms and legs are baked into the single body image.

Finding 2 — automatic 3D rigging fails on a non-humanoid character

Image-to-3D itself worked well. One source image produced a textured 29,200-triangle model in 105 seconds, which we then compressed to a 360 KB GLB that loads in the browser. That part of the pipeline is sound and we intend to reuse it.

The automatic rigging step, however, returned a hard error: 422 — Pose estimation failed, please provide a valid model. The reason is structural, not transient: auto-rigging services fit a humanoid skeleton, and the mascot is a sphere with stub limbs and no discernible spine, shoulders or hips. Retrying costs money and will fail identically. The animation stage was therefore skipped, and the 3D model in the live prototype has zero skeletons and zero animation clips — what you see spinning is procedural motion applied to a static mesh, which the prototype's on-screen notice states openly.

What worked, and what we will keep

One note on the prototype's engineering: a meaningful share of its effort went into working around the demo tunnel it is hosted on — retrying dropped script chunks, a hand-written image loader to avoid stalls, cache-busting, and three separate diagnostic scripts. That work is hosting debt, not product complexity, and it disappears on normal CDN hosting. We have not carried it into the estimates below.

03Proposed approach

Track A — 2D animated mascot widget

1. Layered character source. An illustrator redraws the mascot as a layered document (Photoshop or vector) in which every moving piece is its own element: upper and lower arm per side, legs, eyelids, brows, pupils, cheeks, the leaf, and a complete set of mouth shapes. Overlapping areas are drawn underneath so joints do not tear when they rotate. This document is the master asset and belongs to you.
2. Skeletal rig. The layers are bound to a bone hierarchy in the runtime, so limbs rotate around real pivots. This is what turns the prototype's whole-body lean into an actual wave.
3. Expression system. A named pose table — eyes, brows, mouth, cheeks, head tilt, scale and vertical lift per expression — with eased blending between any two states, so transitions are smooth and new expressions are data, not code. We carry the prototype's approach forward and extend it.
4. Procedural life. Breathing, idle bob, randomised blinking and micro head-drift run continuously underneath whatever expression is active, composed so a blink still reads correctly during a held expression.
5. One-shot actions. Wave, jump and nod (final list agreed in Phase 0), each as an enveloped animation that returns cleanly to idle and cannot be left half-played.
6. Embed API. A single-tag embed plus a small JavaScript interface — setExpression(), play(), on() — so your team can drive the character from your own page without our involvement.

Track B — rigged 3D model

1. Model cleanup. Retopologise the generated mesh to a clean, deforming topology at a controlled polygon budget, and tidy the texture.
2. Custom rig. A bespoke bone layout designed for this character's actual shape — root, body/squash chain, per-limb chains, head and leaf. Explicitly not a humanoid auto-rig, for the reason given in section 2.
3. Hand-keyed clips. Idle, wave and one additional action (agreed in Phase 0), authored by an animator and exported as named glTF animations.
4. Web viewer. Three.js viewer with orbit and zoom, three-point lighting, filmic tone mapping, clip selection with cross-fade, and compressed-asset decoding — extending the viewer already written for the prototype, where the clip-playback code exists and is simply waiting for a rigged asset to drive it.

Delivery and hosting

Both deliverables ship as static, versioned bundles suitable for any CDN or your existing hosting. No server-side component, no database, no runtime API keys, and no per-view cost. The prototype's demo-tunnel workarounds are dropped.

04Scope

05Timeline

Seven working weeks of planned effort inside a 6–8 week envelope. The range is deliberate: it absorbs one normal round of art revision without moving the end date.

06Cost

Effort is shown per phase and per role in working days. Rates and totals are left open in this draft for us to agree with you before v1.0 — the day counts are our estimate and are what we would like your feedback on.

62 role-days total across a 7-week calendar, i.e. a small team working partly in parallel rather than four people full-time for seven weeks.

Third-party asset generation — measured, not estimated

These are the actual figures recorded by the prototype run on 22 September 2026. They are one-off costs incurred only if we regenerate source assets; the delivered products have no runtime API cost at all. Unit prices are left open because vendor pricing should be quoted from the provider's current rate card at the time of signing, not from our notes.

For context on scale: the whole two-track generation run — 12 image layers plus one 3D model — completed in about two minutes of wall-clock time. Generation throughput is not a cost or schedule risk on this project; hand-authored art is.

08Assumptions & what we need from you

The timeline in section 5 depends on these. If any is not met, we will flag the schedule impact in writing at the time rather than at the end.

• Source artwork at full resolution. The prototype was built from a 720×642 screenshot, which is below production quality. We need the original mascot file — vector, layered, or the highest-resolution render available. If none exists, Phase 1 includes redrawing the character from scratch and we should discuss that explicitly.
• Brand and style guidance up front in Phase 0: colours, proportions, personality, and any existing usage rules.
• One named decision-maker empowered to approve art direction and sign off each phase gate.
• Feedback within 3 business days per review round. Two art revision rounds are included in Phase 1; further rounds are handled under change control.
• Accounts and access for any paid generation service, and for the hosting or CDN the deliverables are deployed to.
• Target placement confirmed in Phase 0 — which pages or products the widget will sit in, since this sets the embed method and the performance baseline.

09Change control & payment

Change control

Anything outside section 4's in-scope list is handled as a written change request with its own effort estimate and schedule impact, agreed before work starts. We will not absorb scope silently and we will not surprise you with an invoice.

Payment milestones

Other terms

• Ownership. On final payment, all delivered artwork, 3D assets and source code become yours outright.
• Warranty. N days after acceptance, covering defects against the section 7 criteria at no charge.
• Validity. This proposal is valid until DATE.

10Next steps

1. Review this draft and try the live prototype at apple-agent.6iang.dev — particularly the expression buttons, which show the runtime we intend to build on.
2. Send us your comments on scope (section 4), the phase day-counts (section 6) and the acceptance criteria (section 7). These are the three places where your input changes the plan.
3. A short call to work through the two constraints in section 2 and confirm the action list for 2D and 3D.
4. We issue v1.0 with agreed pricing, dates and terms, ready for signature.