Comments 14
Я так-то читал на сайте Kronos, что OpenGL они рекомендуют для игр, а Vulkan - просто для графики. Лично мне OpenGL нравится по той причине, что в нём всё просто, можно легко написать сразу свой рендеринг, не мудохаться с девайсами, swapchain'ами, расширениями и другим setup'ом
Я так-то читал на сайте Kronos, что OpenGL они рекомендуют для игр, а Vulkan - просто для графики.
А как давно это было?
Vulkan - он для всего. Да, он сложнее в разы, но OpenGL 3.x и выше, не смотря на попытку адаптации к современному оборудованию, будущего уже не имеет, хотя бы из-за своих проблем с многопоточностью.
А статья-то как раз про то, что писать портянки кода и непосредственно взаимодействовать с Vulkan в приложениях не надо - есть VulkanSceneGraph, который дает объектно-ориентированную обертку над вызовами базового API.
К тому же, как пишет комментатор ниже, и Vulkan в ближайшей перспективе могут подвинуть
Он не "сложнее в разы", он многословнее. Написание кода представляет из себя восход и закат солнца вручную. По сложности же там ничего особо нового по сравнению с последним OpenGL нет.
Написание кода представляет из себя восход и закат солнца вручную
В общем-то да. Я старательно воcпроизвел пример рисования треугольника в современном OpenGL и Vulkan - второе напоминало именно то, о чем вы говорите ). Каждую кнопку нажать и каждый рычаг нужно дернуть самостоятельно, с многочисленными проверками.
Если говорить о сложности, то я мог употребить не верный термин, но имел как раз больший объем кода. Но, обращу всё же внимание на то, что Vulkan изначально спроектирован под работу в многоядерных системах, с чем у OpenGL на стороне ЦП - проблемы. Так что утверждение "ничего особо нового" наверное в данном контексте довольно спорный
А как давно это было?
Вообще в 2021-ом, но это там и сейчас написано https://vulkan-tutorial.com/
The takeaway message here is that Vulkan is not for everyone. It is targeted at programmers who are enthusiastic about high performance computer graphics, and are willing to put some work in. If you are more interested in game development, rather than computer graphics, then you may wish to stick to OpenGL or Direct3D, which will not be deprecated in favor of Vulkan anytime soon. Another alternative is to use an engine like Unreal Engine or Unity, which will be able to use Vulkan while exposing a much higher level API to you.
Стандарту, я как понимаю всего меньше месяца, но насколько я понял - оборудование уже начинает поддерживать его. Пока могу сказать лишь спасибо, что обратили на этот факт мое внимание, вынужден пока воздержаться от комментарием, до тех пор пока не изучу вопрос более подробно
Итак, прошу прощения, утром я прочел вашу ссылку по диагонали и не понял о чем идет речь. А речь идет не о новом API уровня аппаратуры, а об объектном интерфейсе к OpenGL, так как в зависимостях имеется только он, Vulkan там нет.
Под mingw у меня не собралась ни ветка 0.7.1, ни next_release, ни main. Под линуком не пробовал, но попробую. Но, что могу сказать, взглянув на исходники:
1. OpenGL. На перспективу я всё же ставил бы на Vulkan - Роберт Осфилд убедил меня достаточно аргументирвано
2. Динамическая компоновка, много зависимостей, в том числе и от GLFW. Против статической компоновки в VSG и собственной оконной системе, статической компоновке компилятора GLSL, математике, при существенно меньшем объеме кода
Это выводы сделанные вот сейчас, навскидку. Дальше посмотрю еще, мне интересно. Но опять таки, исходя из своего понимания вопроса я ставлю на Vulkan
Спасибо, очень завлекательно. Полез тут было дело вулкан изучать, и как-то быстро скис. А с этим его уже можно будет попробовать в относительно гуманных условиях...
Такой вопрос. Вы не подскажите, как к этому безобразию прикрутить imgui https://github.com/ocornut/imgui ??? У меня сейчас что-то типа тестовой лаборатории для будущей игрушки, там многими вещами удобно рулить через GUI, поэтому imgui активно юзается. В игре её разумеется не будет. Рендерится всё через OpenGL. Хочется попробовать переписать всё это на vsg, тем более кода собственно рендеринга там очень мало.
Прошу прощения, но с примером вообще ничего не понял. Там всё свалено в кучу в файле *.vsgt, и модель, и шейдеры и какие-то элементы конвейера... Да, библиотека потом как-то с этим расправляется. Но боюсь написать такой файл ручками, будет не проще чем сделать все необходимые шаги на сыром вулкане. Я не прав ???
Кроме vsgt есть поддержка того же glTF и прочих форматов, которые экспортируются из 3D-редакторов.
боюсь написать такой файл ручками, будет не проще чем сделать все необходимые шаги на сыром вулкане
Вы правы, более того - штатного ковертера в vsgt из 3D-редакторов нет. Я задал этот вопрос Роберту, и вот что он ответил
Modelling tools export a range of different formats and assimp supports a range of formats so it's a case of finding out what combination of supported formats works best for you. Potentially one can write plugins for Modellers to export to native VSG formats, but this isn't something I'm personally planning on tackling.
Converting to native VSG formats may not be necessary, it all depends on the requirements of your application.
Да, столько всего сделал в свое время на OSG..... рад что Роберт и проект развивается
VulkanSceneGraph: Введение в графическую библиотеку