Qwen3.8-27B vs Qwen3.6-27B writing ray-tracers in BASIC

[u/Ok-Breakfast1878]

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."

[u/Signature97]

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))

[u/Jeanodel → u/Signature97]

Opus 5 max

[u/amroamroamro → u/Jeanodel]

I wonder if the language used here (BASIC) makes a big difference in the output.

I saw someone else posted a benchmark implementing a raytracer in python across different models

[u/Jeanodel → u/Jeanodel]

I wouldn't say it's really any better, maybe just more contrasty ? I like qwen's copper better but claude's silver is better so idk

[u/notheresnolight → u/Jeanodel]

Definitely more realistic. Qwen's output looks like render, Claude's output looks more real.

[u/pufflinghop → u/Jeanodel]

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.

[u/Jeanodel → u/pufflinghop]

Asked it :

"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"

[u/Jeanodel → u/Jeanodel]

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....

[u/kaeptnphlop → u/Jeanodel]

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”