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

Дублирование арта и Атласы (3 стр)

Страницы: 1 2 3 4 Следующая »
#30
12:27, 6 ноя 2015

Aroch
к чему эти выкладки?)
да и не правильные

1024 длиться на 4 значит +4 +4 = 1032
768 делиться на 4 значит +4 +4 = 776

для 500 на 500 - 508 на 508

#31
12:32, 6 ноя 2015

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

#32
12:38, 6 ноя 2015

Aroch
случай с 1024 не нужно, я не знаю размер атласа.
А вот если он попадает на край, тогда мы "отрезаем" у него блок 4х4
так же если и справа, снизу сверху. отсюда и 2 раза

у нас 4 стороны

#33
12:47, 6 ноя 2015

IROV..
да хоть 10 сторон, у тебя есть элемент с размерами AxB после бордюра в 1 пиксель размер будет (A+2) x (B+2) чтобы не иметь проблем с dxt тебе нужно довести размер элемента кратному 4, итоговый размер ( ((A+2)%4 > 0) ? (A+2)+(4-(A+2)%4) : A+2 ) x ( ((B+2)%4 > 0) ? (B+2)+(4-(B+2)%4) : B+2 )
Еще раз у тебя уже есть элемент с бордюром, нахрена тебе делать кратность 4 с каждой стороны? Когда тебе нужно чтобы сам элемент был кратен 4.

#34
12:54, 6 ноя 2015

Aroch
ты не прав. Мне нужна возможность его отсекать
+1 +1 тут вообще не нужно
у меня есть 1024х1024 я хочу его закинуть в атлас 1024х1024 или в 2048 на 2048

в случае с атласом 1024х1024 мне нужно отрезать "ушки" в пнг я могу отрезать ушки по 1 пикселю, а в DXT только по 4

#35
13:06, 6 ноя 2015

IROV..
что значит отсекать, что такое "ушки"?

Всё я понял о чем ты, ты хочешь опционально убирать бордюр с одной из сторон если он не нужен.

Проще делать бордюр по надобности в рантайме и переводить в dxt1 весь атлас тоже в рантайме http://www.nvidia.com/object/real-time-ycocg-dxt-compression.html

#36
14:08, 6 ноя 2015

Aroch
Реалтайм? ну если 5-10 минут, по сравнению с 12 часами это реалтайм то я с тобой соглашусь. Но согласиться ли со мной пользователь?

З.Ы. да и качество картинки там хуже, лучше чем обычный фаст, но хуже чем "долгий"

#37
15:46, 6 ноя 2015

IROV..
> З.Ы. да и качество картинки там хуже, лучше чем обычный фаст, но хуже чем
> "долгий"
зато за секунду овер полгига пикселей жмет. Можно использовать как драфт вариант и в отдельном потоке с низким приоритетом сжимать вариантом с лучшим качеством, потом один раз закэшировать на диске и всё.

#38
16:17, 6 ноя 2015

Aroch
можно, не проще ли тогда вернуться к ушкам))

#39
17:00, 6 ноя 2015

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

#40
18:02, 6 ноя 2015

Aroch
ну да это тоже один из поинтов оптимизации, ибо для небольших картинок +8 пикселей это не хухры-мухры)

#41
13:47, 8 ноя 2015

Обожди - сжимать или пересжимать текстуру на лету, в том числе на современных CPU и даже GPU - не проблема. Прости госпади, на javascript в основном потоке делаем.
Да и бордюры при условии ручного формирования mipmap и пиксельных шейдеров тоже не нужны - тут главное минимальный мип ограничить.

#42
13:56, 8 ноя 2015

Kashey
crunch вон вообще текстуру жмет, колдует я бы сказал минут 5 над каждой :)
а то что в обычном качестве оно быстро это факт.
мипмапа нету, есть фильтрация при ресайзе

#43
15:23, 8 ноя 2015

Там алгоритм выбора опорного вектора очень упорный. При этом в 95% случаях ты разницы от обычного min-Max глазом не заметишь.
А фильтрацию при ресайзе еще 10 лет назад лечили добавлением clamp и bias на шейдере.

#44
16:12, 8 ноя 2015

Kashey
А если нету шейдера? :)

Да и зачем мучать шейдер если хватает, добавить пиксель

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

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