Если важна и геометрия (некоторые графы соединений нельзя будет реализовать из-за пересечения элементов, что невозможно будет в реальности без, скажем, отпиливания от них кусков), придётся к вершинам графа добавлять информацию о том, какая у элемента геометрия, в том числе где расположены соединения и как ориентированы, если это бывает. (И применять вычислительную геометрию, чтобы знать, можно ли соединить два элемента.) И с такого полного описания стоило бы начинать, а лишь потом упрощать по надобности. И мне не совсем ясно, в чём была бы проблема — если например вы ищете какую-то волшебную модель, которая сразу даст ответы на все вопросы, когда это заранее без исследования не обязательно.
Пример, чтобы описание не было не-ответом типа «в виде блок-схемы»: пусть есть кубики, в центрах граней которых есть углубления или выступы одинаковой прямоугольной формы (и стороны этих прямоугольников параллельны рёбрам кубиков). Тут всё довольно просто — собранная конструкция всегда будет укладываться в кубическую сетку, потому мы можем сделать описание каждой детали очень простым: для каждой грани кубика описание ориентации углубления/выступа (два варианта) и типа — углубление или выступ, тоже два. Ещё в модели будет функция преобразования кубика при повороте (чтобы мы могли соединять их по-всякому) и функция, говорящая, можно ли соединить два кубика с интересующей стороны.
На картинке иллюстрация как это может быть устроено (и определена функция соединимости), частично:
-- Чт авг 22, 2019 22:55:09 --Да, когда я рисовал, я решил, что лучше описывать не то, выступ на грани или выемка, а то, направлены ли они по соответствующей оси или против. Это позволило написать функцию соединимости очень просто, но вообще можно делать как угодно. Всё равно подобным моделям обычно место в каком-то софте, а там нет проблем со сложными выражениями, так что можно например будет поэкономить код функции вращения детали, а не этой, или что-то ещё.