[seveibar]

Despite what electrical engineers would claim, I think it's very under-studied under a modern lens. When people ask for good places to get started I usually tell them to just look at what game developers are doing for pathfinding. Autorouting sort of a form of multi-agent pathfinding, so there are a lot of relevant concepts from that area.

The tension in autorouting IMO is people generally want something ideal that passes all design rule checks. My thinking (and IMO the more modern way of thinking) is that fast algorithms, fast feedback loops and AI participation are more important.

There are also a lot of relevant algorithms in VLSI/chip design, the folks at OpenROAD seem to have good stuff although I'm not intimately familiar.

[dvt]

> I usually tell them to just look at what game developers are doing for pathfinding.

The example in the article doesn't quite apply, as baking pathfinding given a mesh (like baking lighting) isn't really the same thing as what A* pathfinding is (just how it's not the same thing as, e.g., raytracing). So I'm not sure if I fully agree with the logical inference there. In my defense, I know nothing about etching PCBs, so I'm likely missing something.

[seveibar]

Game developers do bake navmeshes that's true, but it's not the only technique, for example they've also come up with Polyana or "any-angle pathfinding" https://github.com/vleue/polyanya

I also have on my desk "Algorithms for VLSI Physical Design Automation Third Edition" which I really like, but it's ~20 years old and has a lot of nomenclature that can be helpful, but I'm not a big believer in how the problems are broken down, which is IMO more oriented towards "designs with repeated patterns" rather than PCBs that don't usually repeat patterns (unless you're doing an LED matrix)