См. вложение. Черным нарисованы треугольники. Синим, красным и зеленым - независимо найденные сегменты линии уровня. Проблема с красным сегментом. Если epsilon слишком большая, то с концом синего сегмента "совпадают" и начало красного сегмента и начало зеленого сегмента. Сетка увеличена во много раз. В действительности координаты начал красного и зеленого сегмента могут отличаться и в восьмой значащей цифре, и в десятой... С другой стороны, координаты конца синего сегмента и координаты начала красного сегмента рассчитываются по разному: координаты синего сегмента - через координаты вершин верхнего треугольника, координаты красного - через координаты вершин среднего треугольника. Т.е., хотя теоретически эти точки совпадают, на практике их координаты не совпадают абсолютно точно. Если взять слишком маленькую epsilon, получается, что линия прерывается на синем сегменте т.к. нет ни одного сегмента начало которого совпадало бы с концом синего сегмента.

Я хочу. Но на это уйдет не меньше месяца. А в текущую программу кардинальные изменения вносить нельзя: вызовет цепную реакцию. Сейчас треугольники хранятся набором вершин и ничего о соседях не знают. Переделывать структуру данных для треугольника - переписывать, как минимум, триангулятор и конечноэлементную сетку. Что может привести к еще более обширным изменениям. Программа уже давно держится только на костылях .

В том-то и дело, что нет. Треугольники обходятся в том порядке, в котором они создавались при триангуляции. Так что индексы двух смежных треугольников могут различаться на несколько сотен/тысяч. Любой другой порядок обхода при текущих структурах данных будет слишком трудозатратен. Так что после обхода красный, синий, зелёный и еще с сотню сегментов просто свалены в кучу и их нужно отсортировать так, чтобы конец одного отрезка совпадал с началом следующего.

На мой взгляд правильнее говорить, что линия должна быть неразрывной, а реально с учетом применяемого алгоритма, разрывность линии не должна превышать некоторого эпсилон. Если предметная область, в которой решается задача, не задает этого эпсилона, алгоритм нужно менять.
Другая неприятная сторона этого алгоритма, как я понял, заключается в том, что каждое ребро просчитывается 2 раза. Причем вычисленные два раза координаты точки ребра не совпадают при одинаковых параметрах, входящих в расчет и разница в результатах значительна для данной задачи. Понятно, что это не мистика, но признак того, что результат сильно зависит от ошибок "машинного вычисления" (не знаю, как точно называется это понятие).
Поэтому, если изменить алгоритм на данном этапе невозможно, предлагаю изучить формулу, по которой проводится расчет координат точки ребра. Скорее всего, формула основана на линейной интерполяции, в которой производится деление на величину (z2-z1) (это значения функции в вершинах ребра). Хорошо бы избежать операции деления, т.е. в результаты расчета заносить только числитель, и хранить дополнительно третьим параметром Z этот знаменатель. Тогда алгоритм сравнения двух точек (X1, Y1) и (X2, Y2), дополненных третьим параметром Z1 и Z2, может быть такой:

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

Да. Детали:

- ребра надо создавать даже если они не пересечены ф-цией (с указателем на сегмент NULL). Иначе опять точность подгадит ( для одного треугольника пересечение есть, для др нет)

- я предлагал "указатель на точку пересечения", но "указатель/ссылка на сегмент" не хуже, а может и лучше (напр пересечение проходит по 2 точкам одного ребра)

Класс такого рода задач довольно широк, и ф-ция необязательно аналитическая - напр просто "нечто" возвращающее +/-, ну и поехали по ребру делением пополам. А если и есть формулы, то они могут быть слишком сложны. В общем в "подробности ф-ции" лучше не влезать

Есть ещё такая тема как Интервальная арифметика.
Она как раз позволяет более точно учесть проблемы с точностью представлений и позгешностью.
Реализация есть в том же Boost-е.