Новая версия SuperBoundary v.1.0.1.30

[Debalance]

Разместил новую версию программы SuperBoundary v.1.0.1.30. Было устранено и добавлено:
- Устранена критическая ошибка при работе с большим значением коэффициента допуска.

- Тщательно протестирована работа программы в CIVIL 3D, выявлено и устранено некоторое количество ошибок при работе в этой среде.

- Расширены настройки программы. В частности добавлена возможность выбора слоя, в котором будут создаваться полилинии. Добавлена опция выбора текущего слоя и текущего цвета.



- Расширен список поддерживаемых программой примитивов. Добавлены следующие примитивы:
   Мультилинии (MLINE);
   Мультиполигоны (MPOLYGON);
   Регионы (REGION);
   Таблицы (TABLE);

- Добавлена поддержка следующих примитивов, характерных для CIVIL 3D:
   Parcel Segment;
   Featured Line;
   Alignment;
   Tin Surface;

[АлексЮстасу]

Еще мощнее - здорово!

Начало проб данной версии было не очень - на выходе программа зависла.
Во второй раз не могла перейти к указанию точек.
Но это я готов списать на мусорное состояние у меня компьютера-Windows.
Сейчас срабатывает штатно.

Мое предложение сделать учет блоков опциональным не подходит?
Для штрихования учет площадей блоков оправдан. а для построения контуров площадных объектов - нет.

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

Приложение здесь не приложить...

[Debalance]

Начало проб данной версии было не очень - на выходе программа зависла.
Во второй раз не могла перейти к указанию точек.

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

Мое предложение сделать учет блоков опциональным не подходит?

Размышляю. Пока такая заявка поступила только от Вас...

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

Здесь тоже вопрос дискуссионный. Положим есть прямая линия, состоящая из большого количества сонаправленных отрезков. В результате генерации контура имеем прямой отрезок полилинии с таким же количеством узлов. Оно надо?

Приложение здесь не приложить...

Поковырялся в настройках форума - должно сработать.

[АлексЮстасу]

Мое предложение сделать учет блоков опциональным не подходит?

Размышляю. Пока такая заявка поступила только от Вас...

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

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

Здесь тоже вопрос дискуссионный. Положим есть прямая линия, состоящая из большого количества сонаправленных отрезков. В результате генерации контура имеем прямой отрезок полилинии с таким же количеством узлов. Оно надо?

Оно, во-первых, ничему не мешает. А, во-вторых, именно что надо, т.к. "прямая линия, состоящая из большого количества сонаправленных отрезков" - условность. Прямизна и сонаправленность существуют в пределах каких-то точностей их подсчетов. Одним же из главных смыслов альтернативной Boundary является построение точных контуров.

Приложение здесь не приложить...

Поковырялся в настройках форума - должно сработать.

Приложил пример с неточностью создаваемого контура.

[Debalance]

Если целью использования программы является создание контуров площадных объектов, то блоки не могут участвовать в создании контуров.

Давайте начнём с догматов: что есть "площадной объект" и почему, например, внутри блоков не может быть "площадных объектов"? Я так понимаю, что в качестве блока может быть что угодно... иными словами блок внутри себя может содержать какой угодно объект. Или я не прав?

Приложил пример с неточностью создаваемого контура.

Пример посмотрел. Под указанной на чертеже фиолетовой стрелочкой вижу практически идеально прямую линию. Факт наличия стыковочного узла под ней признаю.
Впрочем если вопрос чрезвычайно важен готов в следующей версии предусмотреть опцию отключения оптимизации контура.

[АлексЮстасу]

Если целью использования программы является создание контуров площадных объектов, то блоки не могут участвовать в создании контуров.

Давайте начнём с догматов: что есть "площадной объект" и почему, например, внутри блоков не может быть "площадных объектов"? Я так понимаю, что в качестве блока может быть что угодно... иными словами блок внутри себя может содержать какой угодно объект. Или я не прав?

Давайте догматы. По типу локализации все плоские геометрические объекты делятся на площадные, линейные и точечные. Блоки суть точечные объекты, т.к. геометрически характеризуются одной точкой, точкой вставки. Точечные объекты никак не могут определять границы площадных.
Что внутри блока - вопрос совсем другой.
Если рассматривать возможность разбивания блока, то ведь после разбивания исчезает этот точечный объект, а появляются иные, его составляющие объекты: площадные/линейные/точечные.
Если для каких-то целей для описания границ площадных объектов использовались блоки (для одинаковых помещений или т.п.), то перед поиском контуров площадных объектов такие блоки естественно разбивать, чтобы получать соответствующие линии границ.
Если же стоит задача обнаружения точных габаритов содержания блоков, то это другая задача, которую и нужно решать отдельно. Пусть и с использованием таких же алгоритмов.

Пример посмотрел. Под указанной на чертеже фиолетовой стрелочкой вижу практически идеально прямую линию. Факт наличия стыковочного узла под ней признаю.
Впрочем если вопрос чрезвычайно важен готов в следующей версии предусмотреть опцию отключения оптимизации контура.

"Практически идеально прямую" - это и есть округление, т.е. искажение. Отклонение узла там 0.0044. Специальный тестовый зубчик на желтой линии 0.0062. Т.е. того же порядка, но он отобразился контуром. Ширина "горлышка" - 0.0058, но тоже не стало препятствием. Хотя оно дает "практически идеально совпадающие вершины".
Сейчас контуры строятся идеально, если не считать этой "оптимизации".
Люди сами налажают. Пусть оптимизациями занимаются специальные программы. Любая программа по-моему должна делать только то, для чего предназначена. И не должна делать ничего сверх.

[АлексЮстасу]

Пример, как могут возникать ошибки в контурах из-за их упрощения. Другие программы могут воспринимать возникающий разрыв как расхождение.

Заодно и примеры для крайних случаев - образование для узких треугольников "полигонов" в одну линию. Образование выпуклых полигонов или "полигонов"-линий в зависимости от их площадей - см. узкие треугольники. В этих треугольниках изменялась только длинная сторона. Отклонение вершины от длинной стороны одинаковое.

[Debalance]

По типу локализации все плоские геометрические объекты делятся на площадные, линейные и точечные.

Интересно...!

Блоки суть точечные объекты, т.к. геометрически характеризуются одной точкой, точкой вставки. Точечные объекты никак не могут определять границы площадных.

По поводу блоков - здесь два момента:
1. Блок - это запись в базе данных чертежа, которая содержит какую-то совокупность примитивов. Собственно говоря все примитивы чертежа принадлежат тому или иному блоку. Даже "свободные" объекты пространства MODEL_SPACE принадлежат одноимённому блоку, только вставить куда-либо вы его не сможете.
2. Вставка блока (Block Reference) - это примитив обладающий определёнными свойствами (масштабом, углом поворота и т.п.), в том числе и соответствующей точкой вставки. Именно этот примитив (видимо) Вы и называете "точечным объектом".
Насколько я понимаю основное назначение блока - облегчить разработчику создание чертежа, особенно там где количество повторяющихся элементов велико. Другое сопутствующее достоинство блока - это уменьшение размера чертежа (иногда правильное применение вставок блоков может существенно сократить его объём).

Что внутри блока - вопрос совсем другой.

Ну почему же? Если блок (или блоки) гармонично дополняет "площадной объект"? Таким образом формируется "комплексный площадной объект". Ну вот пожалуйста хотя бы и пример:

Как видно на примере чертёж состоит из двух вставок одного блока (жёлтые прямоугольники) и двух соединяющих их полилиний. Вместе они образуют весьма неплохой "комплексный площадной объект". Если на данном примере блоки не анализировать с точки зрения построения замкнутых областей, то никаких областей мы не обнаружим ибо контур будет разомкнутым.

Если рассматривать возможность разбивания блока...

Зачем разбивать-то? Как-то это моветон...

Если же стоит задача обнаружения точных габаритов содержания блоков...

Нет... так задача не стоит. У нас - комплексный объект (см. пример выше).

Люди сами налажают...

Здесь да! Полностью согласен. Но мы же с Вами создаём универсальный продукт, надо заботиться о всяких пользователях. В Ваших примерах всё чисто и гладко узелок совпадает с узелком... Ну а что вы например думаете по поводу вот такого примера:

Как видите здесь не всё гладко (а может так и задумано) - много линий лежит внахлёст. Как на Ваш взгляд должен выглядеть точный контур такого чертежа? Надо ли его "оптимизировать", как Вам кажется?

[Debalance]

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

Да, вырождение присутствует - факт. Я вовсе не идеализирую оптимизацию... давайте обсуждать эту тему. Но не являются ли подобные построение таких "синтетических объектов" умозрительными экспериментами поиска слабых мест программы? Не оторваны ли эти "ленты Мёбиуса" от жизни?