Вопрос не в этом, а в оценке пути для A*. Нам помимо того что нужно построить путь надо чтобы он был оптимальным (ну или чтобы хотя бы было похоже что мы попытались)

Если нам известны вершины треугольника, которые сами по себе являются графами. То любая точка полигона нас устраивает для того чтобы дойти до графа по прямой из точки к графу

Но это не работает на динамических препятствиях. Для них, мы берем полигон под ними и делим его создавая новые дополнительные графы, можно даже квадратную сетку использовать для простоты, и во время пересечения этого полигона их используем. Удаляем, если моб перешел в другой полигон.

А можно использовать BoundingBox моба, он даст 4 точки внутри полигона. Соединяем с основными вершинами, получается несколько треугольников в одном.

Не за что)

Любая устраивает чтобы дойти, да.
Но как игрок мы знаем, что вот перед нами два пути и один очевидно ближе. И будет странно если вместо этого бот побежит по другому пути, не тот который очевиден для нас.
Во время построения пути через A* мы идём по графу и нам важно каждому полигону который мы прошли дать оценку (как далеко от начала он находится по построенному пути, какая оценка оставшегося пути из него).
И вот вспоминая случай с треугольником на пол километра, нам может быть надо пройти 20 метров через него, но попав в него мы выберем не ту вершину, то наш путь может быть оценен с ошибкой во много раз и другой путь обойдя дом может оказаться короче с точки зрения A*, ну и наш NPC побежит оббегать здание вместо того чтобы пробежать немного по прямой

Самая близкая вершина треугольника (если я вас правильно понял конечно в сообщении про вершины треугольника), может оказаться не самой оптимальной точкой для оценки в этом случае.

Ну дык зачем делать такие длинные полигоны, где вы такие видели? Экономите память? Ну дык зачем так передëргивать. Оптимизировать надо не только тут, и вообще основная проблема в другом месте по оптимизации.
Моя самая отстойная видео карта способна отобразить 22 милиона полигонов в статике, при чём в Unity, который сам по себе потребляет ресурсы.
При всём при этом, я считаю часами какие то там Probe или шейдеры в UE. При этом играю на максималке в танки и корабли.

Ну я написал, оптимизировать геометрию это отдельная задача, не тривиальная тоже. Я занимался улучшением поиска пути вместо этого.

Если у вас уровень и вы запечете свой собственный NavMesh, то у вас не будет таких полигонов. Нет таких прямых пространств на уровне

У ландшафта ест своя сетка, её надо либо добавить, либо сделать линки. Хотя мы так подходим к мержу.

Для blender есть плагин, который например от полусферы создаёт мост из полигонов до квадрата или там двух вершин. Все плагины для него написаны на Python, то есть код открыт.

Есть одна методика, мне сбрасывали, сейчас дам ссылку

Если в запекании геометрии я это предусмотрю, то да.
Пока что у меня геометрия генерируется в рантайме, на время тестирования один меш на уровень, который перегенерируется каждый кадр. Когда закончу с мержем геометрии, возможно уже буду думать как это красивее запекать по кускам и об оптимизации геометрии.
Но пока то что есть меня вполне устраивает.

А нет, наврал, уже не каждый кадр, когда меняется геометрия

yq0ajcb3zw7403xa4mvtds17xcs.gif

Алгоритм триангуляции Делоне методом заметающей прямой / Хабр
https://habr.com/ru/post/445048/

Этот метод позволяет не только создавать произвольную геометрию, но и соединять не соединяемое. То есть полукруг слева из там 12 вершин и половину ромба с 4 вершинами справа. Также он подходит для закрытия дыр в меше.
То есть им же вы сможете мержить два меша делая между ними мост из полигонов.

Да, читал про него, но не нашел имплементации которую можно взять и заюзать. В любом случае спасибо за линк.

Там же в статье есть ссылка https://github.com/pkositsyn/delaunay-triangulation-algorithm