Як здійснюється рендеринг програмного забезпечення?

Я хотів би вивчити растеризацію на основі програмного забезпечення в реальному часі. Я знаю, що все йде назустріч графічному процесору, але є кілька ігор, де все-таки є сенс використовувати програмний рендер.

Наприклад: Воксельтрон

Voxatron - шутер на арені, який відбувається у світі, складеному з вокселів (маленькі кубики, вид). Все в грі відображається у віртуальному дисплеї вокселів 128x128x64, включаючи меню та інвентар плеєра. Якщо придивитися, то іноді можна побачити інвентар (оцінка / життя / боєприпаси), який кидає тінь на деякі об'єкти на землі.

Я вже давно працюю над інструментами візуалізації та моделювання вокселів, з кінцевою метою - створити велику пригодницьку гру. Близько півроку тому він злився з роботою, яку я робив на аренах стрільців для Conflux, і це результат.

Дуже проста гра в душі - в основному просто Robotron встановлений у 3d руйнівному світі з тупими істотами. Я не впевнений, наскільки важливими будуть наслідки руйнування для ігрового процесу, але я впевнений, що це приємно підірвати шматки стіни. Я також додав експериментальний пікап для будівництва стін, який можна використовувати для побудови перешкод, щоб сховатися від страшних монстрів.

Гра відбувається на невеликому наборі арен. Деякі з них обладнані кімнатами із встановленими бойовиками, десь між Knightlore та Smash TV. Це частина оригінального дизайну, заснованого на пригодницьких ситуаціях, що підкрадається, і привід для створення тематичних середовищ.

Особливості:

• Спеціальна візуалізація програмного забезпечення з м'якими тінями.
• Вбудований синтезатор звуку та музики (також використовується для створення музики трейлера).
• Відтворення та розміщення запису гри.

Я припускаю, що ви вже знаєте деякі основні лінійні алгебри, такі, як: 3D-проекції, налаштування камери, перетворення вершин у світову позицію тощо. Якщо ви цього не зробите, є багато чудових місць, з яких слід вчитися. Ось два, які мені подобаються:

Архітектура ігрового двигуна

• Коротке висвітлення основної лінійної алгебри, але охоплює все, що потрібно знати. Книгу варто мати і з багатьох інших причин.

Візуалізація в режимі реального часу

• Трохи більш детальне висвітлення, але знову дотримується лише того, що вам може знадобитися знати. Знову рекомендую цю для тем, що висвітлюються в решті розділів.

Коли ви дізнаєтесь про те, як представляти та обробляти 3d об’єкти, ви готові подивитися, як намалювати їх на екрані. Зазвичай це робиться за допомогою методики растризації трикутника сканування ліній трикутника. Це насправді досить проста концепція. Ви малюєте по одному рядку одного трикутника за один раз, інтерполюючи координати кольорів і текстури uv. Цей процес продовжується для всіх трикутників на екрані. Ви навіть можете застосувати глибинний буфер, щоб обробити подання порядку.

Про це детальніше йдеться в цих статтях:

Навчальний посібник - Вступ до програмного забезпечення: Реалізація трикутника

Школа надання програмного забезпечення: частина I

І просто для розваги ознайомтеся з наступною статтею:

Огляд вихідного коду Quake 2 3/4 (Програмний рендер)

Це досить широка тема. Однак у ньому є дві основні частини: власне теорія трансформації графіки та конвеєра растерізації та фактичні біти реалізації, які дозволяють вибухувати пікселі на екрані, як тільки ви не хочете. Крім цього, є також оптимізація (особливо, останній біт).

Перша частина, на щастя, така ж, як і теорія, що використовується для графічного конвеєра, що піддається сучасним обладнанням та API. Якщо ви вже знаєте це, ви налаштовані. Якщо ви цього не зробите, рекомендую гарну книгу. Цей досить гарний.

Варіантів другої частини дуже багато. Вони сильно залежать від вашого вибору ОС та інструментальної мережі. Якщо ви використовуєте C або C ++, у Windows, ви можете просто побудувати пікселі безпосередньо на растровій графіці GDI ( SetPixelце просто, але болісно, ​​марно повільно - CreateDIBSectionдає шматок необроблених байтів, якими ви можете маніпулювати набагато швидше).

Ви також можете придбати поверхню DirectDraw і записати на неї або записати текстуру Direct3D або OpenGL. У цих останніх випадках ви все одно будете використовувати апаратне забезпечення, але поки ви самі робите всю композицію остаточного зображення на процесорі та просто використовуєте апаратні API, щоб скопіювати результати на екран, він все одно зараховується. На сучасних комп'ютерах ви не можете отримати доступ до сирої VRAM чи нічого іншого безпосередньо.

Якщо ви хочете дізнатися більше, вам, ймовірно, слід створити більш конкретні запитання. Я або інші були б раді відповісти на них.

Гаразд я підходжу до цього питання з самих основ; все, що є поза цим способом для простого забезпечення якості; вам потрібно придбати книгу на цю тему.

Найбільш принципова різниця між візуалізацією в програмному забезпеченні та використанням графічного процесора зводиться до побудови графіків пікселів. Тобто, при проведенні програмного рендерингу ви в кінцевому рахунку відповідаєте за побудову кожного проклятого пікселя, тоді як із графічним процесором графічне зображення пікселів значною мірою автоматизоване обладнанням, і ви просто «масажуєте» піксельний конвеєр за допомогою шейдерів.

Наприклад, подумайте, що ви, як програміст, повинні зробити для того, щоб на екрані відображався трикутник 3D. З графічним процесором ви майже просто розповідаєте обладнанням, що таке координати вершин X, Y, Z, а потім відеокарта заповнює всі пікселі на екрані, що містять зображення трикутника. Ви можете скористатися шейдером, щоб сказати GPU змінити колір кожного пікселя на основі текстури чи чогось іншого, але в кінцевому підсумку він все ще зводиться до того, що GPU автоматично заповнює всі пікселі для вас.

Роблячи програмне відображення, вам доведеться обчислити, які пікселі на екрані потрібно заповнити, а потім виконати блимання, щоб фактично заповнити ці пікселі. Тобто, ви б робили математику матриці для перетворення з координатного простору тривимірної сцени в простір перегляду, потім проектування точок з простору перегляду на екран тощо.