У 2.5D ви використовуєте 2D активи / методи рендерінгу, щоб надати відчуття 3D-середовища.
Тепер із цим визначенням у наступному потенційно неоднозначному сценарії потрібна певна розробка:
Гра А
Використовуючи 3D графіку, GPU прискорюється і все (ігрові об’єкти - це сітки, а не зображення), з фіксованим кутом камери. Давайте зробимо це ще гірше, проекція ортографічна, класична 63,43 градуси. Єдиний спосіб помітити на перший погляд, що графіка не є двовимірною - це те, що 3DGC, за винятком того, що ви надаєте їх з особливою обережністю, легко відрізняються від спрайтів малювання вручну, незалежно від проекції, використовуваної для їх відображення. Ви можете експериментувати з різними методами візуалізації, параметрами, шейдерами тощо, і вам буде важко намагатися приховати той факт, що вони є 3D-сітками.
Гра Б
Порт гри A, але націлений на платформи, які, як відомо, мають апаратне забезпечення, яке не дуже добре обробляє 3D-графіку або зовсім не обробляє її. Тоді порт замінює сітки спрайтами. Наприклад, він використовує 3D-обмежувальні коробки для зіткнень, наприклад, а об'єкти мають властивість позиції зі значеннями x, y і z, оскільки логіка гри в основному не торкалася або взагалі не торкалася, змінювався лише код візуалізації.
Оскільки спрацьовані ігри B представляють тривимірні активи гри A і, щоб зробити речі неоднозначнішими, гра A не робить нічого, що вимагає складних шейдерів, у 99% усіх графічних процесорів там ви не можете відрізнити кадр від гри Б кадру з гри А.
У 2.5D взаємодія між ігровими об'єктами обмежується набором ситуацій, коли ілюзія 3D не може бути порушена. Наприклад, щоб зобразити двох символів, що обіймаються, наприклад, вам доведеться створити один файл зображення із взаємодіючими двома символами, оскільки намагатися зобразити дію обняття лише за допомогою одного зображення на персонаж було б занадто важко або неможливо. Можливо, ви можете підійти з тілом персонажа, розділеним на частини, і намалювати їх у правильному порядку. У 3D цієї проблеми не існує (існує інший, тобто правильно поставити два символи, щоб вони не проникали в сітку іншого символу).
Тепер, щоб візуалізувати це, уявіть, що у грі А та В є помилка, яка в певній ситуації дозволяє персонажу гравця проходити через інший ігровий об’єкт, що дозволяє нам легко розмежовувати 2.5D та 3D.
Гра B, 2.5D Візуалізація, спрайти впорядковані за значенням z його векторного положення. У цьому прикладі позитивне z знижується, а від'ємне z - вгору. вісь z і вісь y паралельні, але z масштабується на коефіцієнт 0,5 y. Отже, якщо видима площа - від 10y до -10y, в цій же зоні ми маємо від 20z до -20z. Об'єкти з більшим z будуть намальовані останніми, тому вони будуть розглядатись як об'єкти з нижчим z. Тінь персонажа гравця виглядає дивно, тому що тіні знаходяться у вищому шарі, ніж підлогу, але в нижчому шарі, який мають усі інші об'єкти, тому тінь персонажа гравця ніколи не знаходиться на вершині куба.
Гра А, 3D візуалізація. Глибинний буфер (також відомий як z-буфер) використовується для тестування точності глибини пікселів. Отже, об’єкт не повинен повністю окулювати іншого, навіть трикутник не повинен повністю оклюзувати інший, у нас є тест на глибину точності пікселів. Ми можемо обертати ігрові об’єкти будь-яким способом і все-таки отримати реалістичні результати при взаємодії.
В резюме: у 2.5D спрайт або перед, або ззаду іншого спрайту. У 3D сетка складається з трикутників, але трикутник не є мінімальною одиницею при тестуванні на глибину, ви можете мати точність пікселів. Звичайно, обертання камери в 2.5D неможливо, оскільки активи створювались за фіксованим кутом камери, тоді як у 3D - це природно, якщо кути камери обмежені дизайном у 3D-грі - інший предмет.
Існують різні хитрощі, щоб дати відчуття перебування в 3D-світі, коли ви можете лише робити 2D-графіку, я лише представив швидко створений приклад, використовуючи деякі активи покинутого мого проекту.
Чому б просто не використовувати 3D завжди і забути про 2.5D?
Ну, я можу подумати на деяких прикладах, чому розробник може віддавати перевагу 2.5D-підходу:
- Можливо, вони не знають або не люблять 3D API (Direct3D, OpenGL, є й інші).
- Можливо, цільова платформа не справляється добре з 3D графікою (старі настільні комп’ютери, 2D консолі).
- Ваша команда може робити дивовижні спрайти, але не 3D-моделі.
На скільки ви можете наблизити результати 3D-графіки за допомогою 2.5D?
Існує горизонт складності продуктивності та програмування. Коли ви наближаєтесь до цього горизонту, ви починаєте сумніватися, чи справді ваш проект можливий в 2.5D чи вам доведеться пройти повний 3D. Наприклад, ви можете використовувати z-буферизацію в 2.5D (теоретично), але чи можете ви заплатити вартість відеопам'яті (старий настільний комп'ютер з вбудованою графікою, а не потужні мобільні пристрої)? Ви хочете оплатити вартість зберігання додаткового зображення, щоб зберегти z-маску кожного спрайту?
Хорошими кандидатами на 2.5D є ігри RPG, думаю, серія Ворота Балдура або RTS, вважає Age of Empires 1 і 2 (AoE 3 повністю 3D і легко розрізнити).
Корисні посилання:
Z-Buffering: http://en.wikipedia.org/wiki/Z-buffering
Ортографічні проекції: http://glasnost.itcarlow.ie/~powerk/GeneralGraphicsNotes/projection/orthographicprojection.html