The craft can move up a level too. You still can make decisions about the implementation, which algorithms to use, how to combine them, how and what to test -- essentially crafting the system at a higher level. In a similar sense, we lost the hand-crafting of assembly code as compilers took over, and now we're losing the crafting of classes and algorithms to some extent, but we still craft the system -- what and how it does its thing, and most importantly, why.

Prior to each step, I prompt the AI to review the step and ask clarifying questions to fill any missing details. Then implement. Then prompt the AI after to review the changes for any fixes before moving on to the next step. Rinse, repeat.

The specs and plans are actually better for sharing context with the rest of the team than a traditional review process.

I find the code generated by this process to be better in general than the code I've generated over my previous 35+ years of coding. More robust, more complete, better tested. I used to "rush" through this process before, with less upfront planning, and more of a focus on getting a working scaffold up and running as fast as possible, with each step along the way implemented a bit quicker and less robustly, with the assumption I'd return to fix up the corner cases later.

The goal was over-the-board (OTB) realism. It’s a physics-based sandbox where you manually drag pieces, move the rook for castling, and clear captured pieces yourself. You can even knock them over. The original idea came from my friend, Drew Olbrich (lunarskydiving.com), who built an SGI-based version of this concept at PDI in the '90s.

I spent three decades writing rendering code at PDI/DreamWorks and NVIDIA. I wrote the rendering pipeline from scratch in WebGPU. It defaults to an optimized rasterized "fast path" but if you have a good GPU, you can enable a real-time path tracer in the settings. I implemented this using a 4-layer depth-peeled G-Buffer and Hierarchical Z-Buffer DDA for ray marching, supporting multi-bounce GI and environment map importance sampling.

The scene is lit entirely by a single HDRI environment map, with no local light sources. Since I’m a programmer and not a lighting artist, I’ve exposed all material settings for you to tweak and share.

For multiplayer, I used WebRTC (via PeerJS) to avoid central server lag. The app integrates with Lichess.org to challenge your existing friends, or you can play a local Stockfish web worker. Each client runs its own rigid body simulation to keep the physics responsive while the logical game state stays synced.

The app requires WebGPU (Chrome 113+, Edge 113+, or Safari 17.4+). Tested on latest Windows, MacOS, iOS and Android. It might take several seconds to load the graphics resources if you have a slow network connection.

I’d love to hear how the performance holds up on your hardware, and suggestions for future features, like adding refractions, allowing spectators, or annotations?

Comments URL: https://news.ycombinator.com/item?id=46885241

Points: 2

# Comments: 2

https://github.com/maierfelix/dawn-ray-tracing

Yes, chessboard3d.app is written with raw JS APIs and raw WebGPU. It does use the rapier physics library, which uses WASM, which might be an issue? It implements its own ray tracing but would probably run 10x faster with hardware ray tracing support.

I think you'd get a lot of attention if you had hardware ray tracing, since that's only currently available in DirectX 12 and Vulkan, requiring implementation in native desktop platforms. FWIW, if the path looks feasible, I would be interested in contributing.