Должны ли новые графические программисты изучать Vulkan вместо OpenGL?


53

Из вики : «Vulkan API изначально упоминался как« инициатива OpenGL следующего поколения »от Khrono», и что это « основополагающая попытка редизайна объединить OpenGL и OpenGL ES в один общий API, который не будет обратным» совместим с существующими версиями OpenGL ".

Так стоит ли лучше изучать Vulkan вместо OpenGL тем, кто сейчас занимается графическим программированием? Кажется, они будут служить той же цели.


1
Если вы можете сделать что-то в одном API, вы можете сделать это любым другим API, просто способ сделать это будет зависеть от API.
A --- B

Ответы:


33

Едва!

Это похоже на вопрос «Должны ли новые программисты изучать C ++ вместо C» или «Должны ли новые художники изучать цифровую живопись вместо физической».

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

Специализация редко является рыночным навыком.

Для тех, кому не нужно продавать свои навыки как таковые, например, для независимых разработчиков, было бы еще более глупо удалять инструмент из их набора инструментов. Инди-разработчик еще больше зависит от гибкости и способности выбирать то, что работает, а не то, что финансируется. Специализируясь на Vulkan только ограничивает ваши возможности.

Специализация редко является эффективной парадигмой.


2
Хороший ответ, напомнил мне об этом: elise.com/quotes/heinlein_-_specialization_is_for_insects
Уилл

7
Эта аналогия C ++ неуместна. Vulkan - это API нового поколения, разработанное создателями OpenGL. C ++ является признанным, в основном обратно совместимым конкурентом C.
Moby Disk

Эти особенности не имеют отношения к точке аналогии.
mHurley

6
Утверждать, что специализация неэффективна или не продается, невероятно наивно. Переводчик, который знает все пять слов на каждом разговорном языке, бесполезен, люди будут нанимать переводчиков, которые владеют (или специализируются на) небольшим количеством языков. Теперь над -specializing является проблематичным. Переводчик, который полностью освоил один язык и знает только этот язык, также не является полезным переводчиком. И разработчики (инди или иным образом) должны быть осторожны, чтобы не тратить все свое время на изучение новых инструментов. В конце концов им нужно что-то сделать, чтобы продать, чтобы не оказаться банкротом
8bittree

Просто чтобы прояснить, я не обязательно не согласен с вами в отношении OpenGL и Vulkan. Вполне возможно, это тот случай, когда изучение обоих, а не только Vulkan, является лучшим выбором.
8bittree

40

Если вы только начинаете и хотите работать с графическим процессором (в отличие от постоянного использования игрового движка, такого как Unity), вам определенно стоит начать изучать Vulkan. Возможно, вам стоит изучить GL и позже, но есть несколько причин, чтобы подумать о Вулкане.

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

  2. Гораздо проще перейти с Vulkan на GL или GLES, чем наоборот. Vulkan делает явным много вещей, которые были скрыты или непредсказуемы в GL, такие как управление параллелизмом, совместное использование и состояние рендеринга. Он продвигает большую сложность от драйвера к приложению, но, делая это, он дает управление приложению и упрощает получение предсказуемой производительности и совместимости между различными поставщиками графических процессоров. Если у вас есть какой-то код, который работает в Vulkan, его довольно просто перенести на GL или GLES, и вы получите что-то, что использует хорошие привычки GL / GLES. Если у вас есть код, который работает в GL или GLES, вам почти придется начинать заново, чтобы заставить его работать эффективно в Vulkan: особенно если он был написан в устаревшем стиле (см. Пункт 1).

Сначала я был обеспокоен тем, что с Vulkan гораздо сложнее программировать, и хотя опытным разработчикам в крупных компаниях это будет хорошо, это будет огромным барьером для инди-любителей и любителей. Я задал этот вопрос некоторым членам Рабочей группы, и они сказали, что у них есть некоторые данные от людей, с которыми они говорили, которые уже переехали в Вулкан. Эти люди варьируются от разработчиков в Epic, работающих над интеграцией UE4, до разработчиков игр-любителей. Их опыт заключался в том, что для начала работы (то есть, чтобы иметь один треугольник на экране) потребовалось изучить больше концепций и иметь более длинный шаблонный код, но это не было слишком сложно, даже для инди. Но после того, как они достигли этой стадии, они обнаружили, что гораздо проще создать реальное приложение для отправки, потому что (а) поведение намного более предсказуемо между реализациями разных производителей, и (б) получение чего-то, что хорошо работало со всеми включенными эффектами, не включало столько проб и ошибок. Благодаря опыту настоящих разработчиков они убедили меня в том, что программирование на Vulkan жизнеспособно даже для начинающего пользователя графики, и что общая сложность уменьшается, если вы пройдете обучение и начнете создавать демонстрации или приложения, которые вы можете дать другим людям.

Как уже говорили другие: GL доступен на многих платформах, WebGL - хороший механизм доставки, есть много существующего программного обеспечения, которое использует GL, и есть много работодателей, нанимающих для этого навыка. Это будет происходить в течение следующих нескольких лет, пока Вулкан набирает обороты и развивает экосистему. По этим причинам было бы глупо полностью исключить изучение GL. Несмотря на это, вам будет гораздо легче с этим справиться, и вы станете лучшим программистом GL (и вообще лучшим программистом на GPU), если вы начнете с того, что поможет вам понять GPU вместо понимания того, как они работают 20 лет спустя.

Конечно, есть еще один вариант. Я не знаю, относится ли это, в частности, к вам, но я все равно должен сказать это для других посетителей.

Чтобы быть разработчиком инди-игр, гейм-дизайнером или виртуальным опытом, вам не нужно изучать Vulkan или GL. Многие люди начинают работать с игровым движком (сейчас популярны Unity или UE4). Использование такого движка позволит вам сосредоточиться на опыте, который вы хотите создать, а не на технологии, стоящей за ним. Это скроет различия между GL и Vulkan от вас, и вам не нужно беспокоиться о том, что поддерживается на вашей платформе. Это позволит вам узнать о трехмерных координатах, преобразованиях, освещении и анимации, не имея дело со всеми мелкими деталями сразу. Некоторые игровые или виртуальные студии работают только в движке, и у них вообще нет штатного эксперта по GL. Даже в больших студиях, которые пишут свои собственные движки, люди, которые занимаются графическим программированием, составляют меньшинство,

Изучение деталей взаимодействия с графическим процессором, безусловно, является полезным навыком, который оценят многие работодатели, но вы не должны чувствовать, что должны изучать его, чтобы войти в 3D-программирование; и даже если вы это знаете, это не обязательно будет чем-то, что вы используете каждый день.


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

2
@RichieSams Я не думаю, что вы имели в виду "реализовать". Только поставщик графических процессоров должен внедрить Vulkan, и это намного проще, чем реализация OpenGL. (Поверьте мне, я сделал это!) Но, предполагая, что вы имели в виду, что трудно интегрироваться или программировать, я добавил параграф с некоторой информацией, которую я узнал от рабочей группы Vulkan.
Дэн Халм

Верный. Реализация, возможно, плохой выбор слов. Я имел в виду «использовать» в вашей программе. Но мне нравятся твои правки. Хорошо поставленный
RichieSams

@DanHulme - я удивлен вашим комментарием "GL призывает вас думать в стиле немедленного режима". Я думал, что это относится только к ранним версиям OpenGL?
ToolmakerSteve

1
@ToolmakerSteve Рабочая группа OpenGL проделала большую работу по добавлению параллельных и пакетных записей, так что вы можете выразить свою программу так, чтобы она подходила для реализации листов / отложенных реализаций. Но это все еще фундамент, который был заложен в эпоху немедленного режима, поэтому эти люди решили, что в Вулкане необходимо начать все заново. И я все еще вижу много новых пользователей, начинающих с GL и формирующих мысленную модель непосредственного режима работы реализаций.
Дэн Халм

26

Изучение графического программирования - это больше, чем просто изучение API. Речь идет об изучении, как работает графика. Преобразования вершин, модели освещения, методы теней, наложение текстур, отложенный рендеринг и так далее. Они абсолютно не связаны с API, который вы используете для их реализации.

Таким образом, вопрос заключается в следующем: вы хотите узнать, как использовать API? Или вы хотите изучать графику ?

Чтобы работать с графикой с аппаратным ускорением, вы должны научиться использовать API для доступа к этому оборудованию. Но как только вы получаете возможность взаимодействовать с системой, ваше обучение графике перестает фокусироваться на том, что API делает для вас, а вместо этого фокусируется на графических концепциях. Освещение, тени, рельефное отображение и т. Д.

Если ваша цель - изучить графические концепции, то время, которое вы тратите на API, - это время, которое вы не тратите на изучение графических концепций . Как скомпилировать шейдеры не имеет ничего общего с графикой. Также не известно, как отправлять им униформу, как загружать данные вершин в буферы и т. Д. Это инструменты и важные инструменты для работы с графикой.

Но на самом деле они не являются графическими концепциями. Они являются средством для достижения цели.

Это займет много работы и обучения с Vulkan, прежде чем вы сможете достичь точки, где вы готовы начать изучение графических концепций. Передача данных в шейдеры требует явного управления памятью и явной синхронизации доступа. И так далее.

В отличие от этого, достижение OpenGL требует меньше усилий. И да, я говорю о современном шейдерном профиле ядра OpenGL.

Просто сравните, что нужно сделать, чтобы сделать что-то простое, как очистка экрана. В Vulkan это требует, по крайней мере, некоторого понимания большого количества понятий: буферов команд, очередей устройств, объектов памяти, изображений и различных конструкций WSI.

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

Поскольку OpenGL многое скрывает от вас, вам нужно гораздо меньше усилий, чтобы добраться до точки, где вы фактически изучаете графику, а не изучать интерфейс с графическим оборудованием.

Кроме того, OpenGL является (относительно) безопасным API. Обычно выдает ошибки, когда вы делаете что-то не так. Вулкан нет. Хотя существуют слои отладки, которые вы можете использовать, чтобы помочь, ядро ​​Vulkan API почти ничего не скажет, если не возникнет аппаратная ошибка. Если вы делаете что-то не так, вы можете получить мусор рендеринга или сбой графического процессора.

В сочетании со сложностью Vulkan становится очень легко случайно сделать что-то не так. Забыть правильную разметку текстуры можно в одной реализации, но не в другой. Забывание точки синхронизации может иногда работать, но затем внезапно завершается неудачей, казалось бы, без причины. И так далее.


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

Графическое исполнение .

Чтобы быть программистом в области 3D-графики, обычно требуется некоторое представление о том, как оптимизировать ваш код. И именно здесь OpenGL скрывает информацию и делает что-то за вашей спиной.

Модель памяти OpenGL является синхронной. Реализация может выдавать команды асинхронно, пока пользователь не может определить разницу. Поэтому, если вы визуализируете какое-либо изображение, а затем попытаетесь прочитать его, реализация должна выдать явное событие синхронизации между этими двумя задачами.

Но чтобы достичь производительности в OpenGL, вы должны знать, что реализации делают это, чтобы избежать этого . Вы должны понять, где реализация тайно генерирует события синхронизации, а затем переписать свой код, чтобы избежать их в максимально возможной степени. Но сам API не делает это очевидным; Вы должны получить эти знания откуда-то.

С Vulkan ... вы тот, кто должен выпустить эти события синхронизации. Следовательно, вы должны знать, что оборудование не выполняет команды синхронно. Вы должны знать, когда вам нужно выпустить эти события, и поэтому вы должны знать, что они, вероятно, замедлят вашу программу. Поэтому вы делаете все возможное, чтобы избежать их.

Явный API, такой как Vulkan, заставляет вас принимать решения о производительности. И поэтому, если вы изучите API Vulkan, у вас уже есть хорошее представление о том, что будет медленно, а что быстро.

Если вам нужно выполнить какую-то работу с кадровым буфером, которая вынуждает вас создать новый проход визуализации ... велика вероятность, что это будет медленнее, чем если бы вы могли разместить его в отдельном подпроходе прохода рендеринга. Это не значит, что вы не можете этого сделать, но API заранее предупреждает вас, что это может вызвать проблемы с производительностью.

В OpenGL API в основном приглашает вас произвольно менять вложения фреймбуфера. Нет никаких указаний на то, какие изменения будут быстрыми или медленными.

Так что в этом случае изучение Vulkan поможет вам лучше узнать, как сделать графику быстрее. И это, безусловно, поможет вам снизить нагрузку на процессор.

Это все еще займет гораздо больше времени, прежде чем вы сможете добраться до точки, где вы можете изучить методы графического рендеринга.


1
Я рад, что вы опубликовали это, потому что это ясно дает понять некоторые идеи, которые я не решался выразить в своем ответе: что изучение концепций является наиболее важным. Я думаю, что в чем мы отличаемся, так это в том, что вы поощряете GL, потому что легче начать, в то время как я думаю, что легкость начала приносит риск сделать вещи традиционными способами. В GL довольно сложно понять, что такое «современная идиома GL», по сравнению с программированием в традиционном стиле. Если никто не советует вам использовать VAO вместо отдельного вызова для каждого примитива, то намного сложнее позже отучиться от этой ошибки.
Дэн Халм

1
@DanHulme: все дело в использовании правильных учебных материалов. Есть много таких материалов онлайн, которые используют современные идиомы. Никто не должен пытаться изучать графику, просто читая справочное руководство или спецификацию.
Николь Болас

Вы делаете это звучит действительно легко! Несмотря на это, я все еще вижу программистов, начинающих работать с графикой - некоторые из них очень компетентны в других областях - и используют устаревшие функции и ничего не изучают о характеристиках производительности. В Vulkan действительно сложно ошибиться, потому что дорогие вещи выглядят дорого. Во всяком случае, нам не нужно спорить. Я согласен с вашей основной идеей: изучение концепций является наиболее важным, и вы можете сделать это без Vulkan или GL.
Дэн Халм

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

2
@DanHulme: Что касается того, насколько легко использовать современный OpenGL, я делаю все возможное, чтобы упростить его . Если люди настаивают на том, чтобы учиться на мусорных сайтах, таких как NeHe, или читая случайную документацию, никто не сможет помочь. Вы можете привести лошадей к воде, но вы не можете заставить их пить.
Николь Болас

7

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


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

1
@DarioOO Непосредственный режим OpenGL намного проще в использовании, чем любой режим, который вы называете «не так быстро», но это не рекомендуется.
user253751

1
@Gavin: Следует отметить, что версии 4.2 OpenGL и выше также не поддерживаются в OSX. Так что если вы хотите использовать что-то недавнее из OpenGL на OSX, вы не можете. И Apple вряд ли примет более поздние версии OpenGL. Платформа Apple является олл-ин на Metal, поэтому кроссплатформенность в любом случае обанкротится.
Никол Болас

Apple никогда не поддержит Vulkan, пока их не заставят, и экономика этого довольно проста. Делая ставку на Metal, они надеются привлечь разработчиков мобильных игр, которым нужно больше, чем может предложить GLES2, но у них нет ресурсов для написания своих игр как для Vulkan, так и для Metal. Они готовы пожертвовать крошечной игровой экосистемой Mac для этого, особенно если разработчики iOS также выпустят в Mac App Store.
Джонатан Болдуин

Vulkan теперь работает на macOS (ранее OS X): moltengl.com
Александр,

4

Это зависит от того, что вы хотите сделать. Если вы хотите изучать графическое программирование только для себя, это не имеет значения, что вы выберете.

Если вы думаете о профессиональной деятельности, я рекомендую Vulkan. Это ближе к аппаратному обеспечению, и я думаю, что знание о том, что делает оборудование, важно для графических программистов.

Vulkan ближе к аппаратному обеспечению, потому что OpenGL делает много вещей под капотом, что в Vulkan вы делаете вручную, например выполнение очереди команд. Также управление памятью зависит от приложения, а не от драйвера. Вам нужно беспокоиться о выделении памяти uniforms(переменная, которую вы передаете из CPU в GPU), об отслеживании их. У вас есть больше поводов для беспокойства, но это также дает больше свободы при использовании памяти. Это может звучать страшно и подавляюще, но на самом деле это не так. Это только следующий API, который вы должны изучить.

Понимание этого также поможет понять, как работает GPU. Что позволит вам провести некоторую оптимизацию как на Vulkan, так и на OpenGL.

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


2

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

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

Другая проблема, с которой я столкнулся, связана с претензиями Vulkan о том, как он утверждает, что он лучше. Хотя OpenGL, конечно, не очень часто обновляет свой сайт. Они продолжают постоянно выпускать обновления, и я всегда с нетерпением жду новых обновлений, которые будут работать быстрее или лучше работать с новым оборудованием.

При этом, хотя я в основном работаю с OpenGL, я понимаю основные принципы DirectX и Vulkan. Хотя я не очень много с ними работаю, особенно с Vulkan, так как его очень трудно освоить и он не так хорошо структурирован для программирования, как OpenGl и DirectX.

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

Я не могу долго держаться за обновления OpenGL, и я не буду. Но это мое предпочтение развития.


« Другая проблема, с которой я сталкиваюсь, связана с заявлениями Вулкана о том, как он утверждает, что он лучше». Вулкан не претендует на то, чтобы быть чем-то. Это просто API; он не может предъявлять претензии.
Никол Болас

Вы понимаете, что Vulkan и GL сделаны в основном одними и теми же людьми?
Дэн Халм

Да. Я все еще предпочитаю GL
Winter Roberts

2

Я хотел бы дать вам мой взгляд начинающего графика на эту тему. Что я понял (много лет работая инженером в другой области), так это то, что фундаментальные понятия являются наиболее важной частью. Когда у вас есть четкое представление о них, изучение последнего блестящего нового API является наименее сложной частью. Я не знаю, являетесь ли вы молодым хобби, пытающимся запрограммировать новый Skyrim или ищете работу в области компьютерной графики.

Я говорю вам , что я думаю , что это лучший подход , на мой взгляд , чтобы узнать компьютерную графику «как профессионал».

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

Начать беспокоиться о производительности, прежде чем понимать, как провести черту, - все равно, что беспокоиться об аэродинамике вашего автомобиля до получения водительских прав.


0

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

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

Если мы абстрагируемся от этого аспекта программирования и сосредоточимся только на понятии, какие методы используются, включая различные уровни математики, ведущие к наборам данных, структурам данных и алгоритмам; Есть много вещей, которые вы должны знать и понимать в первую очередь, прежде чем вы сможете даже попытаться создать 3D игровой движок или эффективно использовать существующий.

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

Исходя из моего собственного понимания и того, как я это вижу, это так, если вы хотите построить быструю игру только ради создания игры; пойти с уже существующими рамными работами, которые сделают ваше производственное время намного меньшим. С другой стороны, если вы хотите понять, как устроены игровые / физические движки / анимационные двигатели и симуляторы, и хотите создать их самостоятельно, тогда у вас есть выбор между выбором API, например DirectX, OpenGL или Vulkan. Одним из определяющих факторов здесь также будут ваши существующие знания в области программирования. Под этим я подразумеваю, что если вы ничего не знаете о многопоточности, синхронных и асинхронных вызовах, выделениях памяти, гонках данных, семафорах и параллелизме (параллельное программирование),

Я упоминаю об этом, потому что, если вы не знаете, как правильно управлять своей памятью, потоками и временем доступа; Вулкан укусит тебя в задницу! Где OpenGL и DirectX будут держать вас всю руку, потребляя гораздо больше ресурсов процессора.

Теперь, если ваш уровень знаний в области программирования является приличным, и у вас есть следующие математические знания, которые включают все уровни алгебры, геометрии, тригонометрии, булевой алгебры, вероятности, статистики, алгебры на основе векторной матрицы, исчисления I, II, .... Infinty (смеется). Векторное исчисление, линейная алгебра, системы линейных уравнений, аналитическая геометрия с векторным исчислением многопараметрических вычислений, теория чисел и множеств, наборы данных и структуры, вычислительный анализ, вычислительный и алгоритмический дизайн. Затем вы можете получить представление о том, что нужно для создания реального игрового движка, и это без какой-либо прикладной математики или каких-либо физических уравнений, которые вам понадобятся. Как только у вас появится этот опыт и достаточно опыта программирования, особенно управления памятью и арифметики указателей, вы можете приступить к созданию игрового движка.

Итак, дело в том, что вы должны понимать все аспекты того, что нужно для создания игрового движка, чтобы заниматься продвинутым графическим программированием. Если вы делаете только 2D-графику, то жизнь не так уж сложна, как вы можете сделать это в Python без какого-либо из вышеупомянутых API! Но если вы хотите быть серьезным и разработать полноценный мощный движок Game Engine, который будет иметь множество наборов функций, тогда вам следует выбрать C или C ++ и использовать OpenGL, Direct X или Vulkan. Любой из них был бы просто в порядке. Теперь, если вы собираете движок с нуля и ищете наиболее «эффективный» работающий движок с наименьшими затратами ресурсов, вам следует выбрать Vulkan. Но если вы пойдете по этому пути, вы должны хотя бы знать все, что я упомянул выше, и некоторые!

Итак, как вы можете видеть, Vulkan на самом деле не ориентирован на начинающих программистов в этой области. Вы должны обладать обширными знаниями по всей математике, парадигмам программирования, всем различным наборам данных и алгоритмам, включая многопоточность, синхронизацию памяти, параллельное программирование. И даже в этом случае приложение просто загружает простой 2D-треугольник на экран. То, что можно сделать с помощью примерно 100 строк кода в OpenGL или 250 строк кода в DirectX, занимает почти 1000 строк кода в Vulkan!

Vulkan оставляет все на ваше усмотрение, поскольку вы несете ответственность за все аспекты использования Vulkan в своем приложении. Там нет руки, которая мешает вам, она позволит вам застрелиться в ноге или повесится, купите рекурсивную петлю!

Нельзя сказать, что новички или новички в этой области не должны изучать Vulkan, но я бы посоветовал им следующее: во-первых, изучите достаточно OpenGL и DirectX, чтобы вымокли, чтобы понять, как Основное приложение структурировано только для рендеринга простого треугольника или вращающегося куба. Познакомьтесь с их API и повторяющимися шаблонами их структур. Узнав, что вы можете изучать Vulkan на параллельной стороне, таким образом, вы можете увидеть, как каждый из трех выполняет одну и ту же задачу, но знать, как они делают это по-разному, тогда вы также можете сравнить результаты между различными API и из там вы можете сделать выбор, который предпочтительнее для вас. Этот метод также даст вам еще один инструмент в вашем наборе инструментов, и вы даже можете написать свое приложение для поддержки всех 3 и иметь "

В конце концов, все зависит от того, какой человек выберет маршрут, по которому он хочет идти, и оттуда его успех будет определяться их преданностью, постоянным обучением, тяжелой работой, пробами и ошибками и, что наиболее важно, их неудачами. Если вы не провалились, значит, вы не успешны! Вы добились успеха только в том случае, если вы потерпели неудачу, нашли свои ошибки, исправили их, пошли дальше, вернулись и сделали все заново!


-1

Сначала вы должны изучить OpenGL, так как это стандарт для графики на многих платформах.

Даже если есть более новая библиотека, понимание основ и работа с языком, который используется во всей отрасли, очень важна ... Тем более, что с тех пор Vulkan не будет использоваться в больших компаниях некоторое время.

  1. Никто не хочет сразу приспосабливаться и заканчивать тем, что отказывается от нестабильной среды Framework / Library.

  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! Framework (также 1.x к 2.x). Полные изменения в структуре, что означает, что мы должны переучиваться ... все ...


По сути, вам следует подождать, пока Vulkan не станет СТАБИЛЬНЫМ. Это означает, что нужно подождать до версии 2.0. Это не означает, что вы не можете узнать об основах Vulkan, но просто знайте, что это может измениться. Я бы предположил, что такая группа, как Kronos, с самого начала предоставила бы очень стабильный API, тем более что над Vulkan работают несколько инженеров Nvidia и AMD, включая высокопоставленного сотрудника Nvidia, который, очевидно, наблюдает за проектом, а также The Base of Mantle; однако, как и любое программное обеспечение, мы, программисты, увидим, насколько хорошо оно работает с самого начала, но многие настороженно ждут, чтобы увидеть, что произойдет.


Вулкан сейчас стабилен. Ваша аналогия GL 1.0 против 2.0 подходит. Начать с GL сейчас было бы все равно, что начать изучать GL 1.0 через шесть месяцев после выхода GL 2.0.
Дэн Халм

1
Vulkan может быть «стабильным», это не значит, что ничего не изменится, такова природа языков, о которых я представил два последних изменения в языках за последние несколько лет, так как же мы узнаем, что это не произойдет с Vulkan? Вы в основном говорите, что изучение OpenGL - пустая трата времени, и это неверно. Похоже, что OpenGL мертва и больше не будет использоваться ... Также ложно. Кроме того, я не единственный, кто считает, что у Вулкана могут быть проблемы со стабильностью. Возможно, нет, но с любым новым языком, это то, что вы ищете.
XaolingBao

1
Конечно, все изменится, и рабочая группа уже работает над новыми функциями для следующей версии спецификации (ssh, вы от меня этого не слышали). Стабильный означает, что эти вещи добавят в спецификацию, и то, что вы узнаете об этом сегодня, все равно будет действовать через два года. OTOH, вещи, которые вы узнаете о GL сегодня, уже плохо соответствуют тому, как работают графические процессоры: так же, как изучение конвейеров с фиксированными функциями в мире программируемых шейдеров. Если вы прочитаете мой ответ, то увидите, что я не думаю, что изучение GL сейчас - пустая трата времени. Но «Vulkan слишком нов» не является хорошей причиной, чтобы сбрасывать со счетов это.
Дэн Халм

1
@Lasagna: « Дело в том, что это может быть изменено, не многие компании сразу адаптируются к его использованию », Valve. Эпическая. Единство. Все они вкладывают значительные средства в работу своих двигателей на Вулкане. CryTech и Id точно не игнорируют это. Таким образом, ваше заявление не соответствует фактам.
Никол Болас

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