Как упаковать текстуры в libGDX?

Question

[Андрей Скляров]

Я пишу игру под Android на libGDX и использую TexturePacker (https://www.codeandweb.com/texturepacker) для создания атласов. Графики становится довольно много, поэтому возник вопрос как упаковать текстуры в менее ресурсозатратный формат чем PNG/RGBA4444 (который я использую сейчас).

Погуглив, я понимаю что мне нужен ETC1. TexturePacker умеет экспортировать в "PKM with ETC1" - это как раз то что нужно. Если такой файл заархивировать и переименовать в etc1, то libGDX его прочтет. НО. Сам формат, подразумевает что изображения сохраняются в один etc-файл без альфа-канала, а альфа-канал сохраняется в другой etc-файл. Как объединить эти 2 атласа в libGDX - я не представляю!

В gdx-tools (https://libgdx.badlogicgames.com/tools.html) есть собственный TexturePacker, но он, как я понял из документации, экспортирует только в PNG. Так же есть некий KTXProcessor, но ни где взять бинарник, ни как им создавать атласы - мне не понятно.

Итого, как же вы упаковываете текстуры в libGDX? Есть какое-то руководство "для чайников"?

Answer 1

[maaGames]

Объединять в шейдере. Без шейдера не знаю, можно ли сделать.

Comments

[Андрей Скляров]

Не работал раньше с шейдерами... Почитал. Вроде бы, в теории все понятно. Мне нужно во фрагментный шейдер передавать еще одну текстуру (загруженную из ETC1-атласа со значениями альфы). Сделать это можно через shader.setUniformi. И в самом шейдере устанавливать значения альфы для gl_FragColor рассчитывая их из этой текстуры.

Но как это сделать на практике? У меня все построено на Stage и Actor. Я должен дописать установку ShaderProgram в каждый Actor? Я уже сделал свое расширение для Actor, чтобы рисовать текстуры, добавить сюда еще один параметр (текстуру с альфа-каналом)?

public class SimpleActor extends Actor {

private final TextureRegion region;

public SimpleActor(TextureRegion region) {
this.region = region;
}

@Override
public void draw(Batch batch, float parentAlpha) {
batch.draw(region, getX(), getY(), getOriginX(), getOriginY(), getWidth(), getHeight(), getScaleX(), getScaleY(), getRotation());
}

}

[maaGames]

Андрей Скляров: Передавать в шейдер две RGB текстуры, из второй текстуры брать только r канал и записывать его в альфу, да. В g и b можно какую-то другую дополнительную информацию писать или альфа-каналы для других текстур.

[Андрей Скляров]

maaGames: А как альфу установить в шейдере?
Переделал вот так, не работает :(

public SimpleActor(TextureRegion region, TextureRegion alphaRegion) {
this.alphaRegion = alphaRegion;
this.region = region;

setSize(region.getRegionWidth(), region.getRegionHeight());
setBounds(0, 0, getWidth(), getHeight());

shader = new ShaderProgram(
Gdx.files.internal("shader/default.vert").readString(),
Gdx.files.internal("shader/default.frag").readString());

if (shader.getLog().length() > 0) {
Gdx.app.log("Shader loading:", shader.getLog());
}

shader.begin();

alphaRegion.getTexture().bind(1);
shader.setUniformi("u_alpha", 1);
region.getTexture().bind(0);
shader.setUniformi("u_texture", 0);

shader.end();
}

@Override
public void draw(Batch batch, float parentAlpha) {
batch.setShader(shader);
batch.draw(region, getX(), getY(), getOriginX(), getOriginY(), getWidth(), getHeight(), getScaleX(), getScaleY(), getRotation());
}

И сам шейдер:

#ifdef GL_ES
precision mediump float;
#endif

varying vec4 v_color;
varying vec2 v_texCoords;
uniform sampler2D u_texture;
uniform sampler2D u_alpha;

void main() {
float alpha = texture2D(u_alpha, v_texCoords).r;
gl_FragColor = v_color * texture2D(u_texture, v_texCoords);
gl_FragColor.a = alpha;
}

[maaGames]

Андрей Скляров: Не силён в шейдерах, но выглядит правдоподобно. Сами шейдеры точно нашлись и загрузились? Перед использованием шейдера сделан его bind? (возможно, он делается в setShader, не проверял).

[maaGames]

Андрей Скляров: Скорее всего shader.begin()/end() должны вызываться при отрисовке.

[Андрей Скляров]

maaGames: Шейдеры находятся/загружаются без ошибок, перенес в отрисовку - не помогло. Мне кажется, с самим шейдером что-то не так... Если "gl_FragColor.a = alpha;" убрать, то спрайты черными квадратами, по крайней мере, отрисовываются.

[maaGames]

Андрей Скляров: попробуй местами текстуры поменять

alphaRegion.getTexture().bind(1);
shader.setUniformi("u_texture", 1);

region.getTexture().bind(0);
shader.setUniformi("u_alpha", 0);

[Андрей Скляров]

maaGames: Неа, не помогает. А может libGDX ETC не читает, который экспортирует TexturePacker (я ни одного примера не нашел). По идее, у меня должны были получится хотя бы спрайты без прозрачности.

[maaGames]

Андрей Скляров: etc1 поддерживает, я использовал. Только не помню, какой программой кодировал... Можешь png-24bit временно использовать, если в кодировщике не уверен.
Раз даже с одной текстурой не работает, то явно ошибка или в инициализации шейдера или в самом шейдере... Но помимо того, что шейдер не инициализирован перед использованием я ничего подсказать не могу, никогда напрямую шейдеры не использовал.

Answer 2

[Евгений Шатунов]

Андрей, у тебя вопрос, как видно по тексту, немного о другом. По описанию видно что ты перед собой стену видишь, а про дверь в стене даже не подозреваешь. Итак, вот дверь, даже несколько. :)

Первое - надо понять, насколько много графики у тебя в проекте. Для современного mid-end устройства на андроиде 5.0 совсем не проблема держать 2-4 RGBA текстуры с разрешением 4096 по ребру. Это не говоря о сопутствующих шейдерах, буферах растра/глубины/вершин/индексов. Минимализм в ресурсах приветствуется, но и зажимать себя в тески не стоит.

Второе - давай взглянем на параграф "Open GL Version" странички https://developer.android.com/about/dashboards/ind...
OpenGL 3.x занимает большую долю всех устройств. Эта версия OpenGL умеет работать с форматом ETC2 (благодаря заявленной поддержке от GPU), в котором уже можно сохранять альфу. А в вики ( https://en.wikipedia.org/wiki/Ericsson_Texture_Com... ) еще и написано про обратную совместимость.
Тут в моем опыте пробел, с ETC2 я еще не работал и наглядно про обратную совместимость с ETC1 ничего не знаю. Поэтому предлагаю устроить обмен знаниями в этой теме. :)

Третье - Аппаратно-поддерживаемых форматов сжатия текстур на самом деле много: S3TC, ATC, PVR-TC. ETC - не единственный. Каждый из форматов поддерживается своим производителем. ATC - Quallcomm; PVR-TC - Imagination Tec. Но вот S3TC (более известный как DXT3/DXT5) поддерживается обоими QC и ImgTec, но тайно. И только ARM Mali поддерживает один лишь формат ETC.
К чему я это. Тройка профильных форматов и альфу поддерживает, и обрабатывается быстрее того же ETC (и уж тем боле пары ETC1).
Поэтому может тебе удобнее будет использовать конвертацию в эту тройку форматов?
У меня на гитхабе есть очень быстрая библиотека для программного чтения PVR-TC.v2 в RGBA буфер, что позволит загрузить текстуры для Mali GPU.

Comments

[Андрей Скляров]

Возможно, я действительно раньше времени создаю сам себе проблему. У меня сейчас, грубо говоря, 4 атласа 2048х2048. То есть, количество контента еще можно увеличить в 4 раза, правильно я понимаю? Просто специфика игра такая, что чем больше контента, тем лучше. Процент реюзинга арта - мал.

Про существование других форматов сжатия - я знаю, да. Тут вопрос больше в том, что поддерживает движок. К тому же (могу ошибаться), ETC1 - самый "безопасный" вариант для Android. В плане того, что будет работать на абсолютном большинстве устройств. Я вот вижу, что у OpenGL 3.x - 42.3%, это ж половину девайсов надо выкинуть из списка поддерживаемых? ИМХО, время 3 версии еще не пришло.

Есть у меня еще одна идея, которую я берегу напоследок. Можно сделать как в больших играх: загрузку-выгрузку арта по необходимости, частями. Конечно, усложняет код и разбавляет плавную игру догрузками, но как вариант.

[Евгений Шатунов]

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

А вот устройств с поддержкой OpenGL 3.x не 42.3%, а 42.3 + 12.8 = 55.1% :) Остальная часть с поддержкой OpenGL 2.0 - это обычно старье с Adreno 200/205, SGX500+ или 1-4 ядерными Mali 400MP. Лично я под вопрос ставлю их практическую ценность и восприятие в качестве целевой аудитории.

Движок поддерживает все что поддерживает его окружение и операционка. Движку неважен формат текстуры если он(движок), конеч, не порывается читать ее в обход окружения.
А "самым безопасным" в этом отношении, на самом деле, может быть только TGA. :) Т.к. этот формат на 100% точно передаст качество текстуры и на 100% точно прочитается даже своими руками. ETC - такой же аппаратно-поддерживаемый формат сжатия текстур и он тоже может не поддерживаться какой-нибудь экзотикой из Китая. Шанс есть всегда.
В манифесте можно указать и требуемую версию OpenGL, и поддерживаемые текстуры. Таким образом можно сделать и несколько .APK файлов для разных GPU, которые будут полностью безопасными.

[Андрей Скляров]

Евгений Шатунов: Евгений, так у меня и есть поделка на коленке! :) Понятно, что можно дописать все что угодно к движку, тем более он опенсорс. Вопрос только времени и усилий. Шейдеры ведь тоже норм. вариант, можно было бы сделать, будь у меня хоть какой-то опыт с OpenGL. Нам, инди, нужно решать задачу максимально простым способом, в условии ограниченного ресурса :) Вот тут https://github.com/libgdx/libgdx/wiki/Texture-Comp... написано, что libGDX поддерживает ETC1 и KTX.