Чим займається Render Developer в геймдеві і як ним стати? Гайд по професії

Вітаю, мене звати Дмитро, я — Render Developer у Pingle Game Studio. У цій статті я хотів би познайомити читача із роллю рендер розробника, розповісти, чим такий спеціаліст відрізняється від інших інженерів, чим займається на щоденній основі, які задачі вирішує та які інструменти використовує. Трохи поговорити, що у ролі подобається, а трохи розповісти про професійний біль. Далі у статті буде визначено, наскільки затребувана ця спеціальність на ринку праці на цей момент, та які вимоги висуваються до розробника, який хотів би взяти на себе роль спеціаліста з рендеру. Також будуть наведені корисні матеріали для навчання тих, хто або вже давно цікавився цією роллю, але не знає, з чого почати, або тих, кого ця роль зацікавила вже під час читання даного матеріалу (це було б для мене найбільшим компліментом).

Ця стаття буде загалом про особистий досвід. Цей матеріал — не монстр Франкенштейна, зібраний за результатами пошуку в Інтернеті (ну, може, зовсім трішки). Тому інформація, зібрана тут, досить суб’єктивна.

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

Рендер як він є та роль рендер розробника у ньому

Для початку було б непогано визначити, що таке рендер. Рендер у комп’ютерній графіці — це процес побудови фінального зображення, з яким може взаємодіяти користувач, за допомогою як CPU (процесора), так і GPU (графічного процесора/відеокарти) на основі вхідних даних (позиція, колір, нормаль тощо). Рендер, умовно кажучи, дозволяє нам бачити результат виконання програми. Все, що ми бачимо на екрані монітора/смартфона/ігрової приставки було побудовано за допомогою рендеру, або, як то кажуть, відрендерено чи відмальовано — переведено зі стану «сирих даних» у той вид, який може ефективно сприйматися людським оком.

Виходячи з цього, рендер розробник — це спеціаліст, який розуміє, як працює рендер, знає яку участь у цьому процесі приймає графічний процесор, а яку — звичайний. Такий розробник володіє навичками безпосередньої розробки (Але це в ідеалі. Чому «в ідеалі» — буде пояснено у наступному абзаці), підтримки та відладки графічного конвеєра (graphics pipeline). Цей конвеєр, власне, і являється тим шляхом, який проходять «сирі дані», щоб у результаті стати готовим зображенням.

Рендер спеціаліст бере безпосередню участь у визначенні того, яке зображення у результаті буде показане користувачеві. Якщо казати відверто та «без прикрас», то відповідальність рендер розробника — «щоб була гарна картинка» та «щоб не лагало». У контексті сучасної розробки, зазвичай, такі спеціалісти не пишуть свій конвеєр «з нуля», а використовують бібліотеки (GLEW, GLUT, GLFW), фреймворки (наприклад, Babylon.js чи Three.js для веб розробки), чи рушії (Unity, Godot, Unreal Engine, Amazon Lumberyard, або ж кастомні рушії великих розробників ігор: Frostbyte, Ubisoft Anvil, REDengine). У цих випадках, конвейєр вже створений, а роль інженера зводиться до налагодження/розширення функціонала/розв’язання питань, пов’язаних з вже існуючими процесами. Є, звісно, виключення, але про це — згодом. Ступінь взаємодії з конвеєром визначається самим рушієм. Десь у розробника більше свободи, десь менше, але певний ступінь свободи у діях зберігається від рушія до рушія та від фреймворка до фреймворка.

Задачі, які вирішує рендер розробник

Було б перебільшенням сказати, що вся робота рендер розробника зводиться до взаємодії із графічним конвеєром, роботі із глобальними речами на кшталт освітлення, ефектів, додавання і підтримка того ж HDR ефекту, екранного згладжування (anti-aliasing) тощо. Ці задачі, безумовно, також зустрічаються, але частіше робота більш тривіальна: треба написати шейдер, матеріал або ефект, а деколи треба їх, навпаки, полагодити. Ще, наприклад, може невірно працювати рух або поворот камери — треба виправити. Чи на певних об’єктах зустрічаються артефакти при певних умовах. Невірне освітлення, некоректні, низькоякісні або відсутні тіні. Некоректне відмалювання напівпрозорих об’єктів. Або на сцені дощ капає вверх. Ще трапляється таке, що частина об’єкта, або навіть він цілком, не вимальовується. Крім цього, у обов’язки рендер-спеціаліста входить розробка нового функціоналу, що пов’язана з графічною частиною: наприклад, нова система взаємодії з камерою, постефектів, освітлення, погоди тощо.

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

Render Developer vs Graphics Developer

Якщо подивитися ринок вакансій, то час від часу можна побачити дві, на перший погляд, різні вакансії, для яких потребується схожий набір навичок — це Render Developer та Graphics Developer. Чим вони відрізняються? На перший погляд — мало чим, крім назви. На другий — теж. Та й на третій, відверто кажучи. І справді, Graphics Developer — спеціаліст, що працює з комп’ютерною графікою не на рівні митця, а на рівні інженера (що його і відрізняє від того ж Graphics Designer). Як, власне, і Render Developer. Відрізняються, в основному, сфери застосування спеціаліста. Графічного розробника частіше шукають у бізнесі, де потребується візуалізація деяких даних. Наприклад, у нафтогазовій сфері чи стоматології. Рендер розробника більше задіяний у створенні ігор. З власного досвіду можу сказати, що, хоча графічний розробник і може рендерити дані у реальному часі, часто трапляється так, що дані вже отримані з сервера, а їх просто треба відмалювати. Рендер спеціалісту же частіше доводиться працювати із рендером картинки у реальному часі — через специфіку роботи з іграми. Різниця полягає у чому: під час рендеру у реальному часі зображення відмальовується заново кожен кадр. Не у реальному — зазвичай, один чи декілька разів у високій якості, а потім користувач просто працює з цими даними та оновлює їх лише за необхідності.

Чи може спеціаліст, що має досвід у комп’ютерній графіці, проходити співбесіди та обіймати посади як графічного, так і рендер розробника? Безумовно. В них навіть задачі будуть схожі, відрізняючись лише в залежності від домену, у якому інженер працює. То ж у багатьох випадках, Graphic чи Render девелопер — це питання неймінгу. Частіше за все це один і той самий спеціаліст, з тими самими наборами навичок, але просто у різних компаніях або галузях.

А що стосовно Technical Artist?

Дійсно, якщо особливо не вдаватися у деталі, ролі Render Developer та Technical Artist можуть здатися схожими: обидва працюють з графічною частиною, обидва роблять шейдери, пост ефекти тощо. Обидві спеціальності — технічні. Обидва спеціалісти оптимізують візуальну частину та відповідальні за «гарну картинку». Але диявол ховається у деталях. Технічний художник — це поєднання технічної та художньої експертизи, інженер та митець, де превалює митець. Рендер розробник — це передусім інженер. Так, вони обидва зможуть написати шейдер та зробити освітлення сцени. Але вони працюють у різних площинах.

Якщо Technical Artist — митець, а його навички володіння 3D моделюванням, написанням шейдерів, робота зі світлом — пензлі та фарби, тоді Render Developer — це виробник холста. Рендер розробник створює самі умови для того, щоб технічний художник розкрив свій потенціал як митця. Так, він теж може написати шейдер, але його основна робота — робота з графічним пайплайном, з налаштуваннями самого рушія. Якщо технічний художник пише фотореалістичний шейдер для дощу, снігу, та й загалом погоди — рендер інженер створює саму «систему погоди».

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

Ці ролі не взаємозамінні. Рендер розробник може досить обмежено виконувати частину задач технічного художника. Так само як і звичайний розробник може обмежено виконувати ряд задач рендер розробника, такі як, наприклад, налаштування освітлення, постпроцесів, камери. Проте, для створення якісного продукту потрібні саме ролі, які спеціалізуються на своїй сфері. Кожен спеціаліст, чи то Gameplay Developer, AI Developer, Render Developer, Technical Artist — це спеціаліст, який володіє інструментами саме своєї ролі на більш високому рівні, ніж інші спеціалісти інших ролей. Так, вони можуть виконувати деякі обов’язки одне одного певною мірою. Але ситуація така ж сама, як, наприклад, звичайні розробники у невеликих командах часто виконують роль «сам собі девопса». Проте, повноцінного девопса таким чином не замінити.

Вимоги до рендер розробника

Основних навичок, які повинен опанувати рендер розробник для подальшої роботи «усього» чотири:

1. Досвід роботи бодай з однієї зі специфікацій/API (OpenGL, DirectX, Vulkan);
2. Знання теорії комп’ютерної графіки;
3. Знання 3D математики;
4. Загальні навички в алгоритмізації (тобто вміння писати якісний, масштабуємий та чистий код, наскільки це можливо у реаліях проєкту).

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

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

Початковий рівень необхідних знань з математики охоплювати лінійну алгебру — операції з векторами, матрицями, а також базові знання тригонометрії. Окрім цього, важливо знати про концепцію кватерніонів, навіщо оті комплексні числа потрібні, чим вони відрізняються від кутів Ейлеру та які проблеми вони вирішують (наприклад, складання рамок).

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

На жаль, частіше ніж того хотілося б, доводиться стикатися із задачами, де необхідно, наприклад, відладити невірне обчислення кута повороту чи нахилу, переміщення об’єктів. Або написати кастомну функцію на сотню рядків, яка обчислює позицію камери в залежності від типу даних у фокусі, та ще й таким чином, щоб камера завжди дивилися на фронтальну частину моделі. Потенційна ціна помилки при побудові архітектури, у кращому випадку — ця фіча просто не запрацює ще при написанні кода. У гіршому випадку — витрачаються людино-години на відладку та прочісування всіх вхідних, вихідних та проміжкових даних через кілька місяців, коли клієнт помітить помилку та зробить репорт. Або це викривається у граничному кейсі, що не був включений у початкові acceptance criteria. А сама помилка криється в одному рядку, наприклад, у невірному знаку множення при граничних значеннях одного з кутів. Різне буває.

У цьому пункті спеціально не вказана жодна з мов програмування, тому що для рендер розробника вона вторинна. Інструменти цієї ролі — тривимірна графіка, що не залежить від мови програмування. Змінюється синтаксис, відрізняються API, але ті концепції, ті абстракції, якими оперує спеціаліст — залишаються незмінними.

Сьогодні рендер розробник працює у веб розробці на JavaScript/TypeScript. На наступному проєкті — конфігурує конвейєр рендеру в Unity на С#, а потім — на С++ працює з кастомним рушієм або модифікованою версією Unreal Engine. Для рендер розробника немає якоїсь «мастхевної» мови програмування чи фреймворку. Послуги рендер розробника потрібні у цілковито різних сферах бізнесу, від розробки ігор до багатомільярдних галузей, як то нафтогазова та гірничодобувна промисловості. Відповідно, змінюються й інструменти в залежності від реалізації конкретного проєкту. Тільки у рамках моєї кар’єри мені довелося попрацювати із C#, Java, TypeScript та С++. Саме тому велику роль відіграє саме алгоритмізація, а не знання якоїсь конкретної мови: змінюється синтаксис, рішення при побудові програми, але патерни та алгоритми будуть виконувати одні й ті ж функції, незалежно від того, написані вони вказівниками з ручним виділенням пам’яті чи інструментами нестрогої типізації.

Окей, вивчили, а як потім знайти роботу?

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

Отже, у багатьох українських вишах на профільних кафедрах у тому чи іншому ступені вивчають комп’ютерну графіку, як мінімум на рівні OpenGL. На жаль, на ринку праці це не означає абсолютно нічого. По-перше, тих навичок, що дасть університет у багатьох випадках буде недостатньо для працевлаштування (хоча ці знання і зроблять подальше вивчення значно легшим). По-друге, багатьом студентам воно не потрібно і не цікаво, а після закінчення курікулуму забувається як страшний сон. Зазвичай, комп’ютерна графіка викладається на старших курсах, де у багатьох вже сформований їх майбутній стек та кар’єрні орієнтири.

До того ж рендер розробник, як і розробник графіки — то доволі вузькопрофільна спеціальність, якщо не сказати «екзотична». Поріг входу у професію вище, ніж, наприклад, у тій же розробці на Unity чи Unreal Engine. При цьому вакансій — значно менше. І знайти свою першу роботу, якщо спеціаліст планує розвиватися виключно як розробник графіки — питання удачі. Потреба на таких спеціалістів є, і вона постійна, проте шукають зазвичай досвідчених розробників від рівня мідл та вище. Якщо джуніор потрапить на графічну інтернатуру чи його візьмуть у рендер команду — можна вважати, що він витягнув свій щасливий квиток.

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

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

Чому саме рендер? Відповідь насправді, доволі проста — це дешевше. Зробити симуляцію значно дешевше, ніж робити все у реальному житті. Навіщо витрачати мільйон доларів у день на реальні іспити, видобування даних, сканування, експлуатацію техніки, якщо це все можна змоделювати на комп’ютері?

Рендер інженер — саме та професія, яка на основі отриманих даних може зробити певну їх візуалізацію, з якою ефективно зможуть далі працювати профільні спеціалісти: геологи, аналітики, інженери-конструктори тощо. Замість того, щоб задіяти коштовну техніку та персонал, щоб, наприклад, провести дослідження грунту, всі ці процеси проводяться на комп’ютері, за допомогою візуалізації різноманітних даних, побудованої графічними розробниками.

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

Саме тому створюється доволі парадоксальна ситуація на [українському] ринку: Кількість вакансій досить невелика, порівняно, наприклад, з Unity, Unreal Engine чи навіть Embedded розробкою на С++. При цьому, потреба на рендер спеціалістів є постійна, хоча вона і невелика. Великі ігрові компанії завжди мають штат рендер розробників. У великих аутсорс-компаніях зазвичай є як мінімум одна вакансія у бізнес доменах, яка потребує такий набір навичок.

Досвідчений розробник потрібен багатьом компаніям завжди і на вчора. А шукають його довго. Без перебільшення довго. Вакансії можуть висіти відкритими від декількох місяців і більше. Наприклад, коли я проводив співбесіди для Unity спеціалістів з графічним бекграундом, то знайти кандидата, якого можна представити замовнику, було дуже важко. Якщо цей текст читають рекрутери зі схожою відкритою вакансією, гадаю, вони розділять зі мною цей біль. Причини можуть бути різні: висока бажана експертиза кандидата, специфічні побажання замовника чи «екзотичний» стек проєкту, але факт залишається таким: закрити вакансію рендер розробника буває дуже важко.

При цьому, «вільних» спеціалістів на ринку небагато. Рендер розробники — не рідкісне явище навіть на ринку України, де потреба на цю роль менша, ніж, наприклад, у Європі. Але ці спеціалісти, у масі своїй «вже зайняті» — працюють на своєму проєкті, на гарних умовах та слабо мотивовані це змінювати.

Специфікації та API для роботи із графікою

У цьому пункті практично не буде мови про фреймворки, бібліотеки та рушії, бо для ролі рендер розробника вони, безумовно, важливі, але все ж таки вторинні. Цей пункт про більш фундаментальні речі, про те, на основі чого вони, власне, працюють. Про основні графічні специфікації та API. Я виокремлю чотири основних: OpenGL, DirectX, Vulkan, Metal.

Чому тут буде мало інформації про ті самі фреймворки? Наведу приклади: якщо ви працюєте із графікою у веб розробці і використовуєте, наприклад, Babylon.js або Three.js — це фреймоворки, що «під капотом» працюють зі специфікацією WebGL, яка побудована на основі OpenGL ES, що є варіацією OpenGL для вбудованих систем, таких як, наприклад, мобільних пристроїв. Якщо Ви знаєте, як працює WebGL, то основна різниця при роботі чи то із Babylon.js, чи то із Three.js — синтаксис та особливості реалізації конкретного фреймворка.

Інший приклад буде про рушії: Render розробники в ігровій сфері часто працюють із Unity та Unreal Engine. Unity у якості графічного API підтримує OpenGL, WebGL, DirectX, Vulkan та Metal, в залежності від того, на яку платформу буде розроблятися проєкт. А ось Unreal Engine за замовчуванням використовує DirectX, хоча він може бути переключений як на OpenGL, так і на Vulkan (останній для Android проєктів).

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

Річ у тім, що OpenGL — це кроссплатформенна специфікація, де синтаксис (але не підходи до проєктування програми!) різняться від мови до мови. Фреймворків та бібліотек для OpenGL дуже багато. Дуже. Майже для кожної мови програмування. Для С++ (тільки із найбільш відомих!) — GLFW, GLUT, freeglut, GLEW. Для C# - TAO Framework, OpenTK. Для Java — LWJGL. Для Python — PyOpenGL. І це тільки в залежності від мови програмування. Про варіації специфікацій в залежності від платформи вже було описано вище. Ця варіативність надає можливість використовувати одні і ті ж принципи роботи із графікою незалежно від платформи, що являється цільовою для програми. При цьому, безумовно, синтаксис та прийоми будуть відрізнятися в залежності від обраної мови програмування, бібліотеки/фреймворку та обчислювальних потужностей цільового пристрою.

DirectX — це набір API для розробки програм виключно для Microsoft Windows. Особливо часто він використовується для розробки ігор. Раніше DirectX протиставлявся до OpenGL, але на цей момент DirectX та OpenGL комбінуються під час розробки, при чому DirectX, на відміну від OpenGL, має ряд додаткового специфічного функціонала для розробки ігор, як то доступ до клавіатури/геймпада, підтримки звуку, мережевого коду, та інше.

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

У Вулкані спеціаліст відповідальний за створення свого конвеєра з нуля. Також, саме він відповідає за те, які етапи будуть у тому чи іншому конвеєрі, які тести будуть проводитися, вручну налаштовується порядок та спосіб малювання кадру. Як приклад можна привести буферизацію кадра. Для роботи із Vulkan API, спеціаліст сам повинен обрати, яка буферизація буде використовуватися у проєкті, подвійна або потрійна буферизація, а також вручну задати її структуру та порядок зміни кадрів. Суть подвійної буферизації в тому, що коли один кадр «показується» користувачеві, на іншому кадрі, у буфері, у той самий час рендеряться дані наступного кроку виконання програми. Потім, кадри просто «свопаються» і показується вже кадр, який був до цього приготований, а перший кадр потрапляє у буфер і там готує нове зображення. Буфер невидимий для користувача. Ця техніка дозволяє показувати плавну картинку без ривків між зміною кадрів. Потрійна буферизація, як не важко здогадатися, працює так само, але використовує три кадри замість двох.

Окрім цього, у Вулкані знову ж таки вручну потрібно встановлювати взаємозв’язок між Physical Device — відеокартою, та Logical Device — об’єктом, який безпосередньо віддає «команди» GPU, за допомогою яких і здійснюється рендер. У OpenGL, наприклад, це реалізовано за допомогою фреймворків. Розробнику не потрібно перейматися через це.

Тобто підіб’ємо підсумки, Vulkan — це API, де спеціаліст налаштовує увесь процес рендеру з нуля, але водночас, сам розробник має максимальну свободу дій і контроль над системою та графічним конвеєром, які проєктуються.

Metal — це пропрієтарний низькорівневий API для пристроїв Apple. Заявляється, що Metal поєднує в собі функції, схожі до OpenGL та може порівнюватися з іншими низькорівневими API, як то Vulkan чи DirectX. Також, є можливість запустити Vulkan поверх Metal за допомогою бібліотек сумісності як, наприклад, MoltenVK.

Поради, матеріали та трохи посилань

Переходячи до пункту з порадами: якщо ви не знаєте, з чого почати освоєння рендер ролі, можу рекомендувати починати з основ, тобто з освоєння OpenGL або DirectX. Можна і обидва, якщо буде час і можливість, але варто попередити: що OpenGL, що DirectX — ще величезний обсяг нової інформації, яку потрібно ще перетравити та засвоїти. Якщо братися за усе та відразу — буде дуже важко, то ж я б рекомендував обрати щось одне. На співбесіді, зазвичай, достатньо володіння будь-якої з них. До того ж тут треба пам’ятати, що DirectX — це розробка під Microsoft Windows, тоді як OpenGL — мультиплатформенна специфікація, тому робити вибір краще виходячи із того, що, як ви вважаєте, буде вам корисніше у майбутньому.

Особисто я йшов шляхом OpenGL, тому і радити буду ті ресурси, якими користувався сам.

Якщо розглядається варіант з онлайн курсами, можу порадити двох інструкторів на Udemy: Ben Cook та Penny de Byl. Ben Cook має по окремому курсу по сучасному OpenGL та Vulkan, де пояснюються усі їх базові концепти. Penny de Byl має більш різноманітний контент: курси з математики, розробка на OpenGL із Python та ряд курсів, пов’язаних з алгоритмами, машинним навчанням, матеріалами, процедурною генерацією. Як основний рушій у більшості курсів використовується Unity, тож ці матеріали будуть корисні як для рендер спеціалістів, так і для Unity розробників.

По книгах: OpenGL SuperBible — не рекомендую. Ця праця може допомогти рендер розробнику закрити пробіли у розумінні, як працює та чи інша частина специфікації, або вбити у новачка будь-яке бажання подальшого вивчення OpenGL. Ефект буде такий самий, як рекомендувати людині, що тільки почала вивчати С++ книгу «The C++ Programming Language» Б’ярна Страуструпа. Безперечно, обидві книги чудові, проте, як на мене, більше як довідники, де досвідчений спеціаліст може поглибити свої знання щодо роботи того чи іншого механізму мови/специфікації. На жаль, гарним матеріалом для навчання на початку свого тернистого шляху особисто я назвати це не можу. Нехай воно і добре структуровано, але обсяг інформації, що подається, занадто великий, щоб його швидко та якісно не стільки перетравити, скільки просто зрозуміти.

Екземпляр OpenGL SuperBible стояв на почесному місці на моїй кафедрі, а ось у моїй першій компанії, куди я прийшов працювати на C# та OpenGL — нею блокували стулку вікна, щоб не зачинялось. Якщо вже є бажання прочитати якусь книгу на тему, то підійде, буквально, будь-яка книга по сучасному OpenGL з гарним рейтингом на Амазоні. Що курси, що подібні книжки зазвичай йдуть по одній «програмі» і пояснюють одні й ті самі речі, просто різними словами.

Також, з альтернативних і безкоштовних джерел: ютубери. Я особисто дивився TheCherno, ThinMatrix та MakingGamesWithBen. TheCherno та MakingGamesWithBen мають серію туторіалів по OpenGL на С++, а ThinMatrix — на Java. На жаль, останній апдейт каналу MakingGamesWithBen був 6 років тому, тому цей матеріал, хоча і досить фундаментальний і інформативний, але вже дещо застарілий. TheCherno та ThinMatrix досі активні, хоча другий на цей момент і робить більший акцент на матеріалах по розробці власної гри.

Щодо графічної теорії та тривимірної математики. Моя рекомендація з графічної теорії — серія книг GPU Gems. Перші три частини (а їх значно більше) доступні безкоштовно на сайті Nvidia. Ця серія розказує про роботу GPU, роботу з графікою та принципи роботи різноманітних ефектів, алгоритмів та концепцій, що використовують при розробці ігор.

Також, є чудова книжка з ігрової математики, де описуються майже всі, якщо не всі концепції, якими оперують рендер розробники. Попри це, інформація, наведена у книзі буде корисна всім розробникам ігор і стане у нагоді в подальшій роботі (виходячи з мого досвіду проведення співбесід, часто з цим бувають проблеми). Ця книга — «3D Math Primer for Graphics and Game Development». Вона також доступна безкоштовно онлайн.

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

Висновки

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

На жаль, у цій статті не було великої кількості інформації щодо технічної частини питання: з яких етапів складається графічний пайплайн, що таке вершина, меш, нормаль, які є види освітлення та камери, що таке шейдери, як вони пишуться та з чого складаються, як відмальовуються напівпрозорі об’єкти, що таке тест глибини тощо. У процесі написання я зрозумів, що, якщо я почну заглиблюватися у цю тему, навіть у найбазовіші речі — стаття буде значно більшою за розміром, ніж вона зараз. Якщо я захочу розповісти про графічний пайплайн, тоді повинен буду спочатку пояснити шейдери та їх види, чим вершинний відрізняється від фрагментного, що таке вершина, а що таке фрагмент і так далі... А без цього користь від такого «пояснення» буде нульовою. Простіше вже написати щось на кшталт введення у теорію комп’ютерної графіки. То ж, якщо є потреба на таку інформацію українською мовою — будь ласка, обов’язково дайте про це знати в коментарях! Дякую за увагу 😊

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини