Войти
ПрограммированиеФорум2D графика и изометрия

Импорт спрайтов, упакованных в одно изображение

#0
19:42, 4 сен. 2020

  Привет! Столкнулся с такой проблемой. Допустим у нас есть изображение, состоящее из разных спрайтов, например, покадровая анимация героя. Как при импорте определять границы самих спрайтов. Дать возможность дополнительно грузить вершины каждого спрайта в obj.? Либо пользователь сам выделяет кадры поконтурно? Или может быть если упакованные спрайты одинакового размера, то просто задавать количество нарезки изображения по ширине и высоте, а спец алгоритм уже сам будет вырезать нужные кадры? 


#1
19:50, 4 сен. 2020

ArtProg
в чём вопрос? Ты не знаешь как это программно реализовать, или тебе нужна утилита?

#2
20:13, 4 сен. 2020

  Нужно понять принцип. На основании чего например изображение можно считать анимацией как например тут. И как тогда понять какие кадры за какими идут. Скажем, если взять пример выше, то как определить, что в какой-то момент нужно отобразить первый кадр, находящийся по таким-то координатам, а потом второй, и т. д. Где брать эту информацию? В изображение типа png или bmp ее же не засунешь.

#3
21:02, 4 сен. 2020

ArtProg
> И как тогда понять какие кадры за какими идут
указывается артистом, порядок последовательности это лишь малая часть необходимая для полноценной анимации.
> В изображение типа png или bmp ее же не засунешь.
при желании можно, но так никто не делает. Всю необходимую информацию можно сохранить отдельно. Либо придумать/взять формат подходящий для этого.

#4
21:03, 4 сен. 2020

ArtProg
в инструментах для импорта спрайтов обычно есть такие настройки как "размер спрайта X/Y", "оффсет X/Y". т.е. да, они будут одинакового размера.

В старых играх (знаю про M&M6-8 т.к. ковырял), бывало что для оптимизации срезали прозначные края спрайтов, делая кадры разными по размеру и отдельно в даташитах хранили координаты/оффсеты всех кадров (предполагаю, это делалось не руками).

имхо, таким маяться сейчас уже не стоит.

#5
14:41, 5 сен. 2020

На входе кадры одинакового размера.
Загонятор в атлас обрезает пустые края, и генерит сопровождающий файл с описанием, где какой кадр, и где у него якорь.
Файл(ы) в формате, удобном для используемого движка.

Можно вообще делать кадры не прямоугольниками, а бить на треугольники, и паковать в атлас ещё плотнее (например,

+ Показать
).

#6
16:48, 5 сен. 2020

krian
> Можно вообще делать кадры не прямоугольниками, а бить на треугольники, и
> паковать в атлас ещё плотнее
нужно, если заботиться о филрейте. Но на твоем скрине похоже на работу руками.

#7
17:38, 5 сен. 2020

krian
> Можно вообще делать кадры не прямоугольниками, а бить на треугольники, и
> паковать в атлас ещё плотнее (например,
Неужели в наше время стоит так заморачиваться? Дает ли это измеримый выигрышь в чем-то?

#8
10:49, 6 сен. 2020

kkolyan
> Неужели в наше время стоит так заморачиваться? Дает ли это измеримый выигрышь в чем-то?
Треугольнички может и перебор ) А пустые поля пообрезать вполне себе гигиенично.
Бывают старые ноуты и мобилки. Ну и игры разные бывают, взять вон айдракулу, https://gamedev.ru/projects/forum/?id=230866. Или, не знаю, как там в капхеде.
Это больше не про филрейт, а про вменяемое количество одновременно нужных текстур и объёмы памяти, которые они занимают. Опять же, разрешения растут.

#9
17:02, 6 сен. 2020

kkolyan

Неужели в наше время стоит так заморачиваться? Дает ли это измеримый выигрышь в чем-то?

  Если, например, сжать текстуру плотнейшим образом, каким нибудь RLE, то в принципе нет(как это реализовано у меня), так как читаются только видимые пиксели на полупрозрачном изображении, но будет некоторый гемор с трансформациями(поворот, масштабирование) для такого изображения.
  В общем, для себя решил каждый кадр хранить в отдельном массиве. Поступает допустим на вход атлас, и дальше прога уже обрезает каждый спрайт и пакует в отдельные сжатые изображения, по идее для производительности должно быть хорошо, так как кэш-френдли для маленьких спрайтов. Еще и преимущество в том, что на входе атлас может быть вообще безразмерный(итоговые изображения будут содержать только видимые пиксели). Хотя нужно еще провести массу тестов. Потом, если что выложу результаты.
#10
16:26, 7 сен. 2020

kkolyan
> Неужели в наше время стоит так заморачиваться? Дает ли это измеримый выигрышь в
> чем-то?
Есть отличный пример по портированию Night in the Woods на планшеты. Чтобы влезть по памяти чувак там спрайты нарезал на квадратные блоки и искал совпадения с уже существующими блоками. Это позволяло повторно использовать куски изображений и экономно использовать видеопамять.

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

Смотреть где то с 30ой минуты.
#11
14:52, 8 сен. 2020

kkolyan
> Неужели в наше время стоит так заморачиваться? Дает ли это измеримый выигрышь в
> чем-то?
Бывает иногда дизайнеры выдают анимацию, которая чуть-чуть не помещается в атлас со степенью двойки. Например, один кадр не помещается в атлас 1024x1024 и генератор выдает атлас размером 2048x1024. Поэтому приходится так извращаться. И надо помнить, что у iPhone 11 всего 4Gb ОЗУ, много спрайтовой графики не поместится.

ПрограммированиеФорум2D графика и изометрия

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