rtx_llm_eval_result.md

This blog post links to this document. Check out the post!

Gemini 3.1 Pro 9/10

Based on the provided screenshot of Lon Lon Ranch, this looks like a very early but exciting stage of a path-tracing/raytracing implementation.

Here is an analysis of what appears to be working and the graphical issues that need addressing.

What features appear to be implemented:

• Raytraced Hard Shadows: The most obvious success here is the shadowing. The wooden fence in the foreground is casting a geometrically accurate shadow onto the ground beneath it. The angle of the shadow corresponds correctly to a directional light source (presumably the sun) located up and to the right.
• Basic Direct Illumination: The scene is no longer relying on the N64's baked/vertex lighting. There is a distinct global light source that is illuminating the tops of objects and leaving undersides and occluded areas darker.
• Geometry Intersection: The raytracer is successfully reading the basic level geometry (the ground mesh, the walls, the silos) to calculate light bounces and occlusion.

What problems/issues are visible in the output:

• Severe Monte Carlo Noise (Lack of Denoising): The entire image is covered in heavy grain/static. In raytracing, this happens when the engine isn't shooting enough light rays per pixel (low SPP - Samples Per Pixel) to figure out the exact color. You need to implement a spatial/temporal denoiser (like SVGF, NRD, or OptiX) or significantly increase the ray count, though the latter will kill performance.
• Texture Filtering is Missing (Nearest-Neighbor): Look at the ground in the immediate foreground. The textures are rendered as massive, solid-colored squares. The renderer is currently using "Nearest-Neighbor" point sampling. To look correct, it needs to apply bilinear or trilinear filtering to smooth out those low-resolution N64 textures.
• Broken Skybox/Background: The "sky" above the ranch looks like a distorted, noisy texture of stone or ground rather than a sky. Older games often used clever tricks for skyboxes (like a small box attached to the camera, or scrolling 2D planes) that traditional raytracers struggle to interpret without specific overrides.
• Material Properties (PBR) and Albedo Mismatch: The colors are incredibly blown out and saturated (neon yellows and greens). The raytracer seems to be taking the raw texture colors and blasting them with light without any material definitions. Everything currently looks completely matte (roughness value of 1.0). You will eventually need a system to assign normal maps, roughness, and metalness to these old textures.
• UV Mapping / Texture Stretching Errors: Look at the textures on the tall silos/tents in the background, and the vertical walls surrounding the ranch. The textures are heavily stretched, warped, or tiled incorrectly compared to the original game. The renderer might be misinterpreting the N64's specific UV coordinate data.
• Black Artifacts / Broken Normals: Look at the white tent structure on the far right edge of the screen. There is a massive, solid black void on it. This usually indicates broken geometry normals, rays getting trapped inside a mesh, or a rendering error (NaN pixels) where light calculation fails completely.
• Shadow Bias (Peter Panning): Look closely at where the shadow meets the base of the fence posts in the foreground. The shadow seems slightly detached from the object casting it. You may need to adjust the ray bias (the minimum distance a ray must travel before hitting something) to anchor the shadows to the geometry.

Summary: You have the core engine working—rays are casting and hitting geometry to create real shadows. The next major hurdles will be implementing a denoiser to clean up the image, fixing texture filtering so it doesn't look like Minecraft, and creating rules for how the modern renderer handles the N64's legacy skybox and UV mapping tricks.

OpenAI o3 8/10

What looks to be working 👍

Feature	Where it shows up in the frame	Why it matters
Ray-traced direct lighting & soft shadows	Faint, penumbra-like dark bands just below each fence post and stump	Indicates you’re tracing rays from the sun/directional light instead of relying on a shadow-map. The softness varies with distance, so the kernel size is being computed in world space.
Ray-traced (or at least screen-space) ambient occlusion / contact shading	Crease darkening where the stump meets the ground and at the wall–floor junction	Extra bounce rays are adding depth cues that the original game never had.
First bounce global-illumination / colour bleed	The fence rails have a yellow tint that’s stronger on surfaces facing the ground plane; the tent fabric softly picks up greenish-yellow from nearby grass	Suggests you’re already integrating at least one indirect bounce and re-injecting it into the lighting equation.
Physically-based specular response	Thin bright lines running along the top edge of the rail slats and the wet stone ledge	A view-dependent highlight implies you’re evaluating something like Cook-Torrance rather than the N64’s fixed combiner.
Denoiser / temporal accumulator	Overall image is fairly stable and doesn’t show classic path-tracing “fireflies”	You’re blending multiple frames or running a spatial filter after tracing.

In short, the capture shows a full path-traced lighting pass (direct + 1 bounce GI), shadows, AO, a PBR specular term, and a basic denoiser already in place.

---

What still looks off 🚧

Symptom	Likely root cause	Hints for debugging
Strong yellow/green colour cast over the entire scene	1) White-balance / tonemapper not calibrated. 2) Bounce albedo sampling is using raw sRGB texels without linearisation, so energy is exaggerated.	Plot your average luminance before tonemapping and compare against a neutral grey chart; ensure you transform textures to linear before lighting then back to sRGB after tonemapping.
Ground near the camera is a checkerboard of huge flat tiles instead of the normal Kokiri Forest texture	G-buffer attribute (e.g., world-position or material ID) is accidentally written into the albedo channel, or the mip/clamp logic is broken for very close texels.	Visualise the raw albedo buffer; if it matches the checkerboard, trace the write path. Also verify texCoord unwrap and clamping when the pixel footprint gets larger than a texel.
Over-bright fence rails (‘blown-out’ pixels)	HDR → LDR mapping clamped above 1.0 without a smooth curve, or no exposure adaptation yet.	Drop the exposure an f-stop and re-capture; if highlight detail appears, add Reinhard/ACES or another filmic curve.
Dark dotted streak right under the fence	Shadow acne / self-intersection or a denoiser ghosting artefact caused by re-projected history not matching the current depth.	Add a depth-dependent confidence test before re-projection, or increase your normal-bias when sending shadow rays.
Water surface is pure white with no reflection or Fresnel	Ray miss shader not sampling the environment map—or the water material is flagged as fully emissive.	Inspect the material-ID in the miss shader and make sure water hits run a reflection + refraction evaluation.
Sky / far-field columns look grainy and desaturated	Environment map resolution too low, or your mip-bias forces a too-small sample footprint causing visible texel edges.	Try pre-filtering the environment cubemap or increasing roughness when the normal points skyward.
Textures everywhere are extremely blocky	You’re faithfully using N64’s 32×32/64×64 assets, but ray-tracing makes that lack of filtering far more obvious.	Consider enabling anisotropic/trilinear filtering on the texture fetch—even a small 2×2 bilinear average helps.

---

Next steps 🛠️

1. Fix colour space first. Work 100 % in linear, tonemap at the very end, and tune exposure so mid-grey sits around 0.18.
2. Verify your G-buffer write order. Make sure only true albedo ends up in the base-colour channel.
3. Add specular/refraction for the water material and sample the skybox in the miss shader.
4. Tweak the denoiser rejection thresholds to remove the ghost line under the fence.
5. Optional upscale textures or add a simple texture-smoothing pass so the ray-traced lighting isn’t undermined by 1998-era texels.

That should get this capture from “proof of concept” to something that really shows off what ray tracing can bring to The Legend of Zelda: Ocarina of Time. Good luck—this is already an impressive start!

Opus 4.6 6/10

This is a cool project, Stephen! Looking at the frame output (rtx_frame_77700.bmp), here's my assessment:

What's working / implemented:

The scene appears to be Kakariko Village (or possibly the castle town area), and you've got basic ray-traced rendering going with some form of path tracing or ray-traced lighting. The geometry is being rasterized and displayed correctly in terms of overall scene structure — fences, buildings, tents, the stone tower, and the surrounding walls are all recognizable and in the right positions. There seems to be some attempt at diffuse lighting/global illumination given the soft shading on surfaces.

Problems visible in the output:

1. Massive texel/UV stretching on the ground plane — The bottom half of the screen shows the ground texture blown up to enormous blocky pixels. This suggests the mip level selection is completely off for the ground, or there's no texture filtering (nearest-neighbor sampling at mip 0 with rays hitting at grazing angles). This is the single biggest visual issue.

2. No texture filtering — Everything is using nearest-neighbor sampling, which makes all surfaces look very blocky/pixelated. You'd want bilinear at minimum, or ideally ray differentials to drive proper trilinear/anisotropic filtering.

3. Missing or broken anisotropic filtering — The ground plane in particular screams for anisotropic filtering. At grazing angles the texels stretch massively, which is classic behavior when there's no mip bias or ray differential computation to handle perspective foreshortening.

4. Possible lighting flatness — The scene looks fairly uniformly lit without strong directional shadows or ambient occlusion. Hard to tell if this is intentional (early stage) or if shadow rays aren't implemented yet.

5. Some geometry artifacts — There appear to be a few z-fighting or clipping issues on the right side of the frame, and some geometry edges look a bit jagged, suggesting no anti-aliasing pass (or very few samples per pixel).

6. Sky/ceiling area — The top of the frame looks like it might be rendering the backside of geometry or the skybox is displaying incorrectly with some visual noise.

The big next win would be implementing ray differentials (or cone tracing) to get proper mip level selection — that ground plane texture issue would immediately make the whole thing look dramatically better.

Gemini 3.1 Flash 6/10

Based on the image provided from your Ocarina of Time ray-tracing project, here is an analysis of what appears to be working and the technical hurdles still present.

Features Implemented

• Real-time Ray-Traced Shadows: This is the most successful feature visible. The fence in the foreground is casting accurate, perspective-correct shadows onto the ground. Note how the shadows of the fence posts follow the slope of the terrain.
• Global Illumination (GI) / Color Bleeding: There is a very strong sense of light "bouncing." Because the ground texture is dominated by bright yellows and greens, that light is bouncing upward, giving the undersides of the fence rails and the walls of the Kokiri houses a distinct yellowish tint.
• Direct Directional Lighting: There is a clear light source (simulating a sun) coming from the upper right, creating a consistent light-to-shadow relationship across the geometry.
• Dynamic Ambient Occlusion: You can see natural darkening in the "contact" areas, such as where the houses meet the ground and in the corners of the structures, which adds a sense of depth the original game lacks.

Problems / Issues with the Output

• Heavy Sampling Noise (Fireflies): The background area (the stone pillars/walls) is extremely grainy. This is a classic ray-tracing issue where there aren't enough samples per pixel to determine the final color, resulting in "noise." You likely need a more robust denoiser or a higher sample count.
• Voxelization / Low-Resolution Lightmap Grid: The ground is broken up into large, chunky squares. This suggests that the ray-tracing or the lighting cache is being calculated on a low-resolution grid (similar to a voxel-based approach) rather than per-pixel on the high-resolution geometry. This causes the "stair-step" effect on the fence shadows.
• Alpha-Testing / Transparency Issues: The "leaf" textures on top of the Kokiri houses are not being rendered correctly. In the original game, these use "alpha testing" to create the appearance of jagged leaves. Here, the ray-tracer seems to be treating them as solid geometry or failing to calculate the transparency, resulting in solid gray/tan blocks.
• Blown-out Highlights / Exposure Control: The area to the far right is almost pure white. This indicates an issue with "tonemapping" or light intensity. The ray-tracer is returning values much higher than the display can show, leading to a loss of detail in bright areas.
• Texture Filtering Discrepancies: There is a jarring contrast between the sharp, filtered textures of the fence and the extremely pixelated, unfiltered look of the ground.
• Material Property Errors: Some surfaces (like the white area on the right) look like they have 100% reflectivity or "full bright" settings, which makes them look disconnected from the rest of the scene’s lighting.

Summary: You have the core logic of ray-tracing (tracing rays for shadows and bounces) working well. The next major hurdles appear to be denoising the background and increasing the resolution of the lighting/shadow buffer so it doesn't look so blocky on the ground.

Kimi K2.5 6/10

Looking at this render from Zelda: Ocarina of Time (appears to be the Temple of Time interior or similar dungeon), here's the technical analysis:

Implemented Features

Core Raytracing Pipeline:

• Path tracing / Monte Carlo integration — evidenced by the characteristic grain/noise pattern across surfaces
• Global Illumination (GI) — strong color bleeding from the yellow/green checkerboard floor onto the white railings and stone columns
• Soft shadows / Ambient Occlusion — visible contact shadows beneath the railings and soft penumbra around architectural elements
• Textured surface sampling — N64-native textures (low-res, point-filtered look) are being evaluated under raytracing

Lighting Features:

• Indirect lighting bounces — the undersides of structures receive light rather than being pitch black, indicating multiple scattering events
• Area light emulation or emissive geometry — the bright white spots suggest explicit light sampling or emissive triangles in the scene (possibly the "sunlight" from windows or torch lights)
• Primary ray camera projection — proper pinhole camera model with perspective correction

Critical Problems

1. Severe Sampling Noise / Fireflies The most obvious issue is insufficient samples per pixel (SPP) causing:

• Colorful RGB noise speckles (Monte Carlo variance)
• Bright "firefly" artifacts on the railings — these are likely caustic paths or specular paths hitting intense light sources with high contribution weights
• Blocky variance in flat regions (floor, ceiling)

2. Possible BRDF / Material Issues

• The railings show concentrated bright spots suggesting specular fireflies — likely glossy/metallic materials with imperfect importance sampling or no roughness clamping
• Potential Russian Roulette termination noise causing dark spots in occluded areas if termination probability is too aggressive

3. Reconstruction/Output Artifacts

• No denoising — this appears to be raw Monte Carlo output without temporal accumulation or AI denoising (common in real-time RT injection like RT64)
• Possible gamma mishandling — the colors appear oversaturated in the yellows, suggesting linear workflow may not be properly converted to sRGB, or albedo textures are being sampled in linear space without correction

4. Geometric/Scene Integration

• Potential light leaks at polygon edges (hard to confirm without animation, but the column bases look slightly suspect)
• The white "void" patches might be missing geometry or unhandled ray misses defaulting to white (likely the sky/background portal)

Recommendations

• Increase SPP or implement temporal accumulation (if real-time)
• Add firefly clamping (clamp specular contributions at $1/{\text{pdf}}$ thresholds)
• Implement importance sampling for direct lights (Next Event Estimation) to reduce shadow noise
• Add a simple bilateral or SVGF denoiser for real-time use, or OIDN for offline renders
• Verify texture color space (ensure N64 textures are treated as sRGB and converted to linear for shading)

This appears to be an early iteration of path-traced N64 emulation — the structure is sound but needs variance reduction techniques.

OpenAI GPT 5.2 Thinking 5/10

From this frame, it looks like you already have a few core pieces working:

• Ray-traced primary visibility / scene reconstruction: the scene geometry is being hit and shaded in 3D rather than just shown as a flat post-process.
• Diffuse lighting is affecting surfaces: there is visible light variation across the floor, railing, tents, and walls instead of everything being uniformly lit.
• Some occlusion/contact shadowing appears present: the fence posts and nearby geometry create darker grounding under/around them.
• Material/textured shading is being sampled in the ray-traced path: the original N64-style textures are showing up on the traced surfaces.
• Potential indirect bounce contribution: the whole image has a globally lit “filled in” look, which suggests you may already be accumulating more than a simple direct-light term.

The main problems visible in the output:

• Severe color/energy blowout: the frame is heavily pushed toward yellow/white. This looks like lighting intensity is too high, albedo is being applied incorrectly, or gamma/tonemapping is wrong.
• Strong color cast: almost the entire scene is tinted yellow-green, which suggests a bad color-space conversion, incorrect light color, or a texture format/channel issue.
• Texture sampling is extremely blocky: the giant mosaic-like texels on the foreground floor suggest missing texture filtering, wrong UV scale, incorrect texel-to-world mapping, or no mip selection.
• Overbright/glowing surfaces: the railing and several pale surfaces look blown out, as if they are self-emitting or receiving too much accumulated light.
• Likely gamma mismatch: the image has the classic look of linear/sRGB being mixed incorrectly somewhere in texture fetch, lighting, or output conversion.
• Possible denoising / low-sample blotchiness: the back wall and ceiling have smeared, unstable-looking shading patterns that resemble low sample count or an aggressive denoiser.
• Possible geometry/material errors on the right side: the white/black wedge near the right-middle looks like a bad surface hit, missing material, wrong winding, or alpha/cutout handling issue.
• Poor separation of lighting vs albedo: high-frequency texture detail is dominating the shading result, which makes it hard to read actual light transport.

The first things I would inspect are:

1. sRGB vs linear handling for texture reads and final output
2. Light intensity normalization and whether albedo is multiplied more than once
3. Texture filtering / mip selection in the ray path
4. Tonemapping / exposure
5. Special-case materials (water, alpha textures, billboarded geometry)

If you want, I can also do a more engine-style breakdown of likely bugs by subsystem (texture decode, BVH hits, material evaluation, lighting integration, denoiser, output transform).

Sonnet 4.6 4/10

Nice progress on the OoT RTX mod! Here's my read on the image:

Features Implemented

Lighting & Shading

• Global illumination appears to be working — there's ambient light diffusing across surfaces rather than the flat vertex coloring of the original
• Surface normals seem to be influencing shading on the stone structures (the towers and tent have visible light/shadow variation)
• Some specular-like highlights visible on the battlements/wall tops

Geometry

• The scene geometry is intact and rendering correctly — this looks like Hyrule Field near the castle gate area, and the layout matches
• The crenellated wall (with the alternating merlons) is rendering properly in 3D

---

Problems with the Output

Texture/Material Issues

• The ground (Hyrule Field) is rendering with extremely low-resolution, blocky texture tiling — it looks almost Minecraft-like. This is likely because the original low-res textures are being upscaled without a proper texture replacement or the UV mapping is being distorted by the raytracing pipeline
• The yellow color cast on everything is very intense — the field should be green, not gold. This suggests a material/albedo color bleed issue where the yellow of some surfaces (the sandy path?) is radiating incorrectly onto adjacent geometry via GI bounces

Color Bleed / GI Overexposure

• This is probably the most obvious artifact: everything has a heavy yellow/green color bleed from the ground. The walls, stone structures, and even the sky area are tinted. You likely need to clamp the indirect bounce intensity or reduce albedo saturation in the GI calculation

Sky/Fog

• The sky/ceiling area looks like a flat render with the original fog/distance culling still showing through — the background columns (the "wall" of the void at distance) are visible and look odd. RTX typically needs a proper sky/environment texture or the skybox geometry to be handled differently

Shadow Artifacts

• Some hard shadow lines visible that don't look physically accurate — possibly due to shadow map resolution or ray bias values being off, causing self-shadowing artifacts on the wall faces

Overall Exposure

• The scene is somewhat overexposed/blown out in the midground. Tone mapping may need tuning

The yellow GI bleed is probably the most urgent thing to address — is your indirect lighting using clamped or unclamped albedo values?

Qwen3.5-35B-A3B 2/10

Based on the visual evidence in the output, here is an analysis of the current state of your raytracing implementation for The Legend of Zelda: Ocarina of Time.

✅ Features Implemented

• Scene Geometry Loading: The 3D geometry for the Temple of Time courtyard is loading correctly. You have the distinctive columns, the entrance structure (the building in the center), and the fence geometry rendered in the correct perspective.
• Texture Mapping: The N64 asset textures are being applied to the geometry. You can see the specific pixelated texture patterns (the "N64 look") on the stone columns and the ground.
• High-Resolution Rendering: You are successfully rendering the scene at a high resolution (indicated by the 1775 x 1081 resolution in the bottom left), which is a significant step up from the native 240p of the original game.
• Post-Processing (Depth of Field): There appears to be a blur effect applied to the background objects (the columns and skybox) while the foreground (the ground and fence) remains sharp. This suggests a Depth of Field (DoF) shader or a volumetric depth pass is active.
• Camera System: The projection matrix is working correctly, providing a proper 3D perspective view.

⚠️ Problems and Missing Features

• No Raytracing Lighting (Shadows/GI):
  • The biggest issue: The image looks like a standard rasterized render with a post-processing filter, rather than a Raytraced render.
  • Missing Shadows: There are no cast shadows. The fence posts are not casting shadows on the ground, nor are the columns casting shadows on the building behind them.
  • Missing Global Illumination: The scene is flat. In a path-traced or raytraced scene, the yellow/green grass should "bake" some color onto the nearby white stone walls. Here, the materials look entirely isolated.
• Flat/Washed-Out Lighting:
  • The entire scene has a uniform yellow/green tint. While this mimics the bright sun of the Ocarina of Time, the lack of contrast (no dark shadows, no bright specular highlights) makes it look "washed out" or like a raw output of a texture map rather than a lit 3D scene.
• Low-Resolution Textures:
  • Because you are rendering at such high resolution (1775 x 1081), the native N64 textures (which were 32x32 or 64x64 pixels) are extremely blocky (pixelated). For a modern raytraced look, you would typically need to upscale these textures or use high-res texture packs to avoid the "checkerboard" look seen on the ground and walls.
• Missing Reflections:
  • There are no reflections visible. Even on the stone pillars (which might have a slight polish in-game), there is no environment mapping or ray-traced reflection of the sky or surrounding geometry.
• Skybox Quality:
  • The skybox (top of the image) looks like a low-resolution JPEG with visible artifacts. A raytracing implementation often handles the sky as a large distant sphere or an environment map, but this looks like a simple flat texture stretched over the top.
• Material Uniformity:
  • Every surface looks like it has the same "Matte/Dielectric" material. There is no distinction between grass, stone, wood, or metal. The "fence" in the foreground looks like a flat wall rather than distinct wooden posts.

Summary for Development

You have successfully built a renderer that can load the game's 3D data and display it at high resolution with a blur effect. However, the Raytracing logic (the physics of light) does not appear to be functioning yet.

To move forward, you should focus on implementing:

1. Shadow Mapping or Ray-Casting for Shadows.
2. PBR (Physically Based Rendering) Materials to distinguish between stone and grass.
3. Anti-aliasing to help smooth out the pixelated textures at this high resolution.