Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - АлексЮстасу

Pages: 1 [2]
16
Из общего еще не хватает сообщений в окне сообщений в режиме указания точек, что создан/не создан контур.

17
Ну а как же BPOLY? Ведь она же успешно работает с блоками. Мы же позиционируем SuperBoundary как наследника BPOLY, поэтому всякое урезание наследуемых возможностей выглядит как добровольная кастрация...
Что касается текстов-мтекстов, то конечно, использовать эту опцию при создании контуров-полилиний нелогично. Данную возможность надо привязывать к режиму заливки.
Что блоки, что тексты/мтексты - к площадным объектам отношения не имеют.
Но я потому про тексты/мтексты и заговорил, что Вы-то делаете аналог.
Кстати я тут заметил, что команда штриховочки (BHATCH) на последних версиях AutoCAD работает веселее не в пример BPOLY... Может вся эта затея с реализацией идеальной BPOLY не стоит "ломаного яйца"? Может ребята из AutoDesk подтянут BPOLY к достойному уровню производительности в версиях AutoCAD 2019-2020? И вся наша возня напрасна?
Дело же не только в скорости, но и в точности, в полноте и в выполнимости. А с этим у этих команд не очень.
Дело же наше в принципе неблагодарное - чужие дырки затыкать...
Но всегда же есть надежды на полезность разного рода такой работы.

18
Полагаю такой вариант не подходит. Нужна однозначность - или мы работаем с блоками в обоих режимах (заливка/обводка) или игнорируем полностью.
Я в принципе за однозначность - ни блоки, ни тексты-мультитексты программой поиска-создания контуров не следует вообще учитывать. Может быть это нужная задача, но отдельная. И решать ее нужно другой программой, самостоятельной.
Мое предложение расположить рядом не означает связывание опций, не означает, что они должны включаться синхронно.

19
Растущее диалоговое окошко может перестать быть удобным...
Это да...
Может быть расположить опцию в одной строке с Заливать контуры? Вроде бы по смыслу.
Кстати - реплика - если обводить блоки, то и тексты-мтексты тоже бы? Если исходить из логики, чтобы блоки-мтексты были видны на штриховках - как BPOLY.
А для уменьшения опций можно, допустим, упростить варианты с цветами-слоем:
Параметры полилиний:
- цвет,
- произвольные цвета,
- слой.
Т.е. убрать "мой" и "текущий" цвет, слой. Текущие - по умолчанию.

20
Пардон!
Не Alt H, а Ctrl H.

Опциональность обводки блоков не обсуждается?

21
Имел в виду: один контур + все островки в нем = одна группа.
Включение-отключение отображения групп - Alt H.
А без групп вроде бы нет другого способа объединить, связать, показать площади с их островами, если они полилиниями.

22
Насчет островков - хорошо бы обнаруженные островки сразу со своим общим внешним контуром объединять в группу. Чтобы появилась и была и зрительно видна их логическая связь.

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

23
Вроде бы все контуры при отключенной Оптимизировать контуры строятся во всех подробностях.  :)

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

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

25
Если целью использования программы является создание контуров площадных объектов, то блоки не могут участвовать в создании контуров.
Давайте начнём с догматов: что есть "площадной объект" и почему, например, внутри блоков не может быть "площадных объектов"? Я так понимаю, что в качестве блока может быть что угодно... иными словами блок внутри себя может содержать какой угодно объект. Или я не прав?
Давайте догматы. По типу локализации все плоские геометрические объекты делятся на площадные, линейные и точечные. Блоки суть точечные объекты, т.к. геометрически характеризуются одной точкой, точкой вставки. Точечные объекты никак не могут определять границы площадных.
Что внутри блока - вопрос совсем другой.
Если рассматривать возможность разбивания блока, то ведь после разбивания исчезает этот точечный объект, а появляются иные, его составляющие объекты: площадные/линейные/точечные.
Если для каких-то целей для описания границ площадных объектов использовались блоки (для одинаковых помещений или т.п.), то перед поиском контуров площадных объектов такие блоки естественно разбивать, чтобы получать соответствующие линии границ.
Если же стоит задача обнаружения точных габаритов содержания блоков, то это другая задача, которую и нужно решать отдельно. Пусть и с использованием таких же алгоритмов.
Пример посмотрел. Под указанной на чертеже фиолетовой стрелочкой вижу практически идеально прямую линию. Факт наличия стыковочного узла под ней признаю.
Впрочем если вопрос чрезвычайно важен готов в следующей версии предусмотреть опцию отключения оптимизации контура.
"Практически идеально прямую" - это и есть округление, т.е. искажение. Отклонение узла там 0.0044. Специальный тестовый зубчик на желтой линии 0.0062. Т.е. того же порядка, но он отобразился контуром. Ширина "горлышка" - 0.0058, но тоже не стало препятствием. Хотя оно дает "практически идеально совпадающие вершины".
Сейчас контуры строятся идеально, если не считать этой "оптимизации".
Люди сами налажают. Пусть оптимизациями занимаются специальные программы. Любая программа по-моему должна делать только то, для чего предназначена. И не должна делать ничего сверх.

26
Quote from: АлексЮстасу
Мое предложение сделать учет блоков опциональным не подходит?
Размышляю. Пока такая заявка поступила только от Вас...
По-моему, это следует из общих соображений. Если целью использования программы является создание контуров площадных объектов, то блоки не могут участвовать в создании контуров.
Quote from: АлексЮстасу
И осталось упрощение полилиний-контуров за счет удаления "лишних" вершин, что приводит к искажению геометрии.
Здесь тоже вопрос дискуссионный. Положим есть прямая линия, состоящая из большого количества сонаправленных отрезков. В результате генерации контура имеем прямой отрезок полилинии с таким же количеством узлов. Оно надо?
Оно, во-первых, ничему не мешает. А, во-вторых, именно что надо, т.к. "прямая линия, состоящая из большого количества сонаправленных отрезков" - условность. Прямизна и сонаправленность существуют в пределах каких-то точностей их подсчетов. Одним же из главных смыслов альтернативной Boundary является построение точных контуров.
Quote from: АлексЮстасу
Приложение здесь не приложить...
Поковырялся в настройках форума - должно сработать.
Приложил пример с неточностью создаваемого контура.

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

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

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

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

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

Pages: 1 [2]