The Astra version seems to have used three.js r170, which is from October 2024. Sol used an even earlier version. GLM's code used the latest version, but I think it's just getting three.js@latest from jsdelivr so it's unlikely to be writing code against that version. Qwen on OpenCode also fetches from jsdelivr, but using a pinned version at r160.
I don't think any of these examples are using things like tone mapping so they're stuck in sRGB (AgX or ACES look much better), they're not using the node materials (good for programmatic texture implementation), and they're not doing anything cool like baking shadow environments or using post-processing effect.
They're nice, but I think they're showing how far behind AI models are on this sort of project rather than how good they are.
Not tone mapping/shader graph is probably the least of the sins, these kinds of one-shots tend to produce hundreds of THREE.Geometry, massive matrix walks, etc. that explode once you move beyond a screen saver.
The models _can_ do it, but you need to ask for the right things. Most people don't, they'll usually blame the browser for being slow or ugly when they can't break through the THREE demo page wall.
A larger THREE.js project starts to look more and more like a game engine, so you pick and choose the parts you need. There's a ton of open source libs, most of the heavy components the big players use are open source, things like physics, mesh optimization.
Key AI-specific parts might be:
- a harness (so the agent can drive the thing)
- authoring pipeline (so you can bake/optimize assets)
- some sort of coherent renderer architecture (what are your assets, your passes, what's your shader graph).
Without some fundamentals here you are on the short road to falling off the cliff of tech debt and the AI will gladly drive you off of it until you ask for an expensive rewrite.
> would you create models independently
Yes. Pretty much any proven gamedev/asset pipeline is something frontier models are good at. Procedural systems, asset store, free content, Blender, Meshy.
Literally anything except "make a THREE.js scene" -- which is not a technique used in gamedev, beyond throwaway prototypes or demos. Which is what you will get if you ask for a THREE.js scene.
Really appreciate this perspective. It’s tempting to stop at being amazed at what these models can do, but my experience matches yours - they need help with details to do well.
I wish there was another column with the estimated cost for each, with a specific date.
Ideally also finding somehow (not sure what would be the right away) what is publicly available before running the test. It's quite a different outcome if there are competitions, e.g. js13k, live code examples from books, even templates, on specific that topic. Visually here the results looks very very similar to the point that I can't help but wonder if it's the result from the short yet relatively descriptive prompt or because some template was always found and relied on.
But I am annoyed at these GUIs implementing features I don’t care about. I want them to just wrap my harness and forward it to my iPhone, but they can’t help themselves from feature creep.
I did have some issues getting it installed on a headless server. I sort of gave up and installed the instance that I use as the remote server on a Debian + xfce machine I had laying around.
I found it appalling when working with remote setup — tabs disappearing and appearing after some time, screen hangs up, projects disappear. Tried to fix some issues with PR, but team is not accepting for 2w+.
I did try this - I found it overly dev focused - e.g. git +/- changes in left sidebar. I wanted something close to what I am use to with Codex/Claude - just for open models.
I created my own in-browser terminal, so it can sit in chrome, accessible, and with some enhancements like animating the tab when the agent is doing some work. It's a layer on top of ttyd/tmux.
Nice. But these tests raise a question what results are reproducible, the final visual, time, tool calling or it's mostly noise. Like, have you tried same combination or model and harness multiple times?
It’s really interesting how much little choices make the result better or worse. Astra and one of the GLMs added bright lights, and thus looked so much better to my eye.
Genuinely happy with some of the Qwen 3.8 results (especially since I can run that model at Q8).
Interesting to see how much better (at this task) Pi (OMP) is over Opencode as a harness.
I’d love to see a few more with outcomes that are as easy to judge but less subjective.
I’ve got a toy project going to make a fun to watch battle simulator where an LLM (or two if playing vs) has to write programs that control multiple bots (each with their own line of sight and limited battle context) that have to coordinate and fight alongside each other. Goal is to have the LLM update the code based on current situations maybe 5-10 times in a 5 min simulated battle. Exploring even allow the bots to request new programming and score based on number of reprogram steps.
huh. goes to show how much browser selection impacts things. the OMP Qwen result is completely unresponsive in free cam on my iphone, whereas the opencode version is responsive, has multitouch zoom and multitouch pan. the glm models do really well with this as well, but all of the anthropic models have pretty gimped camera controls, even astra, which while pretty wont let me pan and only allows me to rotate about 120 degrees! I’m really impressed with the Qwen 27b OpenCode result.
I suppose the only thing that the prompt asks for is the cinematic view, and honestly they all kinda fail on the “subtle volumetric-style fog planes”, none of them have more fog when you get farther from a light source.
I love everything about OpenCode except for the stuff it outputs. On paper it has everything I want in a harness and more, but it tends to struggle to deliver the desired outcome. Last I used it the context was massive and tool calls were reliably unreliable. Is it worth revisiting as a daily driver?
I saw examples on X of people building amazing things with Three.js and models, and I figured out how to build them myself. But the results are mostly low-poly materials and crappy animations (pretty sure because I am not the best at these things). I thought it was my prompt (it was detailed), but it seems to be mostly a limitation of the models.
From all the examples I've seen, Astra does it really well, and I suspect it's because they wanted to attract game designers, so they trained the model more on 3D, animation libraries, etc.
Sol and Opus are pretty good with the right prompting and feedback framework.
Or, my standards are lower. It's sometimes hard to tell in these discussions whether people are talking about getting production quality results, or stuff that's good enough for a one off blog post.
I’m always confused, are all these shapes programmatically generated or are they downloaded from some source?
Also I think Astra looks the best and has the best functionality. Also shocked how much better GLM is on the Non Codex harnesses. Didn’t think it would make such a difference.
Would be nice if you could include cost in the table
Would be good to include Fable and Opus. Based on the results with Astra vs GLM (not even in the same ballpark), these are probably the realistic alternatives to consider.
Basically it can run these mini programs where each input might be another toolcall, so it can run without waiting for whole LLM response and ready the parameters async.
I don't think any of these examples are using things like tone mapping so they're stuck in sRGB (AgX or ACES look much better), they're not using the node materials (good for programmatic texture implementation), and they're not doing anything cool like baking shadow environments or using post-processing effect.
They're nice, but I think they're showing how far behind AI models are on this sort of project rather than how good they are.
The models _can_ do it, but you need to ask for the right things. Most people don't, they'll usually blame the browser for being slow or ugly when they can't break through the THREE demo page wall.
A larger THREE.js project starts to look more and more like a game engine, so you pick and choose the parts you need. There's a ton of open source libs, most of the heavy components the big players use are open source, things like physics, mesh optimization.
Key AI-specific parts might be:
- a harness (so the agent can drive the thing)
- authoring pipeline (so you can bake/optimize assets)
- some sort of coherent renderer architecture (what are your assets, your passes, what's your shader graph).
Without some fundamentals here you are on the short road to falling off the cliff of tech debt and the AI will gladly drive you off of it until you ask for an expensive rewrite.
> would you create models independently
Yes. Pretty much any proven gamedev/asset pipeline is something frontier models are good at. Procedural systems, asset store, free content, Blender, Meshy.
Literally anything except "make a THREE.js scene" -- which is not a technique used in gamedev, beyond throwaway prototypes or demos. Which is what you will get if you ask for a THREE.js scene.
Ideally also finding somehow (not sure what would be the right away) what is publicly available before running the test. It's quite a different outcome if there are competitions, e.g. js13k, live code examples from books, even templates, on specific that topic. Visually here the results looks very very similar to the point that I can't help but wonder if it's the result from the short yet relatively descriptive prompt or because some template was always found and relied on.
I wanted a powerful GUI+harness setup for open models so I could use/test as they came out.
But I am annoyed at these GUIs implementing features I don’t care about. I want them to just wrap my harness and forward it to my iPhone, but they can’t help themselves from feature creep.
https://github.com/stablyai/orca
I did have some issues getting it installed on a headless server. I sort of gave up and installed the instance that I use as the remote server on a Debian + xfce machine I had laying around.
https://github.com/anilgulecha/ttydterm
Genuinely happy with some of the Qwen 3.8 results (especially since I can run that model at Q8).
Interesting to see how much better (at this task) Pi (OMP) is over Opencode as a harness.
I’d love to see a few more with outcomes that are as easy to judge but less subjective.
I’ve got a toy project going to make a fun to watch battle simulator where an LLM (or two if playing vs) has to write programs that control multiple bots (each with their own line of sight and limited battle context) that have to coordinate and fight alongside each other. Goal is to have the LLM update the code based on current situations maybe 5-10 times in a 5 min simulated battle. Exploring even allow the bots to request new programming and score based on number of reprogram steps.
I suppose the only thing that the prompt asks for is the cinematic view, and honestly they all kinda fail on the “subtle volumetric-style fog planes”, none of them have more fog when you get farther from a light source.
If you don't have anything working check the console, maybe a WebGL issue.
From all the examples I've seen, Astra does it really well, and I suspect it's because they wanted to attract game designers, so they trained the model more on 3D, animation libraries, etc.
Or, my standards are lower. It's sometimes hard to tell in these discussions whether people are talking about getting production quality results, or stuff that's good enough for a one off blog post.
Also I think Astra looks the best and has the best functionality. Also shocked how much better GLM is on the Non Codex harnesses. Didn’t think it would make such a difference.
Would be nice if you could include cost in the table
How different are the results between multiple runs of the same setup?
Basically it can run these mini programs where each input might be another toolcall, so it can run without waiting for whole LLM response and ready the parameters async.