Войти
ПроектыФорумУтилиты

[beta] Упаковщик атласов - Cheetah Texture Packer (auto-size ver.) (5 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 14 5 6 721 Следующая »
#60
14:49, 19 мая 2012

Было бы замечательно :)
Вообще, очень удобная утилита - хорошо, что я на нее наткнулся. Спасибо :)


#61
18:18, 19 мая 2012

KoloDen
> Вообще, очень удобная утилита - хорошо, что я на нее наткнулся. Спасибо :)
В целом, не за что:)

Вот такой пробный эксперимент: если ширина или высота картинки равна размеру текстуры, бордер не добавляется. так можно добавлять на атлас текстуры 1024 пикселя. Но зачем?

Снимок экрана - 19.05.2012 - 18:13:37 | [beta] Упаковщик атласов - Cheetah Texture Packer (auto-size ver.)
#62
14:07, 20 мая 2012

RPG
> Но зачем?
Ну я уже понял про проблемы с масштабированием, так что, в принципе, незачем.

#63
23:26, 7 авг. 2012

Закоммитил небольшое изменение - был баг с обрезкой текстур. Теперь режет только по прозрачным пикселям.

Из крупных правок - поддерживается русский и английский языки. Те, у кого ОСь настроена на русский язык, увидят русифицированную версию программы.

#64
18:41, 13 авг. 2012

Годно, особенно из-за кросс-платформы.
Я бы даже чем-нибудь помог в разработке.
Хотелось бы добавления картинок по одному файлу и драгндроп.

#65
22:16, 13 авг. 2012

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

#66
12:08, 16 авг. 2012

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

Буду хаять:
1. Выложил код -> нашли баги -> исправил -> выложил исправленный.
Вин7 - прозрачная картинка, не воспринимает рус. папки (? это што за ептитть!), экспортирует только .atlas файл (мучал полчаса так и не понял каким магическим образом экспортить пнг).
2. GUI  и возможности - лишние кнопки -> лишние действия -> потеря времени.
Heuristic - выбросить, должна происходить выборка внутри кода. Ну и ежу понятно что кроме TopLeft остольное ненужно.
Sort - выбросить, должна происходить выборка внутри кода.
RotataIf - ну млин выдумщик, ротировать если четные/нечетные дни забыл добавить. Опция должна быть одна - ротировать или нет. Соответственно если да то любые изображения с не равными краями будут вращаемы.
3. Отсутствие возможности установить параметры для отдельного элемента (все врощаемы кроме мну / у мну бордер специфичный).
4. Border больше 1 фактически не нужен - соответственно  вкл/выкл а не выбор числа.
5. Crop/Merge - сие не ясно для чего так как все прозрачное и не видать.
6. Где duplicate pixels on border? То есть вокруг квада на один пиксель повтор соседнего(принадлежащего картинке).
7. Где анализ pixel-data и нахождение совпадающих участков (по желанию - я не реализовывал данную фичу но делается на коленке за сутки).

Реализаций MaxRects в сети до крыши (адаптирование для своего фреймоврка от 1 часа до суток).
Привязка к GUI элементам (сутки от силы).
Оптимизация алгоритма (ну пара суток от силы).
Плюс доработка мелких багов как получиться.
=максимум неделя. Хде работающий код в итоге?

Об оптимизации:
MaxRects имее поганую особенность кучковать в одном угле основную массу и вытягивать "руки" вдоль дух ближайших краев (лечиться) (в посте 34 на картинке как раз видать кучу пропавшего места).
Переборка вариантов должна быть ВНУТРИ кода, а пользователь должен видеть только один (самый лучший) результат. Как определить самый лучший: меньше площадь, больше занятость.
Вывод/запись результирующей картинки подогнанной к POT размерам (например упихало оно в 125х290, значит показываем/экспортим 128х512).

Вывод: головная боль / потерянное время для пользователей прие обработке N-ного количества атласов.

#67
13:00, 16 авг. 2012

Zloten
> Вывод/запись результирующей картинки подогнанной к POT размерам (например
> упихало оно в 125х290, значит показываем/экспортим 128х512).
Э. А мне вот не надо так. Как упаковало, так пусть и пишет...

#68
15:44, 16 авг. 2012

andrey.mesheryakov
Одна кнопка - POT enable решает все проблемы

#69
22:27, 16 авг. 2012

Zloten
> Выложил код -> нашли баги -> исправил -> выложил исправленный.
У меня нет постоянных ментейнеров под вин и мак - компиляют как придётся, причём за спасибо.
Zloten
> Вин7 - прозрачная картинка, не воспринимает рус. папки (? это што за ептитть!),
> экспортирует только .atlas файл (мучал полчаса так и не понял каким магическим
> образом экспортить пнг).
Это оказался вопиющий баг в Qt, скоро в гите появится патч. И приставка же: alpha, ваш кэп.
Zloten
> Heuristic - выбросить, должна происходить выборка внутри кода. Ну и ежу понятно
> что кроме TopLeft остольное ненужно.
> Sort - выбросить, должна происходить выборка внутри кода.
> RotataIf - ну млин выдумщик, ротировать если четные/нечетные дни забыл
> добавить. Опция должна быть одна - ротировать или нет. Соответственно если да
> то любые изображения с не равными краями будут вращаемы.
Если бы вы знали КАК сильно это влияет на результат (разумеется, мы не в игрушки играем - упаковывается over 9k текстур). Выкидывать не планирую, а автоматом выбирать - комп можно хорошенько подвесить. Да и ситуации бывают разные, эвристики помогают когда как. NP-полная задача, чтоб её...
Zloten
> Отсутствие возможности установить параметры для отдельного элемента (все
> врощаемы кроме мну / у мну бордер специфичный).
Есть такое. Планируется, но очень нескоро.
Zloten
> Border больше 1 фактически не нужен - соответственно  вкл/выкл а не выбор
> числа.
нужен для постпроцессинга (блур как пример)
Zloten
> Crop/Merge - сие не ясно для чего так как все прозрачное и не видать.
фича полезная
Zloten
> Где duplicate pixels on border? То есть вокруг квада на один пиксель повтор
> соседнего(принадлежащего картинке).
это в вашем DirectX такие жесткие баги, что нужны подобные костыли? DX фаны могут дописать - исходник открыт.
Zloten
> Где анализ pixel-data и нахождение совпадающих участков (по желанию - я не
> реализовывал данную фичу но делается на коленке за сутки).
Она есть.
Zloten
> Реализаций MaxRects в сети до крыши (адаптирование для своего фреймоврка от 1
> часа до суток).
> Привязка к GUI элементам (сутки от силы).
> Оптимизация алгоритма (ну пара суток от силы).
> Плюс доработка мелких багов как получиться.
> =максимум неделя. Хде работающий код в итоге?
А кто мне оплатит эту неделю? Сомневаюсь, что вам это понравится:) Программа написана за день, это опенсорс, извините, времени на "за спасибо" немного остаётся... Поверьте, с OpenSource лицензией вы аналога во всей сети не сыщите.
Я не против если вы будете использовать его в коммерческих проектах.
Zloten
> (в посте 34 на картинке как раз видать кучу пропавшего места).
Эмм? На картинке из 34 поста 6 текстур 512 на 512 и одна 256 на 256, в итоге 7 текстур. Процент свободного пространства - 2%. Просто там 7 отдельных текстур не очень удачно слеены.
Zloten
> Переборка вариантов должна быть ВНУТРИ кода, а пользователь должен видеть
> только один (самый лучший) результат. Как определить самый лучший: меньше
> площадь, больше занятость.
Посмотрю я как ваш i7 ляжет под двумя гигабайтами арта;)

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

#70
23:30, 16 авг. 2012

RPG
Давай во первых на ты, ты кодер я кодер, что мы тут раскланиваться будем :)
Во-вторых:

это в вашем DirectX такие жесткие баги, что нужны подобные костыли? DX фаны могут дописать - исходник открыт.

Когда я слышу DirectX я бью клавиатурой в зубы  :) + [] = :[.]
Как раз в OGL и востребовано.
Если бы вы знали КАК сильно это влияет на результат (разумеется, мы не в игрушки играем - упаковывается over 9k текстур). Выкидывать не планирую, а автоматом выбирать - комп можно хорошенько подвесить.

Что 9k в одну текстуру? А если в несколько то зачем... аха, догнал, я конечно не понимаю такого подхода, это значит энных тысяч текстур в одной папке и они все толпой пакуются в атласы, без тематики, без нихрена, оптить жесть. Как потом разбираться в этой каше. Глянул у тебя формат атласа, так в нем даже не определишь какая текстура куда попала, все цыферки, путь или имя надо, а так лишняя головная боль для юзера.
нужен для постпроцессинга (блур как пример)

А причем тут атлас? Хоть блур, хоть блум , хоть глоу - к атласу это никак не относиться. В атлас мы кладем текстуры или мы в нем блурим? Прошу разьяснений.
Эмм? На картинке из 34 поста 6 текстур 512 на 512 и одна 256 на 256, в итоге 7 текстур. Процент свободного пространства - 2%. Просто там 7 отдельных текстур не очень удачно слеены.

То есть атласы пихаем в атласы. Спорное решение. Но претензия отменяется.
Посмотрю я как ваш i7 ляжет под двумя гигабайтами арта;)

Опять таки не понял как он может лечь. Если два гига в одной папке то да - но для чего такое надо не пойму.  Прошу разьяснений.
Если бы вы знали КАК сильно это влияет на результат

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

Вывод: у нас с тобой немного разные подходы, опишу мой:
я пакер использую в движке для автомоатической сборки динамических атласов (атлас гуи, атлас эффектов, атлас шмота на персе, атлас террейна).
Простой пример: на данной карте растут 4 типа кустов и пять типов деревьев - мой пакер их пакует в атлас и каждый раз когда о дерево/куст взывают к своей текстуре он им подсовывает сябя :) При переходе на другую карту атлас перепаковывается автоматом для новой растительности.  Для батчинга милое дело и не требует возни с предупаковкой и систематизацией. Паковка быстра и эффективна, и расчитана на то чтобы получаемый атлас имел минимально возможный размер (по этому я и не засунул identic pixel area analysis в пакер, текстуры уникальны и похожих кусков в них нет да и лишнее сожраное время опять таки).
Вобчем вот хельп по классу:

+ Показать

Честно говоря наткнулся на твою тему и захотел проверить эффективность твоей паковки и моей. 

#71
23:50, 16 авг. 2012

Zloten
> То есть атласы пихаем в атласы. Спорное решение. Но претензия отменяется.
это всё дурацкое ограничение в 125 кб на картинку
Zloten
> А причем тут атлас? Хоть блур, хоть блум , хоть глоу - к атласу это никак не
> относиться. В атлас мы кладем текстуры или мы в нем блурим? Прошу разьяснений.
После того, как пакер находит границы изображений, к ним удобно применять постэффекты - блюр, distance field, это быстрее, нежели применять к каждой текстуре одновременно.
Zloten
> Опять таки не понял как он может лечь. Если два гига в одной папке то да - но
> для чего такое надо не пойму.  Прошу разьяснений.
Коротко - анимации. Ещё короче:
new_1 | [beta] Упаковщик атласов - Cheetah Texture Packer (auto-size ver.)
Исходник весил почти гигабайт:)
Zloten
> Простой пример: на данной карте растут 4 типа кустов и пять типов деревьев -
> мой пакер их пакует в атлас и каждый раз когда о дерево/куст взывают к своей
> текстуре он им подсовывает сябя :) При переходе на другую карту атлас
> перепаковывается автоматом для новой растительности.  Для батчинга милое дело и
> не требует возни с предупаковкой и систематизацией. Паковка быстра и
> эффективна, и расчитана на то чтобы получаемый атлас имел минимально возможный
> размер (по этому я и не засунул identic pixel area analysis в пакер, текстуры
> уникальны и похожих кусков в них нет да и лишнее сожраное время опять таки).
Этот пакер заточен на оффлайн упаковку анимаций, мелких объектов и прочей ерунды для 2D игр. Примеры в теме я уже выкладывал, наиболее наглядный - игра violetland, где очень много анимации и текстур с пустыми краями. В случае с кубиками: вся анимация рендерилась в мегавидео 2048 пикселей, затем пакер убрал все пустые края, но при этом положение кубиков на экране сохранилось - все смещения запечены в атласе и мне нужно будет просто нарисовать квад 10024 на 1024, не задумываясь о том, где должен находиться кубик в конкретный момент времени.
Zloten
> Результат должен быть один - самый лучший, и выбираться он должен программно а
> не юзером на глазок. Так и проще и быстрее.
Я не спорю, что эта фича нужна, но она будет отключаемой, как и возможность отображения графики в окна упаковщика (там есть спец. галочка, может у вас поэтому были сплошь прозрачные квадраты?:) Если текстур очень много, пакер отключает рендеринг графики для ускорения отрисовки. Так и здесь, когда текстур мало - можно бурутфорсить, если же их over 9000 - пусть юзер сам решает, хватит ли у него памяти на это или нет.
На данный момент перебор в пакере только в том, что он пытается уменьшить размер последнего атласа настолько, насколько это возможно, в итоге может получиться 5 атласов 1024 на 1024 и один последний 128 на 128.

Zloten
> Честно говоря наткнулся на твою тему и захотел проверить эффективность твоей
> паковки и моей. 
эффективность понятие растяжимое. В твоем случае эффективность - это насколько быстро будут уложены лайтмапы/карты теней/текстуры
В случае с 2D - насколько удобно запекать анимацию. Скажем, в игре с 20 спрайтами без атласов можно и обойтись, а вот когда их несколько тысяч и все разложены по папочкам в виде анимаций - вот тут без них никуда.

#72
0:07, 17 авг. 2012

RPG

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

Блур в атлас, хмм.. ладно оставим.

Вобчем разные у нас с тобой цели, подходы и реализации, хотя и родственные :)
Ладно когда win версия будет отбажена померемся чей алгоритм эффективней :)
Хотя если у тебя остался набор текстур из #30 поста могу заскринить свой резалт.

#73
0:15, 17 авг. 2012

Ну не блур так DF

Набор из игры монополия:
textures

Текущая версия пакера ужимает эти спрайты до 512*902, 466 кб в итоге:
classic.png.tar
Бордюра нет.

#74
0:24, 17 авг. 2012

Zloten
> Ладно когда win версия будет отбажена
Галочка "Показывать графику"

Страницы: 14 5 6 721 Следующая »
ПроектыФорумУтилиты

Тема в архиве.