Open vkomen opened 8 years ago
@vkomen Добрый день! JScript немного не то, в проекте JavaScript
:)
В принципе, можно попробовать, только придется сразу учитывать возможности обоих языков, чтобы портирование на JavaScript
не вылилось в отдельную головную боль.
Я также рассматривал вариант, что модуль реализован в отдельном бинарнике и используется как дочерний процесс (либо удалённый сервис). В этом случае будет не важно, на каком языке он написан, хоть на хаскеле, главное, чтобы он был исполняемым и интегрировался в систему. Не совсем то, чего хотелось изначально, но тоже можно попробовать. (Об интеграции чуть подробнее тут)
Да, конечно JavaScript)) Ок. Можно получить варианты контуров, желательно, разнообразные и нестандартные? Какой процент облоя считается допустимым, а то совершенствоваться можно до бесконечности?
Какой процент облоя считается допустимым, а то совершенствоваться можно до бесконечности?
Жестких ограничений на процент облоя нет, он используется постфактум при расчете стоимости заказа. Но есть другие ограничения, которые влияют непосредственно на поведение алгоритма раскладки.
Можно получить варианты контуров, желательно, разнообразные и нестандартные?
У нас есть pdf с разными раскладками и технологическими ограничениями, можно начать с него.
Да, файл я видел, но можно ли получить их в цифровом виде в указанном формате?
Можно уточнить в каком формате?
Да, сериализованный контур выглядит на данном этапе так. Вместе с контуром передаются параметры, так или иначе влияющие на варианты раскладки. Пример рабочего задания (позже накидаем еще):
[
{
"direction": -1,
"placement": {
"angle": 0,
"position": [
99.0046964681824,
-117.961341244201
]
},
"points": [
{
"anchor": [
99.1111428386275,
-210.947907602644
],
"leftPosition": [
98.68828779675,
-209.441851433616
],
"rightPosition": [
99.1111428386275,
-210.947907602644
]
},
{
"anchor": [
172.979493690178,
-474.111433672774
],
"leftPosition": [
172.979493690178,
-474.111433672774
],
"rightPosition": [
173.403348939455,
-475.620809389246
]
},
{
"anchor": [
176.477501281674,
-476.067555110288
],
"leftPosition": [
174.969891842026,
-476.495372715582
],
"rightPosition": [
357.844024730316,
-424.500257247546
]
},
{
"anchor": [
747.194895065428,
-396.889616550603
],
"leftPosition": [
549.294769175481,
-396.889940176756
],
"rightPosition": [
945.096745750123,
-396.88943479183
]
},
{
"anchor": [
1317.91399700182,
-476.067589020052
],
"leftPosition": [
1136.54654763091,
-424.49923733043
],
"rightPosition": [
1319.42162327254,
-476.495088350884
]
},
{
"anchor": [
1321.41182504771,
-474.111123589381
],
"leftPosition": [
1320.98795607782,
-475.620490687329
],
"rightPosition": [
1321.41182504771,
-474.111123589381
]
},
{
"anchor": [
1395.27953540615,
-210.947605030802
],
"leftPosition": [
1395.27953540615,
-210.947605030802
],
"rightPosition": [
1395.70293149766,
-209.441757362644
]
},
{
"anchor": [
1393.3228357875,
-207.447100204013
],
"leftPosition": [
1394.8276443941,
-207.874846048513
],
"rightPosition": [
1187.97025031783,
-149.161451173886
]
},
{
"anchor": [
747.195620360204,
-117.961341299739
],
"leftPosition": [
971.227218675393,
-117.959821246744
],
"rightPosition": [
523.163176379642,
-117.960876710011
]
},
{
"anchor": [
101.067845420794,
-207.448429538528
],
"leftPosition": [
306.420341002594,
-149.162704522473
],
"rightPosition": [
99.5628660925813,
-207.874668388316
]
}
]
},
{
"floatingEdge": 50,
"materialHeight": 444.5,
"nonWorkingArea": 16,
"trimOffset": 3,
"widths": [
410
]
}
]
Спасибо, смотрю!
Еще примеры в последнем коммите (115378f)
Спасибо, этого более чем достаточно. Напишу как разберусь
Подскажите такой момент. Поверхность цилиндра, если ее развернуть, будет прямоугольником с размерами 444.5мм на 1025мм, правильно? А в каких единицах задается исходная модель - это миллиметры или надо их как-то отмасштабировать? (в файле с описанием есть параметры "widths": [ 170, 400 ]
А в каких единицах задается исходная модель - это миллиметры или надо их как-то отмасштабировать?
Тут наблюдается небольшая вакханалия :)
Основная модель у нас в пунктах, это "нативная" единица измерения в Иллюстраторе. А опции, которые следующим параметром идут -- в миллиметрах, как людям удобнее.
Я пока что ставлю единицы измерения в комментариях в интерфейсе. Унифицируем их когда ситуация более-менее стабилизируется.
Подскажите такой момент. Поверхность цилиндра, если ее развернуть, будет прямоугольником с размерами 444.5мм на 1025мм, правильно?
(в файле с описанием есть параметры "widths": [ 170, 400 ]
это размер объемлющего прямоугольника?)
Не совсем. Надеюсь, эти иллюстрации помогут вам разобраться.
Ага, понял 2 новых вещи для себя
То есть для производства каких-нибудь форм можно закладывать ленты разной ширины (длины), и пытаться в них уместиться, правильно? Максимально 410, минимально 170мм
ширина задается в задании массивом порезов. в данном примере это два значения 170 и 400 мм. максимально возможный порез материала 410 мм, минимальный условно принят 110 мм. это так для сведения, главное что раскладки необходимо формировать только под порезы (widths) из task-а.
Что еще непонятно?
Давайте я тогда попробую сформулировать задачу, как я ее понял, а вы поправьте, если что не так
да, все верно. добавлю только что варианты раскладок для одной ширины нужно отфильтровывать перед выводом. в данном примере (см. иллюстрации) для ширины материала 400 мм возможны два варианта: с одним контуром и с двумя. соответственно вариант с одним контуром надо исключить из выхлопа.
Спасибо, позже выйду на связь
Не исчезайте надолго. :)
Скажите еще такую вещь. Вырезаемые фигуры должны быть все повернуты на один и тот же угол (ну за исключением случая с капельками, где присутствует отражение)?
В общем, да, на один угол. Для нестандартных случаев (как с каплями) мы хотим ввести в интерфейс опцию "Разрешить произвольную раскладку", которая обрабатывала бы такие неординарные случаи. И не обязательно только капли, это могут быть любые формы. К примеру, банановидные формы тоже можно раскладывать с разным углом поворота (с включенной опцией).
Отражение - не совсем корректный термин. В случае с каплями это все-таки поворот на 180 градусов.
По идее, разрешение произвольной раскладки должно снимать следующие ограничения:
Ну а цель в любом случае одна - снизить облой?
Цель - сделать оптимальную раскладку, удовлетворяющую технологическим требованиям. Оптимальная - значит с наибольшим количеством элементов и наименьшим облоем.
Как было сказано выше:
Какой процент облоя считается допустимым, а то совершенствоваться можно до бесконечности? Жестких ограничений на процент облоя нет, он используется постфактум при расчете стоимости заказа. Но есть другие ограничения, которые влияют непосредственно на поведение алгоритма раскладки.
Что такое наложение ручьев понятно?
если опция, разрешающая произвольную раскладку не включена, раскладка капель может выглядеть так:
Нет, наложение ручьев не понятно! объясните плиз
Светло-зеленым цветом показано наложение, которого следует избегать. Это понятно? Или не до конца? Важно, чтобы вы хорошо понимали это ограничение.
Теперь понятно, да! Но это сильно ограничивает возможности оптимизации площади... То есть решение сведется к расчерчиванию ленты на прямоугольнички (ну или параллелограммы), в которые должны быть помещены фигуры. Это строгое ограничение???
Да, такие ограничения. Но не забываем про опцию РАЗРЕШИТЬ ПРОИЗВОЛЬНУЮ РАСКЛАДКУ.
ну то есть нельзя, но если очень хочется, то можно))) Ок, будем двигаться от простого к сложному
Мы смотрим на картинку, на которой изображена форма капли, но вместо капли может быть любая другая форма, и может так случится, что эта неизвестная форма на два ручья не раскладывается. упс... А смотреть, к тому-же, должен не человек, а алгоритм. В этом-то весь фикус и вся сложность задачи :)))
Коллеги, 2 важных вопроса
Хорошие вопросы. :)
Могут быть фигуры с вырезами внутри? Типа бублика)
Да, могут.
Нужно ли проверять на валидность исходную фигуру, заданную в кривых Безье, или есть гарантия, что она всегда правильная и замкнутая?
Проверять на замкнутость мы планировали сами, на стороне Иллюстратора. А что значит "правильная"?
Я так понимаю, если фигура состоит из одного контура (Path), то главное, чтобы контур был замкнутым, а направление вектора не имеет значения для работы Solver. Или я ошибаюсь?
Возможны проблемы, если контур будет содержать петли. Каким образом обрабатывать этот момент, я пока не представляю.
Когда фигура составная (Compound Path), мы имеем дело с двумя или более контурами. В этом случае, надо определить внешний контур и плясать (trimOffset) от него.
Опять-же здесь возможны проблемы, если составные контуры будут пересекаться, то trimOffset от внешнего контура будет невалидным.
Если у вас есть мысли на этот счет, можете поделится ими.
Эти варианты всяко придется рассматривать. Ок, сейчас я допилю первую версию, потом можно будет ей скормить большое количество реальных контуров, там посмотрим
Ок, мы подготовим tasks с разнообразными формами контуров и различными параметрами.
как дела? может помощь нужна?
Еще день-два, я покажу, что получилось, и тогда уже поговорим развернуто ,ок?
Ок.
Ну что же, начало кое-что получаться. Пока без наложения ручьев. Вот такие картинки - это предложенные фигуры в разных размерах, она пытается их упаковать на ленту:
Расположение элементов по ручьям нас устраивает. А вот масштабировать исходный контур ни в коем случае нельзя.
Можно не выкладывать сюда изображения получившихся раскладок.
Попробуйте не масштабировать исходный контур и вышлите нам готовые solutions для этих tasks в формате json. Мы "нарисуем" их в Adobe Illustrator и сможем озвучить конкретные замечания и пожелания по получившимся раскладкам.
Ок, есть несколько вопросов. Я так и не понял, как узнать ширину вырезаемой фигуры в миллиметрах, поясните плиз! Точность всяких допусков в 1 миллиметр - это нормально или нужно точнее? Потом, у меня нет пока экспорта в JSON, ну это недолго. И хочу сейчас обсудить финансовую сторону.
Ок. Финансовые вопросы лучше обсуждать не здесь. Если есть предложения, пишите мне на почту. У нас тоже есть к вам вопросы.
to @vkomen
Вот он, момент истины :)
Теперь, когда Вы в теме, можно и к делу – почему эта задача не совсем обычная.
Есть алгоритмы размещения деталей в заранее известную (даже не прямоугольную) область заполнения. С этим мы сами худо-бедно справились.
Главный вопрос жизни, вселенной и всего такого – можно ли оптимально разместить деталь в заранее неизвестную область.
Чуть выше, прямо перед «Примером неэффективной раскладки» как раз такая область и изображена (это синий контур вокруг деталей). И алгоритму она заранее не известна. Ещё примеры: тыц, тыц.
Итак, главный челлендж: мы знаем площадь заполнения, но не знаем её форму. Другими словами, нам надо набить максимум деталей (с технологичными условиями, понятное дело) незнамо куда. Но это самое «незнамо» должно затем «свернуться» в цилиндр и превратиться в условно бесконечную ленту.
Чего бы нам хотелось от Вас: дать оценку в деньгах. Сможете решить вот именно такую задачу? Если да, то озвучивайте цену и Ваши соображения на почту @robespier. Затем, если сходимся по цене, то ждем от Вас солюшены в формате json. Не исключено, что процесс будет итеративный. Но это позволит Вам показывать решения без раскрытия исходников, а нам убедиться, что решения действительно рабочие и за это можно заплатить.
И да, предлагаю уже новые issues заводить, а не писать в эту портянку :)
Добрый день Интересно попробовать. Устроит ли такой вариант работы - прототип программы будет написан на другом языке, если результаты подойдут - перенесем на JScript?