Здравствуйте, в учебных целях (диплом), пишу свой "движок" на OpenGL. Дошел до текстур. Хотел бы узнать у знающих людей, стоит ли создавать атлас текстур и преобразовывать его в TBO, чтобы увеличить скорость? Стоит ли так изворачиваться, или овчинка выделки не стоит? Я понимаю что это всего лишь диплом, но я бы хотел написать все же, может даже меньше, но чтобы в итоге получился более-менее работоспособный коцепт.
Ну смотри.
Во первых зачем тебе TBO, захотелось секаса с мипмапами?) Да и они более тяжелые.
Во вторых, атлас имеет смысл если текстуры очень мелкие и их очень много, т.е. скорость увеличиться чисто за счет меньшего числа IO операций. Проще загрузить 1 раз файл побольше чем загрузить 100 мелких файлов. В наше время честно говоря не вижу особого смысла заморачиваться с атласами, кроме ситуаций когда каждая текстура размером меньше 64 пикселей.
Подгляди реализацию текстур\атласов и "текстурных регионов" в libgdx. Весьма просто и удобно сделано. Хочешь просто текстуру, хочешь из этой текстуры возьми регион(в общем и целом те самые атласы), есть и реальная реализации атласов.
Спасибо, но можно еще пару вопросов? Просто мипмапы насколько мне известно автоматически генерируются OpenGL, и особой морки ведь не должно быть? По поводу IO, это ведь основное "горлышко" в графике, разве нет?
Airat1995: TBO если проще говорить это линейный буфер с не совсем известными данными(внутри может быть 1D\2D\3D\Cube и т.д.), никаких мипмапов или фильтраций нет, только хардкор. Мипмапы автоматически не генерируются, на этот счет от версии к версии opengl было и есть куча разных методов для генерации оных.
С IO надо исходить из задачи. Раньше когда видеопамяти и озу было не так много то часто хитрили и на лету грузили и выгружали ресурсы. Сейчас эта проблема остро не стоит, памяти везде много и она очень быстрая. Исключением может быть игра с бесшовным миром и огромным числом текстур. Если исключить такие миры то текстуры грузят не в реальном времени на лету а вначале при загрузке уровня загружают абсолютно все что понадобится для уровня(обычно называют прекэшем), по времени это опять же становится не критичным т.к. пока грузятся ресурсы игроку обычно показывают экран загрузки с нескучными картинками.
Намного больше времени,как правило, уходит на разработку алгоритма грамотного прекэша. Решают или в лоб путем статичного списка прекэша который точно не меняется на протяжении игры(текстура героя\оружия... в общем все то что на протяжении всей игры не меняется и будет почти на каждом уровне) и данимаческий список(текстуры присущие конкретному уровню, составляется обычно отдельной утилитой которая делает файлик со списком всех текстур на уровне). Динамический список при каждой смене\загрузки уровня сначала вычищается а потом на его место грузится новый. Такой подход в движке сорса и вообще почти в каждом.
Бывает что идут немного интереснее и эти списки составлют динамически на лету и также динамически асинхронно по этому списку все грузят и выгружают. Чтобы сделать этот процесс незаметным идут хитрым путем. Делают свой "велосипед" формат текстур в котором запекают мипмапы, располагают их в начале файла самый мелкий а в конце самые большие т.е. текстура в оригинальном разрешении. При необходиомсти загрузки асинхронно быстро грузится начало текстуры и сразу накладывается на объект(он получается мыльный) и по мере загрузки файла подменяют мипмапу на более качественную. Такой подход тоже много где используется, живой пример был и остается двиг UE3. В нем на компьюерах с малым количеством памяти\медленной памятью или медленным хардом можно наблюдать в реальном времени за этой загрузкой. Карта грузится очень быстро, затем включается рендер мира и все мыльное мыльное и в течении секунд на глазах все обрастает деталями, стоит поднять новое оружие как оно несколько секунд мыльное и вдруг резко становится красивым. У этого подхода к плюсам можно отнести более быструю загрузку, возможность делать огромные и бесшовные миры, возможность загружать огромные текстуры но все это прекрасно и красиво на очень мощных ПК или на более слабых с условием что игра не шибко динамичная а размеренно плавно медленная.
Дмитрий Александров: ну то что TBO это одномерный массив я знаю. А вот про прекэш я не знал, часто вижу такое когда играю в Paragon на PS4, и не знал как это называется. Можете статей пожалуйста подкинуть на эту тему?
На счет мипмапов, я читаю красную книгу по OpenGL для версии 4.3, и там говорится про автоматическую генерацию мипмапов, если в более ранних версиях нужно создавать мипмапы вручную, то как это лучше сделать? Да и вообще есть ли в них смысл, если я не смогу сделать динамический LOD на шейдере в OpenGL 4.1?
Airat1995: Precach\Preload каждый реализует сам в конкретном движке со своими хитростями, нет универсального способа или особых финтов в opengl на тот счет. В целом как я и выше писал, либо грузите все необходимое заранее до геймплея, либо грузите все в реальном времени и изобретаете велосипеды чтобы это было незаметно либо комбинируете оба способа.
По поводу мипмапов https://www.khronos.org/registry/OpenGL-Refpages/g...
Без LOD смысла нет, но лоды обязательно надо делать.
Дмитрий Александров: по поводу мипмапов я про эту функцию и говорил и он позволяет использовать TEXTURE_1D, и в теории можно его использовать для создания мипмапов для TBO. А по поводу LOD, шейдер тесселяции все же доступен в версии 4.1, на который я пока что ориентируюсь. И уже в нем получается писать в вершинный шейдер или в фрагментный шейдер (как это сделано тут: https://habrahabr.ru/company/ua-hosting/blog/271931/ место про пиксели и диффузную карту).
Дмитрий Александров: ну просто мои ограничиваются красной книгой, а там техник рендера нету, лишь просто основы (на 800 страниц :( ) А начинать читать новую книгу - времени в обрез... Так совсем ничего не успею) Но в любом случае вы мне помогли. Спасибо.
Средний
