Generating 3D Web Pages with Large Language Models: Capability Limits and Cloud Deployment

A large language model can generate a basic 3D page from a single instruction, but the result must pass runtime testing before it is used. This article explains capabilities that can be confirmed today, parts that still need verification, and practical ways to judge architecture and cost at deployment time.

What a Single Instruction Can Generate

Traditional 3D development usually starts by creating assets in modeling software, then importing them into an engine or rendering library and writing the logic. A large language model can skip asset production and describe geometry, materials, lighting, and the camera directly in code. A common output is one HTML file that contains Three.js code and runs when opened in a browser.

The following cleaned-up example uses the Three.js r128 CDN build. It renders a wireframe sphere and supports mouse-drag rotation.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <style>body{margin:0;overflow:hidden;}</style>
  <script src="https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.min.js"></script>
</head>
<body>
<script>
  const scene = new THREE.Scene();
  const camera = new THREE.PerspectiveCamera(75, innerWidth / innerHeight, 0.1, 1000);
  camera.position.z = 5;
  const renderer = new THREE.WebGLRenderer({ antialias: true });
  renderer.setSize(innerWidth, innerHeight);
  document.body.appendChild(renderer.domElement);
  const mesh = new THREE.Mesh(
    new THREE.SphereGeometry(1, 32, 32),
    new THREE.MeshStandardMaterial({ color: 0x00ff00, wireframe: true })
  );
  scene.add(mesh);
  scene.add(new THREE.AmbientLight(0xffffff, 0.4));
  const light = new THREE.PointLight(0xffffff, 1, 100);
  light.position.set(5, 5, 5);
  scene.add(light);
  let dragging = false, lastX = 0, lastY = 0;
  renderer.domElement.addEventListener('pointerdown', e => {
    dragging = true; lastX = e.clientX; lastY = e.clientY;
  });
  window.addEventListener('pointerup', () => { dragging = false; });
  window.addEventListener('pointermove', e => {
    if (!dragging) return;
    mesh.rotation.y += (e.clientX - lastX) * 0.01;
    mesh.rotation.x += (e.clientY - lastY) * 0.01;
    lastX = e.clientX; lastY = e.clientY;
  });
  (function animate() {
    requestAnimationFrame(animate);
    renderer.render(scene, camera);
  })();
</script>
</body>
</html>

Three points about this example matter. First, it depends on a CDN and needs network access at runtime. For offline use, the contents of three.min.js can be written directly into a script tag. Second, it uses the older r128 release. Some APIs in newer Three.js versions have changed, so swapping only the version number can cause errors. Third, it shows only basic rendering and drag interaction. It does not include collision detection or physics simulation.

If the requirement includes collision detection, gravity, or a particle system, the model can generate the corresponding logic, but that code still has to be run and tested in the target browser. Model output is not the same as verified behavior.

What a Long Context Window Actually Does

Some models claim context windows on the order of one million tokens. Whether that number applies to a specific case depends on the vendor’s metering method, the maximum length of a single output, and output quality when the input is very long. Check the official documentation for the model in question. Before development, confirm three things: the model name and version, the accepted input and output limits, and how content is truncated once those limits are exceeded.

The direct benefit of a longer context is that the model can see the system prompt, earlier instructions, API documentation, and existing code at the same time. When generating a single-page application of several thousand lines, that helps keep function names, variable names, and the scene-graph hierarchy consistent. A long context does not replace testing. Consistency still has to be confirmed by compiling, running, and reviewing the code.

Measuring Output Length and Cost Instead of Assuming It

Industry reports often mention falling inference costs, but the actual reduction depends on the model, the billing method, and the task type. Teams should measure their own tasks rather than adopt figures from marketing claims. Record the following metrics:

• Input and output token counts for each generation
• Latency and failure rate of each call
• The share of generated code that passes runtime tests
• Cost of the same task across models or prompts

With those numbers, a team can judge whether the cost of frequent trial and error is acceptable. Some models tend to add long explanations before the code, which increases token use. Asking in the prompt to “output only complete code and necessary comments” usually reduces unused content, but that effect should also be checked with the metrics above.

A Reference Architecture on Baidu AI Cloud

When a generated 3D application needs to be served to users, the layered structure below is a useful reference. On Baidu AI Cloud, API Gateway, object storage, serverless containers, and logging can map to these layers. Before use, check each product’s official documentation for specifications and billing.

1. Generation and authentication. API Gateway receives the user’s prompt, verifies identity, and sets a call-rate limit for each user or tenant. The gateway should record a request ID for every request so it can be traced.
2. Sandboxed execution. Store the generated HTML and JavaScript in object storage, then load and render them in a serverless container. The sandbox should block access to external addresses, so dependencies such as Three.js must be inlined in advance or served from internal resources. Set an execution timeout, for example 30 seconds, and limit memory. Model-generated code is untrusted and must not run directly in production or in an administration console.
3. Monitoring and logs. Record generation time, error rate, token consumption, and the error message from each render. Lifecycle rules on object storage can clean up temporary files on a schedule. Log fields should at least include request ID, user ID, model version, prompt hash, duration, and result status.

Three security controls are required: sandbox isolation, code review, and rollback on failure. Review can start with static checks, for example blocking code that reads cookies, local storage, or external addresses. When an anomaly is found, the application should be taken offline and rolled back to the last stable version.

A Prompt Template

A clear prompt makes generation more stable. The structure below can be reused, with the details replaced as needed:

• Stack: Three.js version, WebGL version, and whether a CDN is allowed
• Visual style: colors, materials, and lighting, such as low-poly, wireframe, or a cyberpunk palette
• Physics parameters: concrete values such as gravity, damping, and collision radius
• Interaction: mouse drag, keyboard control, or touch
• Output format: a single HTML file, complete and runnable, with a short usage note
• Restrictions: no external images or model files, no network requests, and no access to local storage

Once this template is fixed, a team can compare how different models respond to the same requirement instead of writing a new prompt from scratch each time.

Where It Fits, and Where It Does Not

These cases are suitable for an early prototype:

• Product display: generate a rotatable page from product parameters. This fits structurally simple models.
• Education: generate orbital motion or a simple gravity simulation. This fits cases with controllable parameters and modest computation.
• Game prototypes: check spatial layout and feedback for a core mechanic. This is useful for fast experiments, not for going live as-is.

For high-precision physics, large scenes, and projects that must be maintained over time, model-generated code still needs professional engineers to review and refactor it.