Чи повинні нові графічні програмісти навчатись Вулкану замість OpenGL?


53

З вікі : "API Vulkan спочатку називався" ініціативою OpenGL наступного покоління "від Хроно", і що це "зусилля, спрямовані на перероблення підстав для об'єднання OpenGL та OpenGL ES в один загальний API, який не буде зворотним. сумісний з існуючими версіями OpenGL ".

Тож чи варто краще слухачам, які зараз переходять на графічне програмування, вчитися Вулкану замість OpenGL? Здається, вони будуть виконувати ту саму мету.


1
Якщо ви можете зробити щось в одному API, ви можете зробити це будь-який інший API, саме спосіб його виконання залежатиме від API.
A --- B

Відповіді:


33

Навряд чи!

Це здається чимось схожим на запитання "Чи повинні нові програмісти вивчати C ++ замість C" або "Чи повинні нові художники навчатися цифровому живопису замість фізичного живопису".

Тим більше, що це НЕ сумісне з відсталими графічними програмістами було б нерозумно виключати найпоширеніший графічний API в галузі просто тому, що є новий. Крім того, OpenGL робить різні речі по-різному. Цілком можливо, що компанія обрала б OpenGL над Vulkan, особливо на початку гри, і ця компанія не зацікавила б того, хто не знає OpenGL, незалежно від того, знають вони Вулкана чи ні.

Спеціалізація рідко є товарним навиком.

Тим, кому не потрібно продавати свої навички як такі, як інді-розробники, було б навіть ДУЖЕ дурнішим видалити інструмент зі своєї панелі інструментів. Інді-розробник ще більше залежить від гнучкості та можливості вибору того, що працює, ніж того, що отримують фінансування. Спеціалізація на Вулкан обмежує лише ваші варіанти.

Спеціалізація рідко є ефективною парадигмою.


2
Хороший відповідь, нагадав мені про це: elise.com/quotes/heinlein_-_specialization_is_for_insects
Will

7
Ця аналогія C ++ є недоречною. Vulkan - це новий API нового покоління, розроблений творцями OpenGL. C ++ є усталеним конкурентом C., здебільшого зворотним,
Moby Disk

Ця специфіка не має значення для погляду аналогії.
mHurley

6
Стверджувати, що спеціалізація є неефективною, або не маркована неймовірно наївна. Перекладач, який знає всі п’ять слів у кожній розмовній мові, марний, люди наймуть перекладачів, які засвоїли (він же спеціалізувався) на невеликій кількості мов. Тепер над -specializing є проблематичним. Перекладач, який повністю опанував одну мову і знає лише, що мова також не є корисним перекладачем. І дияволам (інді чи іншим чином) потрібно бути обережними, щоб не витрачати весь свій час на вивчення нових інструментів. Врешті-решт їм потрібно щось продати, щоб вони не збанкрутували
8bittree

Щоб було зрозуміло, я не обов'язково погоджуюся з вами щодо OpenGL та Vulkan. Це, цілком можливо, випадок, коли навчання як замість просто Вулкана є кращим вибором.
8bittree

40

Якщо ви починаєте зараз, і хочете займатися графічною роботою (на відміну від того, щоб завжди використовувати ігровий движок, такий як Unity), вам обов'язково слід почати з вивчення Вулкана. Можливо, вам слід пізнати GL також пізніше, але є кілька причин подумати Вулкан-перше.

  1. GL і GLES були розроблені багато років тому, коли GPU працювали зовсім по-іншому. (Найбільш очевидною різницею є те, що миттєві дзвінки в режимі прямого режиму проти плитки та черги команд.) GL заохочує вас мислити у стилі негайного режиму та має багато застарілих. Vulkan пропонує моделі програмування, які набагато ближче до того, як працюють сучасні графічні процесори, тому, якщо ви навчитеся Vulkan, ви будете краще розуміти, як технологія працює насправді, а також те, що є ефективним, а що неефективним. Я бачу багато людей, які розпочали роботу з GL або GLES і негайно потрапляють у шкідливі звички, як-от видавати окремі дзвінки за темою на об'єкт замість використання VBO, або ще гірше, використовуючи списки відображення. Програмістам GL важко дізнатися, що більше не рекомендується.

  2. Набагато простіше перейти від Вулкана до GL або GLES, ніж навпаки. Вулкан робить явні багато речей, які були приховані або непередбачувані в GL, такі як контроль за одночасністю, обмін та стан візуалізації. Це підштовхує велику складність від драйвера до програми: але, роблячи це, він дає контроль над додатком і спрощує отримання передбачуваної продуктивності та сумісності між різними постачальниками GPU. Якщо у вас є якийсь код, який працює у Vulkan, досить просто надіслати його на GL або GLES, і ви закінчите щось, що використовує хороші звички GL / GLES. Якщо у вас є код, який працює в GL або GLES, вам майже доведеться почати заново, щоб змусити його ефективно працювати в Вулкані: особливо, якщо він був написаний у старовинному стилі (див. Пункт 1).

Спочатку я був стурбований тим, що Vulkan набагато складніше програмувати, і що, як би було нормально для досвідчених розробників у великих компаніях, це буде величезним бар'єром для індисів та любителів. Я поставив це запитання деяким членам Робочої групи, і вони сказали, що мають деякі дані даних від людей, з якими вони розмовляли, які вже переїхали до Вулкана. Ці люди варіюються від розробників Epic, які працюють над інтеграцією UE4, до розробників ігор для любителів. Їх досвід полягав у тому, що початок роботи (тобто отримання одного трикутника на екрані) передбачав вивчення більше концепцій та довший код котла, але це було не надто складно, навіть для індіанців. Але, дійшовши до цього етапу, їм було набагато легше розробити справжню, доступну для використання програму, тому що: (а) поведінка набагато передбачуваніше між реалізаціями різних постачальників, і (б) потрапляння на щось, що добре справляється з усіма включеними ефектами, не передбачає стільки спроб і помилок. Маючи досвід справжніх розробників, вони переконали мене, що програмування проти Vulkan є життєздатним навіть для початківців графіків, і що загальна складність менша, коли ти пройдеш повчальний посібник і розпочнеш розробку демонстрацій чи програм, які ти можеш надати іншим людям.

Як говорили інші: GL доступний на багатьох платформах, WebGL - це приємний механізм доставки, існує багато існуючого програмного забезпечення, яке використовує GL, і для цієї майстерності наймається багато роботодавців. Це буде протягом наступних кількох років, поки Вулкан наростає і розвиває екосистему. З цих причин вам нерозумно буде виключати вивчення ГЛ цілком. Незважаючи на це, ви будете мати набагато простіший час з цим, і станете кращим програмістом GL (і краще програмістом GPU взагалі), якщо ви почнете з чогось, що допоможе вам зрозуміти GPU, а не зрозуміти, як вони працювали 20 років тому.

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

Щоб бути розробником інді-ігор, або ігровим дизайнером, або робити досвід VR, вам не потрібно вчитися Vulkan або GL. Багато людей починають працювати з ігровим двигуном (Unity або UE4 популярні на даний момент). Використання такого двигуна дозволить вам зосередитись на досвіді, який ви хочете створити, а не на технології, що стоїть за ним. Це приховає від вас відмінності між GL та Vulkan, і вам не потрібно буде турбуватися про те, що підтримується на вашій платформі. Це дозволить вам дізнатися про тривимірні координати, перетворення, освітлення та анімацію, без того, щоб мати справу з усіма суворими деталями одразу. Деякі ігрові або VR-студії працюють лише в двигуні, і вони взагалі не мають штатного експерта GL. Навіть у більших студіях, які пишуть власні двигуни, люди, які займаються графічним програмуванням, меншість,

Дізнатися про деталі взаємодії з графічним процесором - це, безумовно, корисний навик, який багато цінуватимуть роботодавці, але вам не варто відчувати, що вам доведеться вчитися цьому, щоб потрапити в програмування 3D; і навіть якщо ви це знаєте, це не обов'язково буде чимось, що ви використовуєте щодня.


2
Я дещо не згоден. Вулкан (і DX12) виявився дуже важким у виконанні для досвідчених розробників. При всій силі, яку дає вам Вулкан, дуже легко прострілити себе в ногу. Крім того, Vulkan вимагає набагато більше кодового коду. Якщо хтось тільки дізнається про програмування GPU, я схильний думати, що Вулкан буде дуже непосильним.
RichieSams

2
@RichieSams Я не думаю, що ти мав на увазі "реалізувати". Тільки постачальник GPU повинен реалізувати Vulkan, і це набагато простіше, ніж реалізувати OpenGL. (Повірте, я це зробив!) Але якщо припустити, що ви мали на увазі, що важко інтегруватись або програмувати проти, я додав абзац з деякою інформацією, яку я дізнався з РГ "Вулкан".
Dan Hulme

Правильно. Реалізація - це, мабуть, поганий вибір слова. Я мав на увазі "використовувати" у вашій програмі. Але мені подобаються ваші правки. Добре кажучи
RichieSams

@DanHulme - Я здивований вашим коментарем "GL заохочує вас думати в стилі" негайний режим ". Я думав, що це стосується лише ранніх версій OpenGL?
ToolmakerSteve

1
@ToolmakerSteve OpenGL WG доклав багато роботи над додаванням паралельності та пакетних записів, тож ви можете виразити свою програму способом, який підходить для виконання плитки / відкладеного впровадження. Але це все-таки фундамент, який був встановлений у віці найближчого режиму, саме тому ці люди вирішили, що в Вулкані потрібен новий старт. І я все ще бачу багато нових користувачів, починаючи з GL та формуючи ментальну модель негайного режиму роботи реалізацій.
Dan Hulme

26

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

Тож питання таке: чи хочете ви навчитися користуватися API? Або ви хочете вивчити графіку ?

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

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

Але насправді це не графічні поняття. Вони є засобом для досягнення мети.

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

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

Просто порівняйте, що потрібно, щоб зробити щось таке просте, як очищення екрана. Для Вулкана це вимагає хоча б деякого розуміння великої кількості понять: буфери команд, черги пристроїв, об'єкти пам'яті, зображення та різні конструкції WSI.

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

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

Крім того, OpenGL є (відносно) безпечним API. Він зазвичай видасть помилки, коли ви робите щось не так, як правило. Вулкан - ні. Хоча існують шари налагодження, які ви можете використовувати, щоб допомогти, ядро ​​API Vulkan майже нічого не скаже вам, якщо не буде апаратної помилки. Якщо ви зробите щось не так, ви можете отримати сміття або зламати GPU.

У поєднанні зі складністю Вулкана стає дуже просто випадково зробити неправильну справу. Забувши встановити текстуру під правильний макет, може працювати під однією реалізацією, але не за іншою. Забути точку синхронізації може іноді спрацювати, але потім раптом не вдасться, здавалося б, без причин. І так далі.


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

Графічне виконання .

Будучи 3D-графічним програмістом зазвичай вимагає певного уявлення про те, як оптимізувати код. І саме тут OpenGL приховує інформацію та робити речі за вашою спиною стає проблемою.

Модель пам'яті OpenGL є синхронною. Реалізація може видавати команди асинхронно до тих пір, поки користувач не зможе визначити різницю. Отже, якщо ви рендеруєте на якесь зображення, то спробуйте прочитати з нього, реалізація повинна видавати явну подію синхронізації між цими двома завданнями.

Але для досягнення продуктивності в OpenGL ви повинні знати, що реалізація робить це, щоб ви могли його уникнути . Ви повинні усвідомити, де реалізація таємно видає події синхронізації, а потім переписати свій код, щоб максимально їх уникнути. Але сам API не робить цього очевидним; ви повинні звідкись здобути ці знання.

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

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

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

У OpenGL API в основному пропонує вам змінити вкладення framebuffer мимоволі. Немає вказівок щодо того, які зміни будуть швидкими чи повільними.

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

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


1
Я радий, що ви опублікували це, оскільки це чітко дає зрозуміти деякі ідеї, які я вагався висловити у своїй відповіді: що вивчення концепцій є найважливішим. Я думаю, що ми відрізняємося тим, що ти заохочуєш GL, тому що простіше розпочати роботу, хоча я думаю, що простота початку роботи приносить ризик робити речі у старі речі. В GL досить складно дізнатися, що таке "сучасна ідіома GL", порівняно з програмуванням у спадковому стилі. Якщо ніхто не скаже вам використовувати VAO замість окремого дзвінка за примітивом, набагато важче пізнати цю помилку пізніше.
Dan Hulme

1
@DanHulme: Вся справа у використанні правильних навчальних матеріалів. В Інтернеті є багато таких матеріалів, які використовують сучасні ідіоми. Ніхто ніколи не повинен намагатися вивчити графіку, лише читаючи посібник чи технічні характеристики.
Ніколь Болас

Зробити це дуже просто! Незважаючи на це, я все ще бачу програмістів, що починають працювати з графікою - деякі з них дуже компетентні в інших сферах - і використовують застарілі функції та нічого не дізнаються про характеристики продуктивності. Це дійсно важко отримати , що неправильно в Vulkan, тому що це робить дорогі речі виглядають дорого. У всякому разі, нам не потрібно сперечатися. Я погоджуюся з вашим головним моментом: вивчення концепцій є найважливішим, і ви можете це зробити без Вулкана чи GL.
Dan Hulme

@DanHulme: " Дійсно важко розібратися у Вулкані ". Тому що ти занадто зайнятий тим, що все інше не так;) Крім того, в Вулкані все ще досить легко помилитися. Непотрібна синхронізація. Використовуючи лише "загальний" макет зображення. Не скориставшись переходами. Часті зміни трубопроводу. І так далі. Не кажучи вже про те, що різні продавці навіть не домовляються про те, як найкраще використовувати Vulkan.
Нікол Болас

2
@DanHulme: Що стосується простоти використання сучасного OpenGL, я роблю все можливе, щоб зробити його легким . Якщо люди наполягають на тому, щоб вчитися на сміттєвих сайтах, таких як NeHe, чи читаючи випадкову документацію, ніхто не може допомогти. Ви можете вести коней до води, але ви не можете змусити їх пити.
Нікол Болас

7

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


Я б сказав, що якщо OSX коли-небудь підтримуватиме Vulkan, він підтримуватиме лише невелику його підмножину, і це також стане графічним api нового покоління для веб-браузерів, OpenGL все ще є простими у використанні (певною мірою, звичайно), ніж Вулкан, що вулкан виграє у простоті над рендерінгом конвеєра, він втратить його в явній обробці багатьох інших речей
GameDeveloper

1
Безпосередній режим @DarioOO OpenGL - простіший у використанні, ніж будь-який режим, який ви називаєте-те-що-це-не-негайний режим, але це не рекомендується.
користувач253751

1
@Gavin: Слід зазначити, що версії 4.2GL або новішої версії OpenGL також не підтримуються в OSX. Тож якщо ви хочете використовувати що-небудь недавнє з OpenGL на OSX, ви не можете. І Apple навряд чи прийме більш пізні версії OpenGL. Платформа Apple є всеохоплюючою на металі, тому крос-платформа - це будь-який крах.
Ніколь Болас

Apple ніколи не підтримає Вулкан, якщо їх не змусять, а економія цього досить проста. Зробивши все на Metal, вони сподіваються зафіксувати розробників мобільних ігор, яким потрібно більше, ніж може запропонувати GLES2, але не мають ресурсів для написання своїх ігор і для Vulkan, і для Metal. Вони готові пожертвувати для цього крихітною ігровою екосистемою Mac, особливо якщо розробки iOS також випущені в магазині додатків Mac.
Джонатан Болдуін

Зараз Вулкан працює над macOS (раніше OS X): moltengl.com
Олександр

4

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

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

Vulkan ближче до обладнання, тому що OpenGL робить багато речей під кришкою, які у Vulkan ви робите вручну, як виконувати чергу команд. Також управління пам'яттю залежить від програми, а не драйвера. Вам потрібно потурбуватися про розподіл пам'яті для uniforms(змінної, яку ви передаєте з процесора в GPU), і про їх відстеження. У вас є про що більше турбуватися, але це також дає більше свободи у використанні пам'яті. Це може здатися страшним і непосильним, але насправді це не так. Це лише наступний API, який потрібно вивчити.

Розуміння цих речей також допоможе зрозуміти, як працює GPU. Що дозволить зробити оптимізацію як на Vulkan, так і на OpenGL.

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


2

Я вже декілька місяців "заходжу" в графічне програмування.

Зараз я все ще в середній школі, і можу вам сказати, що майже завжди хочу розробити крос-платформні програми. Це фактично моя проблема номер один з Vulkan - Він розроблений не для роботи на всіх платформах. Я працюю з OpenGL на Java і працюю понад 6 місяців.

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

Це було сказано, хоча я здебільшого працюю з OpenGL, я розумію основні принципи DirectX та Vulkan. Хоча я не працюю з ними широко, особливо Vulkan, оскільки це дуже важко вчитися і не настільки структурований для програмування, як OpenGl і DirectX.

Нарешті, я хотів би додати, що спеціалізація в одній галузі, як я в основному використовую Java та OpenGL, не є надзвичайно товарним автономним. Якби я хотів влаштуватися на роботу в компанію, яка займається іграми, здебільшого OpenGL використовувався б лише для створення ігор для Linux та Android, а можливо і для OSX. DirectX для Windows та консолей <Який Vulkan може замінити в деяких випадках.

Я не можу назавжди триматися за оновлення OpenGL, і я не хочу. Але це я віддаю перевагу розвитку.


" Ще одна проблема, що я маю з претензіями Вулкана, - це те, як він стверджує, що кращий ". Вулкан не претендує на те, щоб бути чим. Це просто API; він не може пред'являти претензій.
Ніколь Болас

Ви розумієте, що Vulkan та GL складають переважно одні і ті ж люди?
Dan Hulme

Так. Я все ще віддаю перевагу GL
Winter Roberts

2

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

Я кажу вам , що я думаю , що це найкращий підхід , на мій погляд , щоб дізнатися комп'ютерну графіку «як професіонал».

  1. Вивчіть лінійну алгебру та геометрію, як професіонали. Без цього забудьте будь-який фантазійний API чи графіку
  2. Купіть хорошу книгу з комп'ютерної графіки (наприклад, Основи комп'ютерної графіки )
  3. Поки ви вивчаєте книгу, налаштуйте середовище програмування з чимось, що дозволяє намалювати зображення та реалізувати алгоритми! Це може бути Java 2D або C ++ і SDL або навіть Python та Pygame для того, що це має значення. На цьому етапі вам потрібно отримати свої обертові текстуровані передачі з декількома переглядами камери, перш ніж намагатися отримати 10000 FPS
  4. Тепер візьміть OpenGL, Vulkan або DirectX і повторіть свій фантазійний приклад (див. Вище).

Починати турбуватися про продуктивність, перш ніж зрозуміти, як намалювати лінію, - це як турбуватися про аеродинаміку вашого автомобіля, перш ніж отримати посвідчення водія.


0

Мене самостійно навчають на C ++, не маючи офіційної освіти, і протягом останніх 15 років я навчився як OpenGL 1.0, так і через Modern OpenGL та DirectX 9c, 10 і 11. Я не потрапив у DirectX 12 і хотів спробуй мою руку на Вулкан. Я виконав лише кілька основних навчальних посібників, щоб намалювати простий трикутник або простий прядильний куб з Вулканом. Як і в DirectX 11 і OpenGL 3.3+, я написав повністю працюючі двигуни для 3D-ігор і навіть використовував їх для створення простих ігор.

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

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

Тепер, якщо ви вже розумієте всю математику та теорію, що стоїть за нею, і у вас є досвід програмування, ви можете використовувати вже наявні API, бібліотеки та додатки, такі як Unity або Unreal Engine, і просто написати вихідний код і сценарії, необхідні для того, щоб ваша програма працювала .

Отже, з мого власного розуміння і того, як я бачу, це саме це, якщо ви шукаєте побудувати швидку гру саме заради побудови гри; продовжуйте роботу з уже наявними рамковими роботами, які б зробили ваш час виготовлення значно меншим. З іншого боку, якщо ви хочете зрозуміти внутрішню роботу того, як розробляються ігрові двигуни / фізика двигуни / анімаційні двигуни та симулятори, і хочете створити їх самостійно, то тут ви маєте вибір між вибором свого API, такого як DirectX, OpenGL або Vulkan. Одним із визначальних факторів тут також будуть ваші існуючі знання з програмування. Що я маю на увазі під цим, якщо ви нічого не знаєте про багатопотокові, синхронні проти асинхронні дзвінки, огорожі пам'яті, перегони даних, семафори та паралелізм (паралельне програмування),

Я згадую це, тому що якщо ви не знаєте, як правильно керувати пам’яттю разом із потоками та часом доступу; Вулкан укусить тебе в дупу! Де OpenGL та DirectX будуть тримати вашу руку весь час, споживаючи набагато більше процесорної потужності.

Тепер, якщо ваш рівень знань з програмування пристойний, і у вас є наступні математичні фони, які передбачають усі рівні алгебри, геометрії, тригонометрії, булевої алгебри, ймовірності, статистики, вектор - алгебра на основі матриці, обчислення I, II, .... Інфінті (лол). Векторне обчислення, лінійна алгебра, системи лінійних рівнянь, аналітична геометрія з векторним обчисленням множинних змінних обчислень, теорія чисел і множин, набори даних і структури, обчислювальний аналіз, обчислювальний та алгоритмічний дизайн. Тоді ви можете зрозуміти, що потрібно, щоб зробити фактичний ігровий двигун, і це без будь-якої прикладної математики чи будь-яких рівнянь фізики, які вам знадобляться. Коли у вас є цей досвід і достатній досвід програмування, особливо управління пам'яттю та арифметикою вказівника, ви можете приступити до створення свого Game Engine.

Тому справа в тому, що ви повинні зрозуміти всі аспекти того, що потрібно зробити для створення ігрового двигуна, щоб зробити розширене графічне програмування. Якщо ви робите лише двовимірну графіку, то життя не надто складно, оскільки ви можете зробити це в Python без жодного з вищезгаданих API! Але якщо ви хочете бути серйозними та спроектувати повноцінний Power House Game Engine, який є надійним з багатьма наборами функцій, то вибір тут буде або C, або C ++, і використовувати OpenGL, Direct X або Vulkan. Будь-яка з них була б просто чудово. Тепер, якщо ви будуєте Двигун від Scratch і шукаєте найефективніший двигун із найменшою витратою ресурсів, тоді ви хочете обрати Вулкан. Але якщо ви йдете цим маршрутом, ви повинні хоча б знати все, що я згадував вище, і деякі!

Отже, як бачите, Вулкан не дуже орієнтований на початківців програмістів у цій галузі. Ви повинні мати широкі знання з усієї математики, парадигм програмування, усіх різних типів наборів даних та алгоритмів, включаючи різьблення, синхронізацію пам'яті, паралельне програмування. І навіть тоді це просто для того, щоб програма завантажила на екран простий 2D трикутник. Що можна зробити приблизно в 100 рядках коду в OpenGL або 250 рядків коду в DirectX, це майже 1000 рядків коду у Вулкані!

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

Тепер це не означає, що початківці або ті, хто є новим у цій галузі, не повинні вивчати Вулкан, але те, що я б запропонував для них, це таке: спочатку вивчіть достатньо OpenGL та або DirectX, щоб змочити ноги, щоб побачити, як базовий додаток побудований просто для створення простого трикутника або прядильного куба. Ознайомтеся з їх API та їх повторюваними моделями їх структур. Дізнавшись про те, що ви можете навчитися Вулкану на паралельній стороні, тоді таким чином ви можете бачити, як кожен з трьох виконує одне і те ж завдання, але знаєте, як вони це роблять по-різному, то ви також можете порівняти результати між різними API та з там ви зможете зробити вибір, який вам більше до вподоби. Цей метод також надасть вам інший інструмент у вікні інструментів, і ви навіть можете написати свою заявку на підтримку всіх 3 та мати "

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


-1

Спершу слід вивчити OpenGL, як це є стандартом для графіки, на стільки платформах.

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

  1. Ніхто не хоче відразу адаптуватися і в кінцевому підсумку перекрутити нестабільну рамку / бібліотеку.

  2. Їм потрібно буде найняти / перекваліфікувати своїх поточних програмістів Open-GL, і в цьому немає необхідності.


Крім того, я чув, що OpenGL і Vulkan не зовсім однакові. Я чую, що Vulkan - це API нижчого рівня та ближче до машинного коду, ніж OpenGL.

Ця відповідь, яку я щойно знайшов, має багато чудової інформації

https://gamedev.stackexchange.com/questions/96014/what-is-vulkan-and-how-does-it-differ-from-opengl


Ще одна річ, яку варто враховувати - це проблема, що сталася ще з OpenGL 1.

У OpenGL 1 до OpenGL 2 відбулися ОСНОВНІ зміни, і оскільки багато людей використовували OpenGL1, а апаратне забезпечення його підтримувало, для деяких додатків / двигунів потрібна велика зворотна сумісність, а розробникам постійно болісно підтримувати її. .

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

Це трапилося з такими рамками, як JavaFX (від 1.x до 2.x) та Play! Рамка (Також від 1.x до 2.x). Повні зміни в рамках, тобто ми повинні перевчитись ... все ...


Отже, по суті, ви повинні зачекати, поки Вулкан стане СТАБІЛЬНИМ. Це означає, чекайте, поки напевно, патч 2.0. Це не означає, що ви не можете дізнатися про основи Вулкана, але просто знаєте, що це може змінитися. Я б припустив, що така група, як Kronos, забезпечила б дуже стабільний API з самого початку, тим більше, що на Vulkan працюють багато інженерів Nvidia та AMD, в тому числі і високопоставлена ​​особа Nvidia, яка, мабуть, курирує проект, а також база Мантії; однак, як і будь-яке програмне забезпечення, ми, кодери, побачимо, наскільки добре воно працює з самого початку, але багато хто насторожено і чекають, щоб побачити, що станеться.


Вулкан зараз стабільний. Ваша аналогія GL 1.0 проти 2.0 є доречною. Починати з GL зараз було б як би почати вивчати GL 1.0 через півроку після виходу GL 2.0.
Dan Hulme

1
Вулкан може бути "стабільним", це не означає, що речі не змінюватимуться, це природа мов, на якій я представив дві останні зміни в мовах протягом останніх кількох років, тож як ми знаємо, що цього не сталося б з Вулканом? Ви в основному говорите, що навчання OpenGL - марно, і це помилково. Здається, що OpenGL мертвий, і більше не використовуватимуться ... Також неправдиво. Крім того, я не єдиний, хто вважає, що Вулкан може мати проблеми зі стабільністю. Це не може, але з будь-якою новою мовою, це те, що ви шукаєте.
XaolingBao

1
Звичайно, все зміниться, і робоча група вже працює над новими можливостями для наступної специфікації (ssh, ви цього не чули від мене). Стабільний означає, що ті речі додадуть специфікацію, а те, про що ви дізнаєтесь сьогодні, все ще буде діяти через два роки. ОТО, те, про що ви дізнаєтесь сьогодні про GL, - це вже погана відповідність тому, як працюють графічні процесори: подібно тому, як дізнаватися про трубопроводи з фіксованою функцією в світі програмованого шейдера. Якщо ви читаєте мою відповідь, то бачите, що я не думаю, що навчання ГЛ зараз марно. Але "Вулкан занадто новий" - це не вагомий привід знижувати його.
Dan Hulme

1
@Lasagna: " Це те, що воно може змінитися, не багато компаній пристосуються до його використання відразу " Valve. Епос. Єдність. Усі вони вкладають великі кошти в те, щоб їх двигуни працювали на Вулкані. CryTech і Id теж точно не ігнорують його. Отже, ваше твердження не співмірне з фактами.
Ніколь Болас

2
@Lasagna: " Тільки тому, що він адаптується до 3D-двигунів, чи не означає, що компанії вкладають у нього свої проекти " ... Тож 3D-двигуни не кваліфікуються як "проекти"? Чи DOTA2 вважається "проектом"? Тому що він отримав підтримку Vulkan прямо зараз . Чи вважає лінійку смартфонів та планшетів Samsung «проектом»? Тому що вони хочуть включити його в інтерфейс користувача. Реальність полягає в тому, що багато людей готові "випробувати нову платформу", якщо ця платформа отримає їм те, що їм потрібно.
Нікол Болас
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.