# Improving reference fidelity in Blender MCP character work

Research notes, 8 September 2026. Scope: the two supplied images, public primary documentation and research. No model generation, Blender scene edits, paid service tests, or quantitative benchmark was performed.

**Recommendation / inference:** Improve camera matching, silhouette and shape construction before surface detail. Use a dedicated image-to-3D generator as a candidate source for organic geometry, Blender for controlled corrections and mechanical components, and a deliberate stylized texture/shading workflow. Treat this as a testable production hypothesis, not a demonstrated quality increase on this character.

**Missing evidence:** The actual generation script and iteration history have not been inspected. A local `skeletal-cannoneer.blend` exists in this folder, but its topology, UVs and shaders were not audited. The visual diagnosis below concerns the supplied render, not a verified explanation of its construction.

## What the supplied images show

The source for every observation in this table is user Image #1 (3D render) versus Image #2 (`Canoneer Boss.png`). These are qualitative screen-space observations, not measured proportions.

| Area | Observed fact | Interpretation and proposed correction |
|---|---|---|
| Overall composition | The reference has a compact body and a cannon mass extending far left. The render is more vertical. | Match camera and major masses together before detailing. Some apparent proportion error could be camera error. |
| Cannon cluster | The reference barrels project more strongly leftward; the render barrels rise more steeply. | Treat the cluster's orientation, barrel spacing and visible muzzle ellipses as explicit constraints. |
| Face | The reference has an angular skull and strongly shaped brow/socket boundaries. The render has rounder sockets and a softer face. | Preserve expression through planar brow, cheek and socket geometry. A skull label alone does not specify its expression. |
| Beard and hair | The reference has broad tapered lobes, ridges, sharp tips and dark separation lines. The render uses more rounded, inflated-looking lobes. | Use asymmetric, flattened cross-sections and controlled creases. Avoid uniform smoothing that removes designed planes. |
| Stance and boots | The render's boots are tall and upright; the reference has shorter-looking boots and a broader, angled stance. | Reconstruct the projected leg and foot shapes rather than applying generic humanoid proportions. |
| Surface treatment | The reference has dark colored contours, warm highlights, cool shadow colors and strong local gradients. The render has softer transitions and more uniform surface appearance. | Introduce painted color structure, material-specific reflection and selective outlines. |
| Accessories | The hanging ball arrangement and chain silhouette differ. | Model their count, spacing and path from the visible reference; classify hidden connections as inferred. |

**Inference:** The model communicates the character's inventory, but loses parts of its shape language. Adding scratches or increasing texture resolution would leave several identity-defining differences intact.

**Missing:** A single illustration does not establish the back, exact depth, actual material properties, or a unique camera. It may also contain deliberate perspective exaggerations that no single rigid model reproduces perfectly from every view. There is no defensible numerical fidelity score or 3D reconstruction error available here.

## How Meshy and related tools work

**Documented fact:** Meshy's API exposes geometry generation and an optional texture phase. `should_texture` controls texturing; `enable_pbr` requests additional material maps. This is an externally observable workflow, not disclosure of the entire neural architecture. [Meshy image-to-3D API](https://docs.meshy.ai/en/api/image-to-3d)

**Documented vendor claim:** Meshy's current geometry-alignment article describes an image encoder using multiple feature scales and higher-resolution inputs, better alignment between training images and target geometry, and geometry alignment as a training evaluation signal. Its quality comparisons are vendor-run benchmarks, not our evaluation. [Meshy architecture and alignment discussion](https://www.meshy.ai/blog/meshy-7-image-to-3d-geometry-alignment)

**Missing:** The reviewed Meshy sources do not supply a complete reproducible architecture, model weights, training corpus or training recipe. It would be unjustified to claim that Meshy uses precisely the same latent representation, decoder or texture algorithm as an open model.

The underlying idea can be understood through published implementations:

1. **Condition on an image.** The system extracts visual information that constrains the desired object.
2. **Generate a plausible shape using learned 3D priors.** Those priors help fill surfaces invisible in the source. They do not recover proof of what the original artist intended behind the character.
3. **Decode the representation into usable geometry.** The internal representation and extraction method depend on the system.
4. **Generate appearance on that geometry.** Color and, in applicable models, physical material attributes are assigned to surfaces and exported as textures.
5. **Prepare for downstream use.** Remeshing, UVs, cleanup, rigging and engine integration remain separate quality concerns.

**Documented example — Hunyuan3D:** Hunyuan3D 2.0 separates a flow-based shape diffusion transformer, Hunyuan3D-DiT, from Hunyuan3D-Paint. The latter can texture generated or handcrafted meshes. This supports a useful workflow: retain carefully made geometry while using a learned texture system. [Official code and architecture](https://github.com/Tencent-Hunyuan/Hunyuan3D-2)

**Documented example — Hunyuan3D 2.1:** Its technical report explains a shape and PBR-texture system and includes data processing, training and evaluation guidance. It is a more useful source for understanding the machinery than a short product demo. [Technical report](https://arxiv.org/abs/2506.15442)

**Documented example — TRELLIS.2:** This system uses sparse structured representations, a sparse 3D VAE and an O-Voxel representation. It models surface attributes including base color, roughness, metallic and opacity. Its published implementation is tested on Linux with NVIDIA hardware; do not assume the official installation works natively on this Mac. [Official implementation](https://github.com/microsoft/TRELLIS.2)

**Inference:** A dedicated 3D model supplies learned shape priors that a sequence of hand-authored Blender primitive operations does not automatically reproduce. Conversely, precise mechanical components may benefit from explicit construction rather than generative inference. Neither route guarantees a faithful character.

## What Blender MCP contributes

**Documented fact:** Blender MCP is a connector with scene inspection, arbitrary Python execution, object/material manipulation and external asset/generation integrations. It is not itself an image-to-3D neural network. Its upstream documentation includes Hunyuan3D and Hyper3D Rodin integrations. [Blender MCP repository](https://github.com/ahujasid/blender-mcp)

**Observed session fact:** This session exposes Blender tools for code execution, scene/object inspection, viewport screenshots, Hunyuan3D and Rodin generation. Tool exposure does not establish that the Blender server is connected or that provider credentials are enabled; neither was tested.

**Inference:** The connector is unlikely to be the intrinsic fidelity ceiling. What matters is the geometry representation the agent chooses, the visual evidence it receives, and its ability to revise unsuccessful edits.

A program that runs successfully can still make the wrong silhouette. A screenshot must actually be returned as image input to the model: a saved pathname alone is not visual feedback. Inspect a controlled render as well as the viewport; viewport lighting and material preview can differ from the deliverable.

## What inputs would help most

The following are recommendations, not experimentally established requirements for this asset.

- **Authoritative source:** Retain the supplied original as the visual target. Use its full available resolution and clean alpha/background. Do not replace it with an embellished AI remake without consciously accepting a design change.
- **Separate geometry from style evidence:** Keep the original painted art for appearance and expression. Add consistent construction views for spatial understanding, when available.
- **Consistent views:** Front, side and back views should describe the same pose, scale, accessories and proportions. Generated views are proposed designs of unseen surfaces; they are not newly observed evidence.
- **Useful detail crops:** Face, beard, cannon and footwear crops help the agent inspect specific design decisions, but are not substitutes for full-object angle views in a multi-view generator.
- **Parts and occlusion specification:** State which hand carries what, where the weapon attaches, what hangs freely, and which parts must remain separate for animation.
- **Delivery target:** Specify whether success means a single matching render, a sprite sequence, or a rotating animated game asset. These require different amounts of hidden-surface work and topology quality.
- **Style references:** Provide an approved 3D character in the desired rendering style if one exists. The source image alone leaves ambiguity between painted game art and a softly lit collectible figure.

**Documented guidance:** Meshy asks for consistent style, proportions, backgrounds and subject placement across views, and separate uploads for individual views rather than a whole reference sheet. Its current Help Center says multi-view is available with Meshy 7 and is separate from Smart Topology. A Meshy tutorial encountered during research still describes Meshy 6 multi-view, so the documentation is inconsistent; check the actual selected version/UI before preparing a paid run. [Current multi-view help](https://help.meshy.ai/en/articles/12634481-how-to-use-multi-view), [conflicting tutorial](https://www.meshy.ai/tutorials/multi-view-image-to-3d)

## A better construction workflow for this cannoneer

This sequence is a proposed workflow. It has not been executed during this research.

### Establish the camera and silhouette

Load the reference as an alignment guide. Compare orthographic and weak-perspective camera hypotheses. Match framing, elevation and orientation using simple masses. Keep the muzzle shapes, skull, beard tip, belt and feet visible as alignment landmarks.

Use a flat silhouette render and a neutral clay render. The silhouette reveals outline and negative-space errors; clay reveals volume and plane transitions. Once the camera gives a plausible match, lock it for comparisons. Avoid repeatedly changing the camera to hide local geometry errors.

### Choose construction methods by component

| Component | Proposed method | Purpose |
|---|---|---|
| Skull | Sculpted or generated base, then explicit plane/socket corrections | Preserve expression and asymmetry |
| Beard lobes | Custom cross-section meshes or curves with controlled taper, ridge and flattening | Match broad planar forms and pointed tips |
| Cannon barrels | Radial profile meshes with intentional rim thickness and recessed interiors | Preserve mechanical alignment and muzzle silhouette |
| Chain | Repeated link geometry oriented along an authored path | Maintain separation, holes and connectivity |
| Coat | Shaped panels with deliberate thickness, folds and torn edges | Avoid a uniformly rounded clothing shell |
| Balls and small fittings | Simple procedural geometry where the reference supports it | Keep predictable details inexpensive to edit |

An organic generator could provide the body/head candidate. It should not be allowed to redefine the weapon silhouette silently. Generating parts separately is an experiment, not an automatic improvement: it introduces scale, attachment and continuity problems that Blender must resolve.

### Match large shapes before detail

Adjust body compactness, cannon orientation, beard mass and stance before stitching or dents. Restore the angular brow and cheek planes, then the leaf ridges and torn coat silhouette. Use subdivision and beveling selectively; smoothing is not a substitute for designed form.

### Add texture and material structure

**Documented foundation:** Blender's Principled shader exposes distinct controls for surface color, metallic response, roughness and normals. Those controls affect different aspects of appearance; changing base color alone does not describe the material. [Principled BSDF manual](https://docs.blender.org/manual/nb/latest/render/shader_nodes/shader/principled.html)

**Art-direction inference for this reference:**

| Surface | Proposed appearance work |
|---|---|
| Bone | Warm ivory base, cooler cavities, restrained gloss, stronger brow/socket contrast |
| Beard/hair | Dark cool greens in overlap regions, warmer exposed planes, directional ridge accents |
| Cannons | Darker body, broad warm reflection shapes, cooler opposing tones, strong rim contrast |
| Coat | Deep blue structure, restrained highlights, purposeful folds and dark seam separation |
| Leather | Brown/plum variation, controlled edge accents and different reflection from metal |

These are interpretations of the painted image, not measured physical material properties. Tune them in the intended renderer rather than applying arbitrary universal roughness values.

Base-color painting establishes broad visual structure. Roughness controls reflection breakup. Normal maps add small apparent surface changes without fixing the silhouette. Ambient-occlusion or curvature bakes can be masks for selective painting; blindly multiplying dark AO everywhere can obscure the design.

For a dynamically lit game asset, keep strong directional lighting largely outside base color. For a fixed-camera painted look, deliberately baked color gradients and highlights can be appropriate. Mixing strongly painted illumination with strong dynamic lighting can create conflicting light cues.

Camera projection can transfer visible source detail onto aligned geometry. Blender's UV Project modifier supports camera projection. **Limitation / inference:** the original picture already contains lighting and occlusion; projecting it does not make a clean material, supply unseen surfaces, or guarantee correct appearance after rotation. Use it as a paint starting point or a deliberate fixed-view technique. [UV Project documentation](https://docs.blender.org/manual/en/latest/modeling/modifiers/modify/uv_project.html)

### Match rendering style

The original has selective colored linework and smoothly painted tonal variation. Test subtle contours and controlled lighting rather than assuming a hard cel shader is the answer. A global black outline may be too heavy.

Blender's Shader to RGB workflow is Eevee-specific and does not work in Cycles. A Blender-specific node setup also needs an explicit translation or baking plan for a game renderer. [Eevee supported-node documentation](https://docs.blender.org/manual/en/5.2/render/eevee/limitations/nodes_support.html)

Keep background, exposure, color management and camera consistent across comparison renders. Test at the actual display size, because tiny texture detail may not contribute to character recognition there.

## Improving the GPT workflow itself

**Documented fact:** OpenAI describes GPT-6 Astra as supporting image input, coding and tool use. That is not a published guarantee of reference-faithful Blender character modeling. [Official model documentation](https://developers.openai.com/api/docs/models/gpt-6-astra)

**Missing:** No controlled Astra-versus-older-model benchmark on this character was performed or found in the reviewed sources. There is no basis for a numerical quality uplift or a claim that changing the language model alone solves this problem.

**Relevant research:** BlenderAlchemy uses visual edit generation and evaluation, compares rendered alternatives, and can revert unsuccessful edits. Its reported demonstrations focus on procedural materials and lighting. Applying that approach to this character is a reasonable extrapolation, not a result established by that paper. [Paper and method](https://arxiv.org/html/2404.17672v1)

**Proposed operating discipline:**

1. Inspect the reference and current scene; list visible mismatches and uncertainties.
2. Choose one narrow objective, such as cannon orientation or beard planes.
3. Save an independent candidate/checkpoint and apply a bounded edit.
4. Render from the locked comparison camera and inspect the actual image.
5. Compare against the original and previous accepted state. Keep or reject the edit.
6. Check other views before accepting changes for a rotating asset.
7. Move to the next layer only when the current layer is visually adequate.

Use meaningful object names and centralized parameters for proportions and transforms. Keep reusable part constructors so a local correction does not regenerate the entire asset. Do not let procedural randomness alter established landmarks. These measures make iteration more controllable; they do not create artistic fidelity by themselves.

For older vision-capable models, use the same workflow with smaller edit scopes, fewer interacting parameters and more explicit before/after images. That is a recommendation rather than a verified model comparison.

### Reusable agent brief

> Reproduce the supplied character's visual identity in Blender. The original image is authoritative. Start by stating visible facts and uncertain hidden geometry. Establish the reference camera and match the projected silhouette, cannon orientation, skull expression, beard masses and stance before adding surface details. Use custom planar or tapered geometry where the source requires it. Preserve separate editable components. After each meaningful edit, render and inspect the image alongside the reference; judge visible fidelity rather than script execution success. Retain the best checkpoint and reject regressions. Once form matches, develop painted color structure and distinct material responses, then lighting and selective contours. Treat generated additional views as design proposals. Report unresolved mismatches. Do not claim completion without examining the final render at its intended display size.

This is a proposed brief, not a validated magic prompt.

## Guides worth using

| Primary resource | Why it is relevant | Limit |
|---|---|---|
| [Blender Studio: Stylized Character Workflow](https://studio.blender.org/training/stylized-character-workflow/) | Design, sculpting, retopology, UVs, shading and presentation; includes intermediate production files | Older Blender UI; some content requires membership |
| [Blender Studio: Toon Character Workflow](https://studio.blender.org/training/toon-character-workflow/) | Concept through modeling, rigging, toon shading and outlines | Its toon style should be adapted, not copied indiscriminately |
| [Rain shading and texturing production file](https://studio.blender.org/training/stylized-character-workflow/5d5c21508807bf9927c4621e/) | Shows layered vertex/image colors and baking materials into PBR textures | Access to the file may require membership |
| [Hunyuan3D 2.1 technical report](https://arxiv.org/abs/2506.15442) | Detailed explanation of a reproducible image-to-3D/PBR pipeline | Training documentation is not an artist's character-modeling course |
| [TRELLIS.2 implementation](https://github.com/microsoft/TRELLIS.2) | Inspectable representation and generation pipeline | Official hardware/platform requirements need checking |
| [BlenderAlchemy](https://arxiv.org/html/2404.17672v1) | Research foundation for render/compare/revise automation | Does not demonstrate this character reconstruction task |
| [Blender MCP](https://github.com/ahujasid/blender-mcp) | Connector setup, capabilities and upstream tutorial link | Connector mastery does not supply a complete art pipeline |

**Research conclusion / recommendation:** Begin the next experiment with a matched-camera clay blockout of this exact character, or an image-to-3D candidate judged in the same clay view. Resolve the cannon/body silhouette and facial/beard shape before paying for texture refinement. Then compare a painted stylized material pass against the original. Use the resulting evidence to choose between pure Blender construction and a hybrid generator workflow.

**Remaining decisions before implementation:** intended final deliverable and renderer, authoritative hidden-view design, usable base assets, animation/mesh requirements, service access and spending budget. Numerical comparisons would need an agreed evaluation definition and reference data before measurement. No fidelity percentages, performance estimates or vendor rankings are asserted here.