material definitions are being parsed from yaml, sellmeier is being curried, and we're getting useful objects out of it all! after a lengthy detour reimplementing the concept of a number, which was then backtracked, i've put together points and rays, but not angles---we're gonna try Inigo Quilez' approach of minimizing the use of trig functions, and as such, we're going to use vectors (points) to encode our angles. haven't worked out how to avoid the inverse trig yet, but we'll get there. color translation has been ported, snell/fresnel/sellmeier are done, materials are working... i think next up is probably implementing our curves, surfaces, and elements. then we do the intersections and ray marching again, and finally figure out how to hook it up to the display. and THEN we'll get to work on all the important stuff... but yeah, i'm having a lot of fun learning Rust. It's hard but rewarding.

It's not as pretty as the album cover, but it is modeled on P-BK7 glass as described by Schott, using Sellmeier's dispersion formula! there are still some bugs, mostly to do with the detection of intersections between rays and surfaces. even shutting off the debug messages, it's not exactly blazing fast, but it's also not been optimized much at all. i guess the next step should probably be...fixing the intersection bugs. yeah. not much point in moving on until the geometry is bulletproof.

i posted about writing an optical simulation ray tracer a few days ago. i spent a day rewriting the geometry and optical classes from the ground up, and things are now broken in different ways from before, but it should be more robust soon. today's task, if i can help it, is to rewrite the ray marching component to work on all surfaces in the system, rather than just the next one in the list. i took the time to implement snell, fresnel, and sellmeier, and i'm working on the architecture for the ray marcher next, figuring out which objects own which data and who passes values where.

i found something really awesome just minutes ago: automatic differentiation! it's a thing in all the big ML libraries because it's important for gradient descent. it was stupidly easy to rework it in there and now we don't have to specify derivatives for surfaces! (aspherics are central to this project, so there will be all kinds of different curves involved. in fact none of these examples has a sphere, besides the flat surfaces of infinite radius.)

New video soon!

A close look at recent GTA 6 footage has sparked discussion over an oddly specific detail: a Ferris wheel that appears to be missing from certain reflections. Digital Foundry examined the scene as part of a broader analysis of Rockstar’s rendering technology, highlighting how even tiny visual inconsistencies can reveal clues about the technical compromises happening behind the scenes. Modern open-world games rely on a mix of rendering techniques to balance image quality and performance. Reflections are often one of the most demanding visual effects, leading developers to use a combination of ray tracing, screen-space methods, and selective object rendering. As a result, some objects may not appear in every reflective surface, even when they are visible in the world itself. Rather than being evidence of a major problem, the missing Ferris wheel is presented as an interesting example of the trade-offs required to create a massive, highly detailed open world. Rockstar appears to be pushing visual fidelity to impressive levels, but like every game engine, it still has to decide where to spend finite computing resources. Final Note: One of the funniest things about GTA 6 coverage is that we've reached the stage where people are investigating missing reflections on distant amusement park rides. The game isn't even out yet, and fans are already conducting digital forensics on every frame.

clean for over a year :0)