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.

mmozeiko "fixed" windows native development, just use their script. Also PortableBuildTools already exists https://github.com/Data-Oriented-House/PortableBuildTools

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"

This is another common excuse.

You don't need to use microsoft's or apple's or google's shit UI frameworks. E.g. see https://filepilot.tech/

You can just write all the rendering yourself using metal/gl/dx. if you didn't want to write the rendering yourself there are plenty of libraries like skia, flutter's renderer, nanovg, 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.

This is the epigraph form of the problem. You try to find the point with the lowest height in the epigraph.

https://en.wikipedia.org/wiki/Epigraph_(mathematics)

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

Braid was not made with XNA. It used a custom game engine. I think it was just on XBLIG?

Lin has some interesting work in isosurface extraction https://github.com/Lin20/BinaryMeshFitting