QPolygonF - сжатие (inflate)

[alexis031182]

На простом полигоне это работает. Я просто добавил свой полигон в Ваш код. Взгляните.

[alexis031182]

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

[Igors]

На простом полигоне это работает. Я просто добавил свой полигон в Ваш код. Взгляните.

Ну так у Вас длины отрезков примерно 1.0, а величина выдавливания 20 - конечно перехлестнет. Используйте разумную амплитуду - напр 0.5

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

Вникнуть в текст (засоренный модными итераторами) трудновато. Покажите исходную одним цветом а построенный контур другим - и будет ясно

По поводу возможных само-пересечений. Это типовая проблема если исходная поли-линия слишком "зубатая" и/или амплитуда слишком велика. Пока на Ваших картинках такого не видел. Чаще всего эту проблему "никак не решают" (т.е. отдают на откуп пользователю считая что он задаст разумные значения). По-настоящему хорошего/нормального решения там нет, надо так или иначе латать. Это можно долго обсуждать, но сначала давайте разберемся чего не хватает и откуда перехлесты.

[alexis031182]

Ну так у Вас длины отрезков примерно 1.0, а величина выдавливания 20 - конечно перехлестнет. Используйте разумную амплитуду - напр 0.5

Да, точно, Вы правы, использовал неподходящую амплитуду. Отрисовало также как у меня.

Вникнуть в текст (засоренный модными итераторами) трудновато.

QVectorIterator, что в нём модного? С итераторами очень удобно, если индексы особо не нужны.

Покажите исходную одним цветом а построенный контур другим - и будет ясно

Нарисовал. Чёрный цвет - исходный полигон. Красный - "сжатый". Видна петля у красного контура в нижней части изображения с левой стороны.

По поводу возможных само-пересечений. Это типовая проблема если исходная поли-линия слишком "зубатая" и/или амплитуда слишком велика.

Мне нужно избавиться от точек в сжатом полигоне, которые образуют петлю. Точки будут основой для вывода текста. И соответственно, если оставить петли, то текст будет выводиться и по точкам этих петель. Получается очень не красиво.

Пока на Ваших картинках такого не видел.

Ну как же. На всех скриншотах я жирным маркером красного цвета обвёл места, где петли выводятся.

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

Перехлёсты (петли) получаются в узких местах полигона, когда вектор нормали (или как его правильно назвать) получается длиннее чем половина ширины узкого места полигона. Тут наверное надо как-то определять ширину узкого места, чтобы выводить точки для сжатого полигона на расстоянии от исходной, вычисляемого по коэффициенту, а не на основе постоянной величины. Либо найти способ, как удалить точки петель, скажем, вторым каким-нибудь проходом по точкам сжатого полигона. Я пробовал добавлять метод вырезания точек, расстояние между которыми меньше задаваемого минимума. Часть точек петли конечно вырезается, но опять же не все.

[Igors]

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

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

[alexis031182]

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

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

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

[Igors]

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

Ну резать так резать Можно напр сделать метод "удалить само-пересечения", потом (если понадобится) подгладить эти места. Тут надо (немного) подумать, до завтра сделаю

[alexis031182]

Ну резать так резать Можно напр сделать метод "удалить само-пересечения", потом (если понадобится) подгладить эти места. Тут надо (немного) подумать, до завтра сделаю

Хм... спасибо большое! Я над этим уже три дня бьюсь. Единственное, что смог придумать - это выполнять свою offset-функцию совместно с функцией вырезания точек по минимально допустимой длине линии в несколько итераций. Но с каждой такой итерацией сжатый полигон естественно всё больше сужается и "огрубляется" (меньше следует форме исходного полигона). Да, петли удаляются полностью, но конечный результат "не вставляет", т.к. у меня есть совсем уж аляпистые полигоны, у которых узкие и широкие области могут понескольку раз перемежаться.

P.S. Контуры берутся из векторного SVG изображения, которое в свою очередь создаётся векторным редактором из растровой картинки.

[alexis031182]

Igors, подскажите хоть суть метода "удалить само-пересечения". Каким образом это можно сделать?

[kamre]

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

А что вы хотите делать с отделяющимися и исчезающими островками вроде таких:

?

[alexis031182]

Круто! А как Вы так сделали?! Островки оставить конечно, я их отдельным полигоном оформлю. Поделитесь, если не жалко алгоритмом.

[kamre]

Круто! А как Вы так сделали?! Островки оставить конечно, я их отдельным полигоном оформлю. Поделитесь, если не жалко алгоритмом.

Это коллеги по работе в проекте реализовывали вычисление offset, нужно было для того, чтобы определять места, куда можно поставить круглые присоски при поднятии детали, вырезанной из листового материала. А я просто взял ваш полигон и запустил на нем вычисление offset с разной величиной.

Проект не open source, так что кодом поделиться не могу. А алгоритм брали и реализовывали по статьям вроде этой и других, которые ищутся в google.

Так что предлагаю подождать решение от Igors, интересно будет посмотреть на выбранный им алгоритм...

[Igors]

[Так что предлагаю подождать решение от Igors, интересно будет посмотреть на выбранный им алгоритм...

Делаю, скоро будет 

[alexis031182]

Нашёл в инете на C# (или типа того, их хрен разберёшь) пример. Переписал на C++, но тоже самое - петли в узких местах. Хоть сам полезай в оную ))

[Igors]

Хоть сам полезай в оную ))

Держитесь, помощь идет

(из послания к окруженной в Сталинграде армии)

Ну в общем сделал (аттач). Довольно трудно, в каких-то случаях остаются "пипсики" которые формально корректны, но конфузят.

Нашёл в инете на C# (или типа того, их хрен разберёшь) пример. Переписал на C++, но тоже самое - петли в узких местах.

Ну да, легко смеяться над глупыми велосипедистами, а припрет - и где же оно, то "готовое решение" которое так экономит время и силы ?  

Edit: удалил аттач чтобы был только последний (см ниже)