Tiny Harbor: Qwen 3.8 Flash Next Built a 3D Island in three.js in One Pass

On October 30, 2026, a post with a run appeared on r/LocalLLaMA: a local build of Qwen 3.8 Flash Next in NVFP4 was given the task of making a website with a living 3D village on an island. The author attached a 1920×1080 video, 40 seconds, with an audio track. And immediately a caveat: the post text was written and polished by AI, and the video is an export from the site that the model generated.

What exactly was generated in one pass

The model wrote a website on three.js — a JavaScript library for 3D graphics in the browser, on top of WebGL. The scene: a round island that is built from a single analytical height function. That is, the terrain is defined by a formula of the form h(x, z), not by a ready-made height map and not by a loaded mesh. From this function are derived the cliffs, beach, hill, harbor, and pier.

Next is rendering. The video is 1920×1080 for 40 seconds, the sound was generated separately, offline. The author emphasizes: this is an export from a working site, not a separate build in an editor. The difference is fundamental. If the site opens and runs in the browser, then the code does not just look plausible — it executes.

The word 'benchmark' in the post title should be read cautiously. Formally, this is one run with one prompt. There are no repeated runs, timing measurements, or comparison with a reference in the post.

Why terrain from a single height function is a smart move

Procedural terrain generation is a technique where the surface is described by mathematics rather than drawn by hand. A typical scheme: a radial island profile (height falls toward the edges), on top of it noise for irregularities, separate additions for cliffs and a depression for the harbor. Change one coefficient — the coastline moves, the hill height changes, the depth of the bay changes.

The plus is compactness. Such an island is dozens of lines of code, not a geometry file. A model that holds the scene as a formula is less likely to miss the coordinates of individual objects.

The minus is also known. Objects like the pier and houses need to be placed on the surface. If you just place them at fixed coordinates, they will hang in the air or sink into the slope. How exactly the model solved the attachment to the terrain is not stated in the post. There is no data. This is the first thing to look at in the code if it is posted.

Another point: a 'round island' is a strong simplification. A circle is symmetrical and easy to parameterize. It shows well whether the model handled basic geometry, but it poorly tests work with irregular shapes.

Comparison with DeepSeek: one run is not a benchmark

The author writes: the result is decent, but on the first pass it is worse than DeepSeek, and a couple of iterations will probably close the gap.

Let us break down what is here. There is a subjective assessment by one person. There are two different runs, probably with different prompts and different settings. There is a hypothesis about iterations — it is not tested in the post.

What is missing: identical conditions, number of repetitions, criteria for 'better/worse', blind evaluation. It is not said exactly in what DeepSeek turned out better — in geometry, in scene density, in the absence of artifacts, in code quality. Without this, the comparison remains an impression, not a measurement.

This is not a nitpick of the author. This is the usual problem with demonstrations of generative code. Models are sensitive to prompt wording, to version, to quantization format. One successful or unsuccessful run says little about the model as a whole.

NVFP4 and the AI disclaimer: what remains off-screen

NVFP4 is a 4-bit weight representation format. Fewer bits per parameter — less memory and higher speed on suitable hardware. The price is a possible loss of quality relative to full precision. The post has neither the model size, nor memory consumption, nor generation speed, nor a comparison with an uncompressed variant. There is only the word 'local'. Therefore, the conclusion 'NVFP4 does not get in the way' does not follow from this post — there is no basis for comparison.

The second point is the disclaimer. The author honestly writes that the text was polished by AI. The video and code remain artifacts of the model, but formulations like 'the results are decent' could have been smoothed by an editor. This does not cancel the demonstration, but it changes the status of the text: before us is a report with a caveat, not an independent test.

What to do with this

• Look at the site and the code, not the video. The video shows the result, the code shows how it was obtained. Look for a link to the repository or the HTML file itself.
• When reproducing, record the conditions: the exact prompt, model version, quantization format, hardware. Without this, the run cannot be reproduced.
• Compare models on identical prompts and several runs. One run per model is a demo, not a measurement.
• Check the attachment of objects to the terrain and the handling of scene edges. These are typical places where procedural generation breaks.
• Separate the artifacts: the site, video, sound, and post text were made by different tools. They should be evaluated separately.