Added a few examples to the single-header triangulation lib, including pathfinding.
Not thinking about usage code carefully led to a bit ugly situation. Owl of shame moment.
https://t.co/fVzzPKTkDE
stb-style dynamic triangulation library written in C. Targeted at game devs who want to build navmesh. Trying hard not to hinder the spirit of Sean Barrett. User-facing API polishing in progress... almost there!
https://t.co/fVzzPKTkDE
@christopherliu_ I've tried Sloan's, but personally I found quad-edge more convenient for inserting and removing โ though don't quote me on that :) Could you share the resource about the cache performance? That sounds interesting.
@StefDevs But honestly, if my life were on the line, I'd trust those 16k lines of Ph.D-written code over mine any day.
Thanks for sharing the use case. It'll definitely help me polish the API.
@rasulseidagul Thanks. I can feel the pain๐. It was built on top of the quad-edge data structure, which is really neat. If you are interested, Stolfi's paper explains it in great detail!
@StefDevs For my case, I'm focused on avoiding infinite loops without relying on heavy math. I think "good enough" triangles are totally fine as long as the triangulation works, and there's no need to match real-number calculus precisely in game. Maybe I'm just being a smartass, though!
@StefDevs Thanks! I didn't look into it deeply, but iirc, that approach was developed for earthquake simulations where I assume precision is crucial. I'm considering its exact math predicates as an option as well.
@terekhov_de I mainly focused on reducing the number of math predicates and the variety of inputs going through them, and on structuring the code smart enough to cover all cases. I definitely need to think harder about it though. Infinite loop would be a disaster in a game.