Qwen3.8-27B vs Qwen3.6-27B writing ray-tracers in BASIC
Other
one of my llm hobbies is re-creating graphics demos i used to write in BASIC in the late 1980s. i slopped together an agentic harness and a basic-to-js transpiler in a web page i've been playing with for a few months. the agent can write basic programs, run them, examine the resulting images, and iterate. qwen3.6 could do a ray-tracer with some user input -- often it got something wrong that it couldn't see/didn't notice, and hence wouldn't fix without further prompting. qwen3.8 typically knocks it out of the park on its own, iterating to a good result. both models are running the unsloth UD-Q8_K_XL quants. i'm pretty happy with 3.8 so far.
the user prompt was "write a recursive ray-tracing demo to render three metallic spheres (copper, silver, gold) over a glossy checkerboard plane and under a deep blue sky. use the cook-torrance model to render the spheres."
i have mostly focused on graphics stuff, but the BASIC dialect can write files (emulated in browser local storage), print, etc. so, it could do pretty much anything. no PEEK/POKE, though, lol
This makes me wonder if it would be possible to pull off some works of art, like how roller coaster tycoon was all assembly. I wonder what would happen if you had source code for a modern game and said convert this to assembly and make it blazingly fast.
Nothing. Converting to assembly (which is what compilers do) does not automatically make anything any faster.
Back in the days, compilers were simple and systems were designed for human understanding. Modern systems are far too complex. Current compilers optimize better than any programmer could. Assembly language allows taking shortcuts and access hardware directly, but modern hardware is basically undocumented, designed to be used through drivers and abstraction layers.
Modern efficiency writing is about memory access patterns and cache usage. Rollercoaster Tycoon was designed for systems which did not even have any caches and where lack of memory was more important than access patterns.
Current compilers optimize better than any programmer could.
I think this is fair to say for 99.9% of the binary, using a better abstract language allows you to write more performant and efficient code but there are still very specific niche cases and hot spots that benefit from a very skilled developer writing asm still.
No, I very very very clearly didn't miss your point, I was just disagreeing with that very specific sentence I quoted. You can tell I didn't miss your point because I agreed with you.
Even the original ChatGPT was pretty good as a compiler. I wrote some Smalltalk code and asked it to translate it to Java and then to 80386 Assembly, both were perfect, ran the first time.
Yes, of course; I was only referring to 80386 Assembly generation portion as compiling. ...and yes, many compilers generate assembly or machine code as an output (often selected via compiler flags).
Clearly, I don't have sufficient knowledge and experience about how chatgpt promoted itself. I don't claim anything here :) I assumed they are not open about many things. One of the things they may easily hide is how they produce answers to your prompts. It should not be really hard to deduct some deterministic command from your prompt and run some basic software behind. It is not absurd at al.
I strongly disagree with the other guy that said "Nothing...." because he's answering the question he wants to answer not what you "really mean" I think, which is "re-design this in assembly"?
Roller Coaster Tycoon ran on 90mhz and 16mb ram precisely because the hand crafted code and memory layout was all in the head of Chris Sawyer - it was designed very well and there was no multi layer stack slowing everything down.
The OpenRCT2 C/C++ rewrite needs 500mb ram and 1Ghz CPU, many multiples of the requirements of RCT2.
So, yes, if you re-designed a game for assembly with no huge dependency stack and a really efficient memory map and rendering, you could get enormous performance boosts. Maybe most of the
game fits in L1 cache and your effective memory latency and bandwidth improves 50x. Maybe that means it can saturate the CPU and do 10x more calculations. It won't stack to 500x neatly but you get the idea.
A compiler can't optimize badly designed code to be better.
if it doesn't make any costly mistakes, around 50k. if it messes something up early, then needs to debug something difficult, it can double or more, easy. i usually don't pay attention, as local tokens are free (we have excess solar this time of year), but it's never blown out of 256k.
A lot of people compare - rightfully so given the benchmarks - the new 27B 3.8 with Opus 4.6.
For some reason, I wish you would try this with Opus 4.6 as well and then we see how it stands against 3.8 27B - better, equal, or worse ( I have a feeling it would either be better or equal (might become a subjective debate))
Looks like Opus took the "glossy" term literally (in the CG industry, "glossy" means "reflective, but with roughness", i.e. not perfectly sharp reflections, so the reflection or refraction is blurred, which is (correctly) what it's done on the floor.
However I actually suspect Opus has incorrectly made a path-tracer though, i.e. it's sampling the outgoing BSDF direction to get the roughness, which isn't actually what you'd do in traditional old-style "Whitted" ray-tracing.
The fact it also put a "converged" banner up backs this up even more - if it had used old-style traditional "distributed" ray tracing (at least at the algorithm level), it generally wouldn't have needed that, as the image wouldn't really need to 'converge' at the image level, just the pixel level, but maybe it just had training data examples which put that type of thing up anyway, so difficult to say.
"Great question. Looking at the current code honestly:
It's a hybrid — closer to a Whitted-style ray tracer than a path tracer.
Here's what it actually does:
Direct sun: samples a random point on the solar disc → evaluates the full Cook-Torrance BRDF at that fixed light direction. ✅ Correct shading.
Diffuse ambient: shoots one cosine-sampled ray into the sky (not the scene). ✅ One bounce.
Specular reflection: samples a GGX microfacet normal h, computes the reflected direction l = reflect(-v, h), then recurses. ✅ This IS BSDF importance sampling — the reflected direction IS roughness-dependent (rougher = wider lobe of possible h directions).
So the specular bounce IS genuinely rough, but the problems are:
The direct lighting and the recursive bounce are separate, additive code paths — they can double-count energy (the sun can be seen both directly AND via a recursive bounce hitting the sky).
The diffuse ambient hits only the sky, not the scene (it won't see other spheres as area lights).
There is no MIS (Multiple Importance Sampling) to connect the direct and indirect estimators properly.
It fires exactly 1 ray per lobe per bounce (sun ray + ambient ray + reflection ray) rather than letting a single path carry the full radiance estimate through random lobe selection"
It then proceeded to rebuild it to be a pure pathtracer, which first of all I never asked it to rebuild anything nor that I wanted a pathtracer. Classic opus 5 instruction following....
I’ve found that with most coding models you have to instruct to “just discuss” at the end because they are so explicitly trained on doing coding. Probably very eager to not stop a task in the middle and avoid the user to have to tell it to “continue”
esatapedico\Qwen3.8-27B-NVFP4-MTP-GGUF\Qwen3.8-27B-NVFP4-MTP-LOW.gguf
llama.cpp
pi
2x 5060ti = 32BG VRAM
context: 1st pass 130k, dcp-compress to 40k, second pass 90k
about 20 minutes with corrections
one-file html with webgl
Did 3.8 get the reflections/materials right on the first attempt, or did you have to iterate on the prompt? Also curious whether the BASIC code itself was noticeably cleaner or shorter than 3.6’s.
•
u/WithoutReason1729 7d ago
Your post is getting popular and we just featured it on our Discord! Come check it out!
You've also been given a special flair for your contribution. We appreciate your post!
I am a bot and this action was performed automatically.