OlympicMarmoto

I wrote a short post about convex hull building and dual polytopes. Dual polytopes are one of those things I understand and then inevitably forget the details of a few months later, so I mostly wrote this as a reference for myself. Hopefully someone else finds it useful too.

The proof that rendering is not _that_ hard because the flutter team did it when they switched off skia (although technically they still use skia for text rendering, I'll admit that text rendering and layout is hard)

Claude code is perfectly capable of writing low level rendering and input code and it can be equally as mindless as vibe coding web apps.

E.g. just say "write a c++ gui widget library using dx11 and win32 and copy flutters layout philosophy, use harfbuzz for shaping, etc etc"

It is baffling how these AI companies, with billions of dollars, cannot build native applications, even with the help of AI. From a UI perspective, these are mostly just chat apps, which are not particularly difficult to code from scratch. Before the usual excuses come about how it is impossible to build a custom UI, consider software that is orders of magnitude more complex, such as raddbg, 10x, Superluminal, Blender, Godot, Unity, and UE5, or any video game with a UI. On top of that, programs like Claude Cowork or Codex should, by design, integrate as deeply with the OS as possible. This requires calling native APIs (e.g., Win32), which is not feasible from Electron.

A few years ago I was experimenting with using Frank-Wolfe for collision detection in a toy physics engine. I never knew about the connection to GJK so I was pleasantly surprised to find the paper mentioned in the blog. Since I had never seen it before I'm sure other people missed it so I wanted to share.

No AVBD is a solver, they use standard collision detection routines.

> But you have to look at numerical error.

Yeah I agree, the error analysis could be many blogs in and of itself. I kinda got tired by the end of this blog. I would like to write a post about this in the future. For global solvers and iterative.

> Finding the closest vertices is easy but not sufficient.

As I'm sure you are aware, most GJK implementations find the closest features and then a one shot contact manifold can be generated by clipping the features against each other. When GJK finds a simplex of the CSO, each vertex of the simplex keeps track of the corresponding points from A and B.

> A second problem is what to do about flat polygon surfaces

Modern physics engines and the demo I uploaded do face clipping which handle this. For GJK you normally ensure the points in your hull are linearly independent.

Do you mean non-convex shapes? You can do a convex decomposition and then test all pairs. Usually games accelerate this with a BVH.