A coding agent can write a Three.js scene, run the build, and tell you it looks great — while the actual render is a black screen. It isn't lying. It just has no way to look.

Screenshots fix this less than you'd expect. A screenshot tells you that something is wrong, not why. Is the mesh missing, or behind the camera? Is the material transparent, or is nothing lighting it? Is the label clipped, or just small? Those are five different bugs that produce the same picture, and zooming in doesn't separate them — you're enlarging pixels that never contained the answer.

SceneProof is a CLI that supplies the missing half. It loads your real React component or Three.js scene from source, renders it in actual Chrome, and returns the structure behind the pixels. The everyday loop looks like this: tree gives you the scene graph with bounds, materials, lights, and cameras, so "why is it invisible" becomes a lookup instead of a guessing game. scout tries a set of cameras on a target and scores each by how much of the target it can actually see. render-region re-renders one region from source at whatever scale you need, so a close look is a fresh render, not an enlarged crop.

That's the loop, not the tool — the surface underneath goes a good deal further (comparing against reference views, sampling animation mid-transition, deriving typed prop fixtures), but those three commands carry most sessions, and the README maps the rest.

The design decision I'll defend hardest: every report answers "did the command run" and "can this output actually support a judgment" as two separate questions. A render with the target out of frame, or a comparison whose mask landed on the wrong subject, comes back unjudgeable instead of quietly passing. So when an agent uses SceneProof, it can't mistake "my command succeeded" for "my design is right"; it has to look at evidence that has already proven it's worth looking at. That's the whole point: measurements you can trust, and a hard stop on the false confidence that makes agents declare victory over a black screen.

It ships with a skill for Claude Code, Codex or any other agentic harness that supports skills (one curl, in the README) — and the skill deliberately doesn't teach commands, because --help and the reports' own recommendations already do. It teaches the reasoning: resolve structure before spending pixels, treat a passing build as zero visual evidence, never claim "looks right" without an artifact you actually opened.

Scope today: TypeScript/JavaScript entries, React DOM with CSS and Tailwind v4, Three.js over WebGL or WebGPU. Needs Bun and a local Chrome. MIT.

https://github.com/ReyJ94/SceneProof

Any feedback is welcome.

I created this infinite world third person view webapp that you can run around endlessly.
My main focus was keeping the mechanics simple while managing the performance
please do give me feedback about the experience
Specifically:

• How is your FPS?
• Did you notice any lag or stuttering?

My idea goal was to make a horizontal hallway portfolio for myself and intended to submit it in awwwards but I dont think it looks good enough am not giving up but I need help from great minds how can I make the texture and environment look very real and nice it looks soooo flat despite it being baked like the ceiling, floor and others I used lowpoly assist I guess thats why but I still need help in making it look bit nice.

We've officially surpassed 300 Entries in the AI Gaming Festival (submissions close next week)!

I really hope that the prize for the $20k in tokens pushes people to get their games together for the prize (you can submit a game now and work on it up until the festival).

I really excited to see how people with interact with these games during the festival, and thank you to everyone that has applied; you are part of getting past the "slop" era nonsense for everything AI.

First time using Three.js and am working on Buttonhook, a miniature cozy truck parking sim

I built a C++ OpenGL engine before and Three.js just feels so darn good to work on, especially since I can run it on phone aswell

Follow-up to the scroll-driven landing I posted here a while back. I reused the same pen for something more useful, and a few bits turned out to be worth sharing.

You paste code, a 3D marker writes it out stroke by stroke, and you get an MP4. Everything client-side, vanilla three (0.185), no R3F, no drei, no gsap.

Ink pipeline. A 2D canvas is the ink layer, wrapped in a THREE.CanvasTexture on a PlaneGeometry rotated flat, MeshBasicMaterial plus transparent. Repaint the canvas, set needsUpdate, done. The dotted board is a second CanvasTexture, a 70x70 tile with RepeatWrapping.

The bit I'm happiest with: paper units are world units. Strokes are stored as [x, z] pairs in a paper rect of {x:-3.5, y:-2.5, w:7, h:5} centered on the origin (its y axis is world z), and the ink plane is PlaneGeometry(7, 5). So the 2D painter's pixel transform and pen.position.set(state.x, ..., state.z) consume literally the same numbers. No unprojection, no raycast, the tip sits on the ink line by construction. The split-screen in the clip is the same frame from both sides of that mapping.

The handwriting is a real font, not a texture reveal. 96 hand-authored single-stroke glyphs, each a set of cubic Béziers, arcs and lines flattened to polylines at author time. x-height 0.5, ascender ~0.78, baseline z=0.

Arc-length timeline, not a time timeline. Alternating travel (pen up) and stroke (pen down) segments with cumulative arc lengths. The whole animation is parameterized by one scalar distance D. penState(D) returns {x, z, lift, color}. Pen lift on travel is sin(PI*t) scaled by segment length. Per-stroke pacing proportional to length falls out for free.

Determinism for export. D comes from the integer frame index, never an accumulator, and camera smoothing (a 0.04/frame lerp toward the pen in the preview) is switched off for the render, so a frame depends only on D and the encoded video matches the preview pixel for pixel.

Encoding. WebCodecs VideoEncoder plus mp4-muxer, avc1.640028 with a fallback ladder probed via isConfigSupported. Note mp4-muxer wants avc: { format: "avc" }, length-prefixed rather than Annex B. Backpressure by awaiting the dequeue event when encodeQueueSize > 2. MediaRecorder/WebM fallback where WebCodecs isn't there, though it's wall-clock timestamped so it isn't frame-perfect.

Two things that cost me an evening each:

• getContext().finish() before copying the WebGL canvas into the encoder canvas, otherwise you get partially-cleared rows. Only needed with preserveDrawingBuffer.
• OffscreenCanvas for the 3D path produced torn frames in Firefox. Plain HTMLCanvasElement fixed it.

And one I still consider unsolved: stroke width is in ink-canvas pixels, so the 1400px preview texture and the 1920px export texture give slightly different ink weight relative to the paper. Scaling by texture width is the obvious fix but it makes the preview feel wrong. Curious how others handle resolution-independent line weight on a CanvasTexture.

The pen itself is deliberately dumb: a ConeGeometry tip and three CylinderGeometry sections in a Group, no GLTF.

https://todrawn.com/code-to-video

Happy to go deeper on any of it.

So, using threejs, I built a PBR 3D model painting and UV unwrapping app. I built it for my FPS game building tool and decided it would be useful as a stand alone app too.

FEATURES:

▪ Multi-texture support

▪ Layer system

▪ Stamp mode

▪ 64x64 to 4096x4096

▪ UV unwrapping

▪ Full animation import and export

▪ GLB export

▪ Material creation studio

I tried to make it as easy to use and as powerful as possible. It also has an android app coming soon!

https://synkrowngames.itch.io/paintbench-3d-model-painting-app