"Комплексные" сплайны

[Debalance]

Думаю, что единственный правильный способ - аппроксимация сплайна с заданной точностью

Вы намекаете на полилинию с миллиардом вершин? Представляете как раздуется чертёж в котором куча сплайнов?

[Александр Ривилис]

Вы намекаете на полилинию с миллиардом вершин?

Думаю, что значительно меньше - зависит от "гладкости" сплайна и необходимой точности представления.

Представляете как раздуется чертёж в котором куча сплайнов?

А зачем добавлять его в чертеж? Ты его используешь только для создания AcDbRegion при помощи AcDbRegion::createFromCurves. Если это однократная операция, то можно в чертеж аппроксимированный сплайн не добавлять.

[Debalance]

А зачем добавлять его в чертеж?

Нет, я не добавляю его в чертёж. Я просто сравниваю "вес" гипотетического региона созданного из полилинии с большим количеством вершин с "весом" региона на основе исходного сплайна. Последний (в моём понимании) существенно "легче".

[trir]

Скорей всего сплайны разбегаются при усечении координат конечных точек в соответствии с текущей точность чертежа...

[Debalance]

Скорей всего сплайны разбегаются при усечении координат конечных точек в соответствии с текущей точность чертежа...

Не понял. Поясните, что Вы имеете ввиду?

[trir]

да нет, фигню сказал 

[Николай Горлов]

Во всей этой математической кутерьме связанной с кнотами и контрол-поинтами меня интересует практическая сторона вопроса, непосредственно касающаяся опубликованного мной чертежа. Речь идёт о создании региона (AcDbRegion). Я провёл небольшой тест:

1. Попытался создать регион из исходного сплайна (команда _REGION). В результате получается вполне себе корректный объект - даже площадь имеет адекватное значение.
2. В тулбаре AutoCAD я нажал вот на эту иконку:

и применив к сплайну команду _EXPLODE я расчленил его на группу примитивов. Если далее к полученной группе попытаться применить команду _REGION, то в текстовом окне мы обнаружим следующий лог:
Код: [Выделить]
1 loop extracted.
1 loop rejected.
    Unable to cover wire                   : 1 loop.
0 Regions created.
То же фиаско нас ожидает при использовании команды _BOUNDARY, если в качестве Object type указать Region.
Таким образом наблюдается некоторый дуализм в поведении AutoCAD'а. Что это баг?

команды "_REGION" и "_BOUNDARY" требуют одновременной видимости всех объектов, которые включены в набор. проверил создание области у себя. всё прекрасно создается, если все используемые объекты видны на экране ("_REGION" и "_BOUNDARY" и для целого сплайна и для его кусков). потом зумом оставил правую часть объекта на экране и при выделении - перемещался по чертежу так, что правый  "хвост" скрылся за пределами экрана, а левый появился. всё выделил. нажал Enter - результат: 0 областей.
по поводу того, как создавать такие сплайны - есть команда "_JOIN". Не уверен, но для программной реализации можно поковырять класс AcDbJoinEntityPE

[Debalance]

команды "_REGION" и "_BOUNDARY" требуют одновременной видимости всех объектов, которые включены в набор.

Данная теза вызывает сомнения касательно команды _REGION. Я так понимаю там тупо используется AcDbRegion::createFromCurves для объектов из "селекшн-сета" и если объект выбран - то он ВЫБРАН, причём здесь видимость? На каком Автокаде Вы производили тест?

[Александр Ривилис]

команды "_REGION" и "_BOUNDARY" требуют одновременной видимости всех объектов, которые включены в набор.

Это условие требуется только для _BOUNDARY.

[Николай Горлов]

Данная теза вызывает сомнения касательно команды _REGION. Я так понимаю там тупо используется AcDbRegion::createFromCurves для объектов из "селекшн-сета" и если объект выбран - то он ВЫБРАН, причём здесь видимость? На каком Автокаде Вы производили тест?

упс... да, видимость только для _BOUNDARY. _REGION отрабатывает нормально, даже если объект(ы) полностью за пределами чертежа
проверял в 2014x64 и 2017x64

[Debalance]

_REGION отрабатывает нормально

Ещё раз, чтобы я понял, Вы делаете следующее:
1. Взорвали исходный контур.
2. Применили команду _REGION к группе полученных сплайнов.
3. Наблюдаете полученный регион.

Ну если это так, то я отказываюсь понимать моё поведение Автокада!

[Николай Горлов]

та могу даже видео снять ))). варианты тестов с _REGION:
1. к исходному сплайну применяю _REGION (создается область с одной ручкой перемещения)

2. переоткрываю чертеж.
a)_EXPLODE для сплайна.
б)_REGION. Выбираю рамкой все 12 кусков. создается область с 12 ручками перемещения

3. переоткрываю чертеж.
а)_EXPLODE для сплайна.
б)_JOIN для кусков сплайна.
в)_REGION. создается область с 12 ручками перемещения

PS: напрягает во всём этом только то, что для указанного сплайна неверно определяется площадь (окно свойств, arxdbg, сервис->сведения->площадь). но кажись я нашел, какая команда автокада привносит эту изюминку . Нарисовал два куска сплайна друг под другом. Есть такая команда - "соединение кривых". Воспользовался ей. Она дорисовала два куска сплайна самостоятельно, чтоб  было красивенько и замкнуто. Потом объединил сплайны в кучу. В результате - площадь "-1".

Ну если это так, то я отказываюсь понимать моё поведение Автокада!

пора переустанавливать кажись.

[Debalance]

пора переустанавливать кажись.

Полагаю дело не в этом. Протестировал на двух машинах (Acad 2016x64), результат тот же - регион не создаётся. Программная реализация показывает, что метод AcDbRegion::createFromCurves возвращает Acad::eInvalidInput.

Подтверждаю, что использование _JOIN решает проблему - создаётся регион, но всего лишь с одной ручкой (вместо 12-ти как у Вас) . Вот скриншот:

[Николай Горлов]

хм... вот не зря я не люблю сплайны, и везде, где только можно, стараюсь переводить их в полилинии. ради интереса поковырялся во всех установленных автокадах. задача была просто получить из исходного замкнутого сплайна (без лишних телодвижений, только команда _REGION) область и посмотреть её площадь. Вот такая занимательная математика выходит, и сразу видно, когда кто-то ковырялся руками в исходном коде автокада (кстати, автокады 2012-2014 область создают, но в логе командной строки есть сообщение об ошибке)
акад2010:   87.6068
акад2011:   87.6068
акад2012:   87.6024      Ошибка операции моделирования: Замкнутое ребро в многореберном каркасе.
акад2013:   87.6022      Ошибка операции моделирования: Замкнутое ребро в многореберном каркасе.
акад2014:   87.6022      Ошибка операции моделирования: Замкнутое ребро в многореберном каркасе.
акад2015:   87.5999
акад2016:   87.5999
акад2017:   87.6024

Дальше просто ради смеха решил в 2016-м автокаде пересобрать сплайн (_EXPLODE + _JOIN), а затем сделать на его основе область. Всё получилось, только площадь стала 87.6018, хоть была 87.5999. Оно то в принципе и не критично, погрешность приблизительно 0.002%.
Затем я превратил сплайн в полилинию (получилось 646 точек). Ну и пробежал создание области уже для аппроксимированного сплайна (для полилинии, короче говоря). Так вот. Результат во всех автокадах одинаковый (в принципе как и площадь самой полилинии) 87.5352

PS: Дальше идет сугубо личное мнение. Если программа пишется за денежку, то покупатель должен получать одно и то же число в ЛЮБОМ автокаде (проблемы самого автокада покупателя как-то не сильно утешают. например, площадь здания не усыхается/разрастается сама по себе в зависимости от того, в каком автокаде печатается сопроводительная документация). Второе, исходный материал может быть в любом допустимом виде, но привести его к какому-то одному промежуточному, с которым удобно работать, намного проще, чем обрабатывать рандомный ввод пользователя. Ну и третье из собственного опыта, есть чертеж карьера, нарисованный 3D сплайнами. Еле шевелится этот чертеж на 3D орбите на стареньком компике. Перегнали в 3D полилинии без видимого ухудшения качества (вроде и точек мульйон стал , а чертеж начал плавно вращаться).
PS2: Так что Наумович, как всегда прав , без аппроксимации дела не будет, тем более, что как я понял, её и сохранять то в чертеже не нужно

[Debalance]

Площадь фигуры ограниченная сплайном(ми) не может быть вычислена по формуле (т.е. с точностью до машинного эпсилон). Вероятнее всего в алгоритме подсчёта площади используется (опять же таки) предварительная аппроксимация. Именно от различного шага аппроксимации (используемого в разных версиях AutoCAD) и получаются разные величины площади. Где-то уже обсуждалось, что значение AcGeContext ::gTol менялось от версии к версии - возможно это и есть ответ на вопрос.

... вроде и точек мульйон стал , а чертеж начал плавно вращаться ...

А это как сравнение векторной и растровой графики: векторная и чётче и ярче и меньше по объёму, но зато затратнее по машинному времени.

Так что Наумович, как всегда прав

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