Blender 还是 Three.js：让 AI 把同一个场景建两遍 Blender or Three.js? Having AI Build the Same Scene Twice

The question was specific: give the same brief to the same model (Claude Code, Opus 5), have it drive the Blender CLI and export to the web on one side and write three.js directly on the other, and see where the results actually differ — in capability, and in what ends up on screen.

This is not an engine benchmark. The two toolchains render in fundamentally different ways, so comparing frame rates proves nothing. What is worth knowing is where to start next time a brief asks for a space you can walk into in a browser.

Both sides got the same one-sentence brief: a 64 × 30 × 20 m barrel-vaulted terminal concourse at a quarter past nine on a clear morning, sun coming down through the roof glazing, a split-flap departures board as the focal point.

A · Blender was generated end to end by the model writing Python and driving the Blender CLI. Every shape comes from primitives, every material is a procedural node graph, and there are no purchased models and no image textures. It bakes into a compact binary — int16 positions, int8 normals — that a hand-written WebGL2 viewer renders inside a single self-contained HTML file. The process on this side draws on GLM 5.3’s write-up of building a scene in Blender.

B · three.js was written directly as scene code. Its geometry is generated at runtime and nothing is baked. It was built later, with A as a visual reference, and even its palette was ported over as linear albedo values, so the two should agree on colour. The source for B is in Makone.

Both sides are n = 1, same author, same model. Every conclusion below should be read against that sample size.

A high ceiling and a shippable result are two different things

Blender’s ceiling is far higher: global illumination, volume scatter, glass with real refraction, effectively no triangle budget. All of it holds up in an offline render.

None of it survived the export. What reaches the web is one directional light plus hemisphere ambient, a single 2048² shadow map, and a little distance fog. The Cycles volume scatter is not in there. The refraction is not in there. Geometry and textures are what crosses.

The three.js side knew from its first line of code that it had none of this. Everything has to be faked inside a 60 fps budget — and that constraint turns out to be its biggest advantage.

Between “can be made” and “can be delivered” sits an export step. That is the most expensive single finding in the experiment.

Don’t screenshot — put both on the same camera

Grabbing a few stills from each and comparing them by eye only produces two sets of pictures that each look fine on their own. So both pages received the same patch: hide every piece of interface, kill the built-in requestAnimationFrame loop, and expose one minimal external interface.

window.__api = {
  set(eye, at, fovDeg) {              // Blender coordinates in
    cam.position.set(eye[0], eye[2], eye[1]);
    cam.up.set(0, 1, 0);
    cam.lookAt(at[0], at[2], at[1]);
    cam.fov = fovDeg;
    cam.updateProjectionMatrix();
  },
  step(dt) { world.renderFrame(dt); },
  caption(s) { document.getElementById('cap-shot').textContent = s; },
};

The shot list is authored once, in Blender’s convention — X right, Y depth, Z up. The three.js side remaps to (x, z, y) inside its own set(). Both engines take a vertical field of view, so the framing is identical by construction rather than by adjustment.

window.SHOTS = [
  { id:'long-axis', cn:'长轴 · 西入口',
    eye:[-29.0, 0.40, 1.68], at:[24.0, -1.0, 6.40],
    fov:56, dolly:3.2, drift:[0, 0, 0.10] },
  { id:'clock', cn:'四面钟特写',
    eye:[ -3.6, 3.60, 4.55], at:[ 0.0,  0.0, 4.33],
    fov:34, dolly:0.9, drift:[0, 0, -0.10] },
  // …nine viewpoints in all, 4.5 seconds each
];
window.FPS = 24;
window.TOTAL_FRAMES = window.SHOTS.length * 108;   // 972

Capture is frame-stepped rather than screen-recorded: set the camera, render exactly one frame with dt = 1/24, screenshot, repeat.

for (let i = 0; i < total; i++) {
  await page.evaluate((i) => {
    const c = window.camAt(i);
    window.__api.set(c.eye, c.at, c.fov);
    window.__api.step(1 / window.FPS);
  }, i);
  await page.screenshot({ path: `${out}/${String(i).padStart(4, '0')}.png` });
}

ffmpeg -framerate 24 -i frames/a/%04d.png -framerate 24 -i frames/b/%04d.png \
  -filter_complex "[0:v]pad=1280:724:0:0:color=0x2a3138[t];[t][1:v]vstack=inputs=2" \
  -crf 18 compare.mp4

Deterministic stepping is what makes this worth doing. Real-time recording gives two clips that slowly drift apart; stepping gives two strictly aligned columns of 972 frames that can be scrubbed one frame at a time.

The first frame: the two halls are mirror images

Both builds use the same zone convention — gates and platforms on one side, retail arcade and mezzanine on the other, the great window at the east end. Each is internally consistent.

But mapping Blender’s (x, y, z) to three.js’s (x, z, y) is a reflection, and both projects had that mapping baked into their own declared viewpoints. The result: standing at the west entrance facing the great window, A’s arcade is on your left and B’s is on your right.

Same convention, opposite handedness. Eye, target, and vertical field of view are identical in the two frames.

No camera choice fixes this. B is the mirror of A. Flipping the rendered image would correct the chirality and mirror every piece of type in the room along with it. Actually aligning them means changing B’s construction code or A’s export axis convention. Both looked correct in isolation for as long as they existed; one shared rig surfaced it in the first frame.

On sheer content, Blender wins and it isn’t close

A is visibly fuller. Shopfronts with real signage, a ticket hall with numbered windows, luggage, trolleys, bins, stanchion queues, signage totems, trains sitting at the platforms, and people actually seated at the mezzanine café.

B is sparser and its furniture is larger: benches, bins, a few trees, a kiosk, stanchions. The arcade’s shop openings are empty. The mezzanine has tables and nobody at them.

Same viewpoint, roughly twice the stuff in frame above. But the floor tells the opposite story.

Crowd is the widest single gap. A carries 78 figures with varied clothing colours, 21 of them walking a corridor grid that runs between the bench rows so nobody strides through furniture. Per-figure state — position, yaw, gait phase — lives in a two-row RGBA32F texture that the vertex shader reads with texelFetch. Limbs are tagged per vertex at export time from each figure’s own local frame, so the stride costs one rotation in the shader and carries no skinning data at all. They cluster in front of the departures board the way people do.

B has around 13 actors on scripted routines: uniform pale mannequins, thinly spread.

On how the picture reads, three.js wins — because it can’t fake it

This was the surprise, and the reason for it is the constraint itself.

The brief asks for distinct bands of sun lying across the floor. Across all nine viewpoints, only B actually shoots that sentence.

A builds a full glazed truss vault — ribs, purlins, cross-bracing, the whole steel net. Sun passes through the entire glazed surface, so what lands on the floor is diffuse light chopped up by the grid. The light was handed to the solver, and the export came back flat and even.

B cannot do volumetrics, so it had only one route left: make the roof opaque and cut three longitudinal glazed bands into it, at roughly 25%, 48%, and 71% of the arc. The opaque part casts shadow and the glass does not, so the sun draws its own hard-edged stripes across the floor. The visible shafts are geometry — one merged additive prism per band per bay — with dust motes seeded inside the beams rather than scattered through the room.

This one frame explains every lighting difference that follows. The upper roof is a net; the lower one is a slab with three slots cut in it.

A has lighting; B has a lighting idea. The renderer that can’t fake it makes you decide, and deciding is most of art direction.

Push in, and the verdict flips again

The four-face clock is the hero prop of this room. At 4.5 m the judgement reverses completely.

A’s four columns align better and the tracking is more even, but it is dead; B’s board has status colour, and one row physically flips every 2.2 seconds.

A’s dial has no numerals. The source does create text objects for them on all four faces, but they are absent from the WebGL export and from the offline Cycles renders, so the scene lost them during the build rather than at the export. I re-shot the clock from all four azimuths in case it was backface culling; they are simply not there. The hands are two boxes and the hub is a cylinder.

B’s dial is a CanvasTexture — Roman numerals, minute ticks, tapered hands, a brass bezel with a real specular, and hands that advance. At 4.5 m it is still a clock.

A dial built from geometry loses to a 512² canvas at every distance that matters, and it spends more triangles doing it.

The departures board tells the same story. A’s typography is finer — four aligned columns, even tracking, set as actual geometry — but it never updates. B’s is a CanvasTexture with status colour (on time / boarding / delayed / platform change), and one row flips every 2.2 seconds over 0.45 s. It is the only thing in the room carrying news.

Density wins far and loses near.

Both builds hide errors only a new camera can find

The last viewpoint looks back down the long axis from the east end — an angle neither project’s own shot list contains. That is the entire point of a shared rig.

B’s board was only built on the face meant to be read; the back was never made. A’s board holds up from either side.

Sorting A’s 18 logged defects by kind says more than counting them. Ten are pure tool tax — node graphs, the export pipeline, axis conventions — and cannot exist in three.js at all. The other eight are spatial: handedness, single-sided geometry, angles nobody framed. Those survive any change of renderer.

Choosing a tool saves you the first ten. The other eight only turn up under a camera that belongs to neither build.

Numbers

Measured in headless Chromium (ANGLE/Metal) at 1280 × 720, with readPixels forcing a GPU sync after every frame, both sides running the same 972-frame schedule.

const px = new Uint8Array(4);
window.__sync = () => gl.readPixels(0, 0, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, px);

A’s triangle count is the static figure from its export manifest, with figure batches counted separately (~456 k for the whole scene). B’s is renderer.info for that frame, after frustum culling.

That last row may be the one to read first. One round trip costs A five minutes and B 49 seconds. Over an afternoon that is the difference between a dozen adjustments and a hundred, and picture quality is mostly decided by how many rounds you get.

As for the frame-time rows: what they show cleanly is the value of the export step. Baking to a binary lets you merge everything into 91 material batches, and that alone buys most of the 2× frame time. B pays 918 draw calls for the privilege of being five times smaller and generating itself at runtime.

So which one do you pick

Working backwards from the brief, the dividing lines come out reasonably clear:

For content volume, offline quality, a still or a film — start in Blender. The ceiling is there: global illumination, volume scatter, real glass, no triangle budget. The cost is that those things stay on your machine, and the web gets their shadow.

To deliver a space someone walks into in a browser — start in three.js. The version you reviewed is the version they see; there is no export step in between to lose things. Its limits force sentences like “sun lying across the floor” into explicit construction decisions, and that translation is often the reason the picture works at all.

Anything close-up that carries type: use a canvas texture on either side. A dial built from geometry loses to a 512² canvas at every distance that matters.

Whichever side you pick, get a camera that belongs to neither. Every finding above came from a viewpoint that at least one of the two builds had never framed. Reviewing a scene against its own curated shot list means reviewing it against the angles you already know are fine.