Работа
GameDev.ru / Работа / Форум / C# Смещенная кривая (10 стр)

C# Смещенная кривая (10 стр)

Страницы: 19 10 11 1214 Следующая »
Alex_HellПостоялецwww10 июля 201817:14#135
MrShoor
> И спрашиваешь чем не устраивает? Rly? Ну тогда я могу только предложить тебе
> перечитать еще раз цитируемое предложение.
Да спрашиваю чем не устраивает. Объяснить можно? Судя по вашим комментариям, вы писал "нужна производительность, не ниже Х" - причем тут она? Если вам важна производительность вы ее в основном объяснении не написали! Если вам нужно ключевое - поддерживать сегменты дуги (Arc) то это и пишите. Если вам нужна точность - объясните какая точность вам нужна, и для чего, и чем не устраивает текущая реализация.
И распишите - какова подробней какая текущая.

Предположительный flow вашей программы такой:
1) по аналитическим кривым (у вас только Line, Arc, нет безье), строиться эквидистанта, да хотябы AGG библиотекой (C++), получается контур из аппроксимированных точек, с Х точностью

Вот тут уже получается аппроксимированные точки, сразу; но чем вас точность double не устраивает? Вы уверены что если вы дадите аналитические кривые в самом конце то будет точнее для ваших целей? Их можно изначально по всему pipeline аналитически прогонять - что сложно, или делать rebuild из вершин в аналитику в самом конце, с определенной погрешностью (интерполяция кривыми), или даже без нее (сложно, надо поддерживать mapping из исходных аналитических - в итоговые вершины, и потом по вершинам, с учетом пересечений, сделать обратно).

2) применяется что-то типо clipper либы (http://www.angusj.com/delphi/clipper/documentation/Docs/Units/Cli… yPolygons.htm), которая находит пересечения между вашими линиями, и в точках пересечений решает - куда продолжить контур, т.е. rebuild контура, разрывая места пересечений, продолжая в другую сторону, и строя полигоны (уже несколько могут получиться, в том числе дырки) без само-пересечений

MrShoor
> О каком замыкании идет речь? Нарисуй.
Нарисовал:
http://prntscr.com/k4rvoy
Если вам нужно обрабатывать такие пересечения методом универсальным - т.е. построение другого контура - я не понимаю из доменной области зачем это? Помоему надо выдавать ошибку при пересечении 2х контактных offset-контуров, которые стали пересекаться, хотя не должны, а сам алгоритм будет выдавать offset-контуры очень простые.

Более того - это подтверждается вашими же словами
MrShoor
> Более того, между площадками и дорожками должен быть определенный зазор, чтобы не было пробоя и каких либо наводок

А также я не увидел ни 1 Arc тут (ваш скрин, ссылку сделал)
http://prntscr.com/k4rx7e

Правка: 10 июля 2018 17:16

ASPПостоялецwww10 июля 201818:26#136
Постановка задачи на текущий момент не полная. Я приводил пример в котором не понятно что желает видеть заказчик, есть подобный пример и для внешнего контура, когда есть две дуги и проводя внешний контур придется увеличить кол-во дуг, это можно сделать несколькими способами, в зависимости от точных требований, но пока точных требований не было озвучено. Ещё раз повторю вопрос про внутренний контур:
кривая | C# Смещенная кривая
как в данном случае должен выглядеть внутренний контур (красный) когда расстояние больше радиуса дуги во входной кривой?
Или вы тут реально только софистикой занимаетесь?
MrShoorУчастникwww10 июля 201822:06#137
Alex_Hell
> Да спрашиваю чем не устраивает. Объяснить можно?
Написано же, точностью.

> Судя по вашим комментариям, вы писал "нужна производительность, не ниже Х" -
> причем тут она?
Чтобы не вышло, что после замены решения с апроксимации на честные арки производительность упала в 10 раз.

> Если вам нужно ключевое - поддерживать сегменты дуги (Arc) то это и пишите.
Так это вроде и написано. Изначально то у меня есть арки, а после операции экспанда - уже нет. Вот нужно поддерживать арки на всех этапах работы.

> И распишите - какова подробней какая текущая.
Сейчас чтобы построить экспанд каждый сегмент и арка обкладывается аппроксимирующим полгином по отдельности. Потом все эти полигоны объединяются булевой операцией union с помощью алгоритма Vatti.

> 1) по аналитическим кривым (у вас только Line, Arc, нет безье), строиться
> эквидистанта, да хотябы AGG библиотекой (C++), получается контур из
> аппроксимированных точек, с Х точностью
> Вот тут уже получается аппроксимированные точки, сразу; но чем вас точность
> double не устраивает?
Это не точность double, это погрешность X+double. Где X очень большой по сравнению с точностью double.

> Нарисовал:
> http://prntscr.com/k4rvoy
Ок. Поясняю. Эквидистанта вокруг трека - это пустоты. Там меди не будет. Поэтому и не будет замыкания.

> А также я не увидел ни 1 Arc тут (ваш скрин, ссылку сделал)
> http://prntscr.com/k4rx7e
На данном скрине во входных параметрах арок может быть и нет. Но
1. Арки будут в эквидистантном контуре, то есть арки нужны на выходе. Нарисуй просто отрезок. Потом нарисуй вокруг него эквидистанту, и найди в этой эквидистанте арки.
2. Арки так же могут быть во входных данных, например можешь поискать тут:

+ Показать

MrShoorУчастникwww10 июля 201822:13#138
ASP
> как в данном случае должен выглядеть внутренний контур (красный) когда
> расстояние больше радиуса дуги во входной кривой?
Вроде бы понятно, что должен выглядеть так, как ты его и нарисовал.
Вот тебе полный рисунок твоего случая:
+ Показать

На входе 2 отрезка и одна арка. На выходе 4 отрезка и 3 арки.
Alex_HellПостоялецwww11 июля 20182:37#139
ASP
> На данном скрине во входных параметрах арок может быть и нет. Но
> 1. Арки будут в эквидистантном контуре, то есть арки нужны на выходе. Нарисуй
> просто отрезок. Потом нарисуй вокруг него эквидистанту, и найди в этой
> эквидистанте арки.
> 2. Арки так же могут быть во входных данных, например можешь поискать тут:
Помоему это усложнение ради усложнения. Если допустимы только прямые линии оно же проще в разы. Вот какой профит от того что у вас на выходе будут арки вместо полигонов? А на входе? Что ухудшиться если их не будет? Зачем решать абстрактные задачи, вроде "сделайте мне алгоритм оффсета чего угодно", когда есть конкретные проблемы в ПО, их и надо решать, при возможности упрощая, в том числе времязатраты и бюджет.

MrShoor
> Чтобы не вышло, что после замены решения с апроксимации на честные арки производительность упала в 10 раз.
это из той же оперы. Ну выкиньте вы свои арки и не упадет у вас про-ть.

MrShoor
> Это не точность double, это погрешность X+double. Где X очень большой по
> сравнению с точностью double.
Покажите тестовые варианты. Я не вижу где тут может упасть точность. Помоему вы решаете не те задачи. Всегда, повторю, ВСЕГДА, можно точность повысить, без аналитики. В любых расчетах есть вещественные числа а не аналитика. Вы там не ракету запускаете. Вам не хватает double?! Серьезно? Помоему вы не умеете его готовить. И даже если не хватает, напишите свою математику или заюзайте, с произвольной точностью - даже это будет быстрее в разработке чем универсально аналитику юзать.

p.s. у меня проект связанный с векторной графикой, я юзаю вообще float и мне хватает его для увеличения векторных фигур в 100 раз. А вам double не хватает. А теперь вопрос - а как вы определили что вам не хватает именно точности. И где это место? И почему оно так? И если даже так, чисто гипотетически, ну с чего вы взяли что что-то поменяется если вы будете аналитически проверять скажем точки пересечений в том же double, и вам хватит такой точности? Я считаю у вас просто баг есть, в какой-то аппроксимации.

Правка: 11 июля 2018 2:56

Alex_HellПостоялецwww11 июля 20183:21#140
MrShoor
> Сейчас чтобы построить экспанд каждый сегмент и арка обкладывается
> аппроксимирующим полгином по отдельности. Потом все эти полигоны объединяются
> булевой операцией union с помощью алгоритма Vatti.
помоему даже тут косячно выглядит.. каждый сегмент? что у вас сегмент?

и по скрину http://prntscr.com/k4ytl8 это НЕ эквидистанта

MrShoorУчастникwww11 июля 20183:33#141
Alex_Hell
> Помоему это усложнение ради усложнения.
Это по твоему. Узость кругозора, такое бывает, ничего сташного.

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

> это из той же оперы. Ну выкиньте вы свои арки и не упадет у вас про-ть.
Ты это, приходи к нам, и научи тут всех нас как надо. А то мы же тупые тут сидим, да. На одного тебя умного надежда.

> Вы там не ракету запускаете.
Чувак, мы электронный CAD. На нашем софте могут делать все что угодно, ракету в том числе.

> Вам не хватает double?!
Я писал что нам хватает double. Учись читать уже, а не только писать.

> А теперь вопрос - а как вы определили что вам не хватает именно точности.
А теперь вопрос, как ты определил, что нам double не хватает? Вот серьезно, приведи пример, где я говорю, что нам не хватает точности double.

> и по скрину http://prntscr.com/k4ytl8 это НЕ эквидистанта
В пеинте рисовал по быстрому. Так лучше:

+ Показать

?

Alex_HellПостоялецwww11 июля 20185:35#142
MrShoor
> Множество профита. Мне не хочется тебе рассказывать что такое DRC, рассказывать
> про механические кады и про построение лодов для ускорения рендера.
Ну так расскажите. И мы не переходили на "ты" если что.
Это вы пришли сюда со своей проблемой, и в поисках помощи, а не я. Если вам ее не надо - да пожалуйста.

Если по конструктиву: я знаю что такое LOD и еще раз повторю - что работаю в проекте с векторной графикой. И мне внезапно хватает точности вершин, для моих кривых безье. У вас жесткие лимиты на число вершин? Вопрос о точности открыт. Уменьшайте шаг интерполяции на высоком приближении, если дело в рендере. У меня вообще-то рендер при 100х делает огромное число вершин на единицу расстояния, а на 1х намного меньшее - но покрывает больший объем изображения.

Alex_HellПостоялецwww11 июля 20185:37#143
MrShoor
> На такой плате даже с грубой аппроксимацией полигоны легко улетают в 100К+
> вершин, и такой полигон там не один. Их десятки.
MrShoor
> В данный момент задачу заливки полигонов мы решаем через аппроксимацию.
> Аппроксимацию определяет пользователь.
Это те цитаты что из старых я нашел..
В чем проблема то? Делайте 1кк вершин при приближении 100х.

Правка: 11 июля 2018 5:38

Alex_HellПостоялецwww11 июля 20185:40#144
MrShoor
> Кроме того, для передачи в MCAD нам сейчас приходится после заливки полигонов
> аппроксимировать кучу отрезков дугами, потому что MCAD-ы тупо не справляются с
> полигонами, которые имеют сотни тысяч вершин.
Если в этом проблема - ну так найдите MCAD который сможет миллион вершин переварить.

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

MrShoorУчастникwww11 июля 20186:24#145
Alex_Hell
> Ну так расскажите.
А есть смысл?

> И мы не переходили на "ты" если что.
Ну это ты может быть не переходил. А я с самого начала с тобой общался на ты. Но почему-то последний пост тебя задел, странно, да?

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

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

> Уменьшайте шаг интерполяции на высоком приближении, если дело в рендере.
Шаг интерполяции чего? Мне чтобы рулить шагом интерполяции нужна аналитическая кривая, а после пуринга у меня её нет. Собственно об этом и нульпост, построить аналитическую кривую вокруг другой заданной кривой. Ты читал вообще этот пост:
https://gamedev.ru/job/forum/?id=236674&page=3#m30 ?

> Это те цитаты что из старых я нашел..
> В чем проблема то? Делайте 1кк вершин при приближении 100х.
Их уже сейчас может быть 1КК, при этом при приближении полигоны выглядят довольно погрызаными, а точность апроксимации находится на грани допустимой.

> Если в этом проблема - ну так найдите MCAD который сможет миллион вершин переварить.
Что значит найдите MCAD? Нам не нужно искать какой-то MCAD, нам нужен вполне конкретный MCAD.

> Если так уж хочеться - делайте вашу аппроксимацию в обратную сторону из вершин в дуги, в самом конце.
Гениальный совет. Но мы уже делаем это. Попробуй читать, что тебе пишут, ибо в посте #141 я писал:

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

slepovПостоялецwww11 июля 201811:29#146
Alex_Hell
Я не из клуба Алтиум, но согласен что в задаче есть смысл. Вот смотри. Если кривая задается арками, то у тебя на входе по 2 вершины на отрезок и по 3 вершины на арку. Т.е. 5 вершин на простой path в виде отрезка и арки. А теперь делаем аппроксимацию арки. Можно смело сказать что кол-во вершин увеличивается ну в 3 раза как минимум. А теперь давай вспомним основные алгоритмы выч геометрии. Их сложность почти везде зависит от кол-ва вершин. Сложность равна N^2, NLogN.. зависит от алгоритма. Вот и выходит, что метод с апроксимацией довольно здорово увеличивает нагрузку.
А примеры их печатных плат ты видел, там хренова туча этих path. А если еще учесть что CAD должен быть комфортным в работе то это означает что он должен на лету все обновлять и пересчитывать. Это я к тому чтоб ты и другие не задавали тут вопросов вроде "а нафига это надо.. ну что за проблема обсчитать 100к вершин".
Перфоманса никогда не бывает много.
Alex_HellПостоялецwww11 июля 201816:03#147
MrShoor
> Если ты внимательно почитаешь, то я сюда пришел не в поисках помощи, а лишь для
> того, чтобы сказать, что конкретно эта задача сложная. Но тут набежали ребята,
> и стали доказывать, что это легко. Ну раз это легко, то я им и предложил
> попробовать сделать.
Мне это доказывать не надо, я итак знаю. Считаю что никто за разумное время из вышеотписавшихся не сможет решить такую задачу из 0-поста. Я рассматривал только разные упрощения, чтобы получить лучше, чем ничего.
Alex_HellПостоялецwww11 июля 201816:09#148
slepov
> Их сложность почти везде зависит от кол-ва вершин. Сложность равна N^2, NLogN..
> зависит от алгоритма. Вот и выходит, что метод с апроксимацией довольно здорово
> увеличивает нагрузку.
> А примеры их печатных плат ты видел, там хренова туча этих path. А если еще
> учесть что CAD должен быть комфортным в работе то это означает что он должен на
> лету все обновлять и пересчитывать. Это я к тому чтоб ты и другие не задавали
> тут вопросов вроде "а нафига это надо.. ну что за проблема обсчитать 100к
> вершин".
> Перфоманса никогда не бывает много.
Теперь я вижу что проблема в пересчете, при изменении приближения и позиции камеры, да это проблема. Но она не была озвучена никем. Если бы ее озвучили сразу - я бы и не стал глупости предлагать.

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

slepovПостоялецwww11 июля 201816:17#149
Alex_Hell
при изменении приближения и позиции камеры

Камера то тут причем.. Вы игнорите задачу в ее начальной формулировке, и додумываете свои. Кто сказал что проблема в прорисовке этих фигур? В CAD-ах нужна самая разная инфа о геометрии для разных нужд. И прорисовка тут как раз меньшая из проблем.
Страницы: 19 10 11 1214 Следующая »

/ Форум / Работа / Разовая работа

2001—2018 © GameDev.ru — Разработка игр