Войти
ПрограммированиеФорумГрафика

Кто-нибудь делал автосборку атласов на лету? (3 стр)

Страницы: 1 2 3 4 5 6 Следующая »
#30
17:53, 8 мая 2022

Huldra
> Все это имеет смысл на Pi 1-3 (OpenGL ES 2.0) и на Pi 4 (OpenGL ES 3.0)
На ES3 массивы есть

#31
18:38, 8 мая 2022

MrShoor
> На ES3 массивы есть
Я пока хочу продолжать поддерживать хотя бы Pi 3, там ES2

#32
23:10, 8 мая 2022

Huldra
> Я пока хочу продолжать поддерживать хотя бы Pi 3, там ES2
Ты уверена что оно тебе надо? Просто между es2 и es3 большая разница в аппаратных фичах. И это будут постоянные ограничения из-за поддержки es2. А es2 между тем всё реже и реже встречается, и почти вымер уже

#33
23:38, 8 мая 2022

Huldra
> Я вообще не игру делаю, а движок, так что я в design time точно ничего не могу
> скомпоновать, я даже не знаю какую игру будут делать разработчики на моем
> движке

Вангую с довольно высокой вероятностью, кто будет делать игру на твоём движке. Никто.

#34
1:08, 9 мая 2022

bool
> кто будет делать игру на твоём движке. Никто.

Это да. При том, что есть допустим опенсорсный Godot, с ЕS2/ES3, билдами на Pi.
И кстати со своими атласами и коммюнити.

#35
1:46, 9 мая 2022

bool
> Вангую с довольно высокой вероятностью, кто будет делать игру на твоём движке.
> Никто.
А вот и не угадал, на моем движке уже сделано несколько игр

#36
1:54, 9 мая 2022

MrShoor
> И это будут постоянные ограничения из-за поддержки es2. А es2 между тем всё
> реже и реже встречается, и почти вымер уже
Пока новые Pi3 все еще производят и продают, я буду их поддерживать. И потом еще пару лет.

#37
15:12, 9 мая 2022

Ну я делал. Единственная сложность (которую упорно замалчивают), это то, что размер атласа предполагается задавать вручную.
И никакого метода для его автоматического определения не предполагается. Математически вычислить размер атласа едва ли возможно.
Я поначалу пробовал сложить все длины и ширины кусочков, а потом извлечь из каждой квадратный корень и выбрать большее значение как размер стороны квадрата, но и это тоже не слишком надёжно.
Остановился на варианте тупого перебора. Принимаем начальный размер атласа как размер самого большого куска, а шаги на увеличение его размера - как размеры самого маленького куска. И в цикле по очереди увеличиваем сперва длину, потом ширину и так - пока всё не влезет.
Конечно если кусков сильно много - это будет медленно.

#38
16:00, 9 мая 2022

g-cont
> И никакого метода для его автоматического определения не предполагается.
> Математически вычислить размер атласа едва ли возможно.
если текстурки по размерам +/- однородны, то вполне. Считай общую площадь и считай подходящий размер  большей площади с каким то запасом. Да и если не вместится какая-то текстурка, всегда есть варианты: 1) в след. атлас. 2) пересобрать с большим размером.

#39
16:21, 9 мая 2022

g-cont
> И никакого метода для его автоматического определения не предполагается.
8192х8192 - не влезло в следующий.

#40
16:21, 9 мая 2022

g-cont
> Ну я делал. Единственная сложность (которую упорно замалчивают), это то, что
> размер атласа предполагается задавать вручную.
> И никакого метода для его автоматического определения не предполагается.
Потомучто оно нафиг ненужно. Просто делаешь TEXTUE_ARRAY размера 1024*1024*n и всё. Главная сложность это уместить компактно множество спрайтов самой различной формы. Алгоритм за O(N*N) то известен, но такая сложность в рантайме не прокатит.

#41
20:59, 9 мая 2022

>>если текстурки по размерам +/- однородны, то вполне
Если бы они были однородны, тогда бы и упаковщик не понадобился. Для моноширинного шрифта, он к примеру не нужен.

#42
21:56, 9 мая 2022

Атласы в реал-тайм гибче и пайплайн подготовки упрощается. Шрифты - самый базовый пример.
Смысла подготавливать заранее в современных реалиях немного, к тому же для предрасчитанного атласа нужно дополнительное место на диске.

Алгоритм получения атласа достаточно прост. Сортируем картинки по размеру, далее расставляем. Когда в один атлас не влазит, добавляем в следующей. Более сложная упаковка это для упоротых и маньяков), она не сильно уплотнит.

Еще нужно отступы между картинками, чтобы мипы не смешивались.

#43
22:37, 9 мая 2022

betauser

> она не сильно уплотнит
Сортировка тоже даёт довольно мало.

#44
(Правка: 23:00) 22:56, 9 мая 2022

Сортировка кстати неплохо уплотняет, если сортировать правильно.
У меня наилучшие результаты получались вот с такой формулой:

diff = (piece2.width * piece2.height) - (piece1.width * piece1.height);

Смысл в том, что самые большие кусочки должны добавляться в первую очередь.
В принципе добавление сквозь все страницы уплотняет еще лучше, но это еще дольше :)

Страницы: 1 2 3 4 5 6 Следующая »
ПрограммированиеФорумГрафика