Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Сделал мегатекстуры (3 стр)

Сделал мегатекстуры (3 стр)

Поделиться

Страницы: 1 2 3 4 5 6 Следующая

0xc0deПостоялецwww2 окт. 201714:32#30
0xc0de
> Джек Аллигатор

По поводу детализации мегатекстуры - более 13-и лодов из нее выжать не получится. В последнем лоде (№12) у тебя максимум может быть 4096х4096 тайлов. Для наиболее оптимальной работы с SVT старайся использовать максимум 9-10 лодов.

Джек АллигаторПостоялецwww2 окт. 201714:42#31
0xc0de
> Таблица переадресации из виртуальной текстуры в физический кеш будет одна.
А, вот оно что.
На самом деле можно хранить несколько таблиц, а куски от разных мегатекстур в одном кэше. Это ж чисто вопрос удобства реализации.
В любом случае интересная у тебя идея, взял на заметку.

0xc0de
> у тебя максимум может быть 4096х4096 тайлов
Ну зачем же так много.
Планирую для планеты мегатекстуру 65536х32768.
размер одного куска 512х512
размер текстуры переадресации 128х64
восемь мипов:
0  512
1  1024
2  2048
3  4096
4  8192
5  16384
6  32768
7  65536

Вопрос только в размере одного куска. Не слишком ли крупновато?

Если речь идет об этой части твоей статьи

Решить это ограничение можно используя дополнительный канал, в котором кодируются дополнительные восемь бит (по четыре на pageOffset.x и pageOffset.y). Таким образом, максимальное количество страниц, которые мы можем закодировать увеличивается до 4095 по x и столько же по y.

— не думаю, что ограничение 4096х4096 непреодолимое. Можно ведь текстуру переадресации хранить в другом формате, не обязательно юзать unsigned int.
У меня вот сейчас формат текстуры RGB32F, данные хранятся во float как есть. Просто так удобнее.

0xc0deПостоялецwww2 окт. 201714:49#32
Джек Аллигатор
> размер одного куска 512х512

Много. Долго будет закачиваться на видяху. В играх у id Software тайлы 128х128.

> — не думаю, что ограничение 4096х4096 непреодолимое. Можно ведь текстуру
> переадресации хранить в другом формате, не обязательно юзать unsigned int.

Слишком много памяти потребуется и скорость "пробега" по такому дереву будет очень медленной. Размеры текстуры переадресации так же будет больше 4096x4096, а ты учти, что для нее нужно хранить еще и лоды, а еще эту текстуру переадресации нужно будет обновлять на каждый чих. Сделать то можно, но будет не оправдано с точки зрения скорости алгоритмов и объему потребляемой памяти.

Джек АллигаторПостоялецwww2 окт. 201714:56#33
0xc0de
Понятно. До планеты далеко ещё, надо существующее до ума довести.
Позже отпишусь по этим вопросам, когда будет актуально.
FordPerfectПостоялецwww2 окт. 201718:18#34
Ranma
>А от собственной таблицы много не надо: имя файла, смещение от начала, размер,
Я о том, что PAK примерно так и выглядит. Ну, у PAK куча подвидов, да.
https://quakewiki.org/wiki/.pak
В Crimsonland весьма похожий формат.
RanmaПостоялецwww2 окт. 201720:42#35
nonamezerox
Не-не-не, Дэвид Блэйн! Раскукожь обратно! Нафиг такой оверхед, лучше я буду образ FAT-раздела монтировать - это быстрее выйдет, тем более если повезёт, то чтение пойдёт через ядро.

FordPerfect
Ну примерно как PAK я и имел в виду, просто не обязательно натягивать сову на глобус и принципиально брать PAK от id, мало ли, что вдруг понадобится, чего в этом формате нету, и что - терзаться муками буриданова осла между чистотой формата и реализацией потребностей? Тем более, что такую простую вещь написать руками дело на час-два.

Правка: 2 окт. 2017 20:45

BishopПостоялецwww3 окт. 20176:27#36
Ranma
> Надо запаковать все файлы в один большой файл собственного формата с
> виртуальной файловой таблицей, при старте таблицу прочитать, чтобы знать где
> что лежит, и держать файл открытым. Функции открытия отдельных файлов заменить
> на маппинг (memory-mapped files) по заданному смещению, чтение будет просто
> работой с памятью.
Вот так лучше не делать. Тут сразу несколько плохих советов :(

Ranma
> имя файла
ЗАЧЕМ?! Ну на кой хрен вам текстовое имя для тайлов то? Что за паталогическое желание скопировать POSIX-файловую систему...

Daniil Petrov
> Я вот хочу со временем подключить zlib для подобной канители.
Для текстур чтоли? Дык я тебя разочарую, их для мегатекстуры жмут не так.

Mr F
> вроде не самое быстрое, что есть. LZMA вроде быстрее.
Рука-лицо.....

Daniil Petrov
> решение ID Software
Только для мегатекстуры. Там хотябы по уму выбраны алгоритмы.

0xc0de
> Один для дифуза, другой для нормалий, и т.д.
Нет. Тайл хранит в себе сразу всё. До тех пор пока это не в видеопамяти тайл это сразу все каналы.

0xc0de
> Для мегатекстуры не нужно.
Да нужно и ещё как. Просто не то, что они выбирают.

BishopПостоялецwww3 окт. 20176:29#37
0xc0de
> По поводу детализации мегатекстуры - более 13-и лодов из нее выжать не получится.
Это ещё почему. Технически можно, только смысла делать больше чем 64к х 64к я не вижу. Самих текстур может быть и больше, но единую делать из них смысла 0.

> В последнем лоде (№12) у тебя максимум может быть 4096х4096 тайлов.
Хм... А вы точно знаете другие способы адресации мегатекстуры кроме прямого через ещё одну текстуру?

Daniil PetrovПостоялецwww3 окт. 20176:43#38
Mr F
> я сам сувал тайлы в зип и открывал через это:
А пароль на файлы ставить можно? Чтоб интеллектуальную собственность не растаскивали :)))
0xc0deПостоялецwww3 окт. 20178:42#39
Bishop
> Нет. Тайл хранит в себе сразу всё. До тех пор пока это не в видеопамяти тайл
> это сразу все каналы.

Где противоречие с тем, что я сказал? Там речь шла о физическом кеше, а физический кеш находится в видеопамяти.

Bishop
> Да нужно и ещё как. Просто не то, что они выбирают.

Там советовали Zlib для мегатекстуры. Ты сам в другом предложении себе противоречишь, где говоришь, что мегатекстуры жмут не так.

0xc0deПостоялецwww3 окт. 20178:46#40
Bishop
> 0xc0de
> > По поводу детализации мегатекстуры - более 13-и лодов из нее выжать не
> > получится.
> Это ещё почему. Технически можно

Технически не оправдано, я об этом писал выше.

> > В последнем лоде (№12) у тебя максимум может быть 4096х4096 тайлов.
> Хм... А вы точно знаете другие способы адресации мегатекстуры кроме прямого
> через ещё одну текстуру?

Для мегатекстуры других не знаю.

RanmaПостоялецwww3 окт. 20179:21#41
Bishop
> Вот так лучше не делать. Тут сразу несколько плохих советов :(
Можно поподробнее?

Кстати, насчёт имени файла - это была общая идея, тайлы конечно можно держать и с индексами наподобие потоков основного файла (опять как в файловой системе). Но ведь как-то надо обращаться к ресурсам, особенно в процессе создания сцен задолго до релиза (это когда релиз - тогда можно даже обфускацией заниматься). Короче - от копирования идей файловой системы никуда не деться. Потому что в принципе нужно каким-то образом размещать ресурсы, ссылаться на них из других ресурсов, находить в рантайме, открывать найденное и читать. Делать всё-всё-всё числовыми индексами? А потом сходить с ума пытаясь вспомнить какое число от чего?

Джек АллигаторПостоялецwww5 окт. 20171:35#42
Panzerschrek[CN]
> > Заметил пока только трудности с фильтрацией
> Надо добавлять границу к тайлам шириной в несколько пикселей, тогда такой
> проблемы не будет.
0xc0de
> Для каждого тайла генерят бордеры во время построения SVT.
Сделал фильтрацию без изменения тайлов, без всяких границ, штатными средствами OpenGL. К тому же, код существенно упростился в определенных местах.
Изображение
0xc0deПостоялецwww5 окт. 20171:48#43
Джек Аллигатор
> Сделал фильтрацию без изменения тайлов, без всяких границ, штатными средствами
> OpenGL. К тому же, код существенно упростился в определенных местах.

Круто :) Но в пейперах от id говорилось, что рассчитывать фильтрацию в реалтайме в шейдерах достаточно тормозно. У тебя кстати какая фильтрация, билинейная, трилинейная, с анизотропией?

Джек АллигаторПостоялецwww5 окт. 20172:02#44
0xc0de
> Но в пейперах от id говорилось, что рассчитывать фильтрацию в реалтайме в
> шейдерах достаточно тормозно.
А я и не рассчитываю.

> У тебя кстати какая фильтрация, билинейная, трилинейная, с анизотропией?
Какая хошь.

Секрет прост:

gl::TexParameteri(gl::TEXTURE_2D_ARRAY, gl::TEXTURE_MIN_FILTER, gl::LINEAR as i32);
gl::TexParameteri(gl::TEXTURE_2D_ARRAY, gl::TEXTURE_MAG_FILTER, gl::LINEAR as i32);
Долго думал как Кармак фильтровал тайлы с границами, как эти тайлы нарезать правильно...
Лень было всё это проворачивать, решил пойти по пути наименьшего сопротивления. Почему-то никто не пишет об использовании GL_TEXTURE_2D_ARRAY в качестве кэша.
А из него тайлы рендерятся правильно, без захвата соседних пикселей.

Код шейдера упростился до такого:

+ Показать

Результат меня устраивает, большего и не нужно. Видны границы смены детализации, но они и у Кармака видны в Rage.

+ Показать

Единственное ограничение - в кэше не может быть больше 2048 тайлов. Ну это на моём железе, на новых гпу в несколько раз больше можно.
К слову, 16К кэш-текстура может вмещать от 1024 512x512 до 65536 64х64 тайлов.

Правка: 5 окт. 2017 2:04

Страницы: 1 2 3 4 5 6 Следующая

/ Форум / Программирование игр / Графика

Тема закрыта.

2001—2017 © GameDev.ru — Разработка игр