Beginner-Friendly Vulkan Tutorials
stephaniehurlburt.com
stephaniehurlburt.com
Vulkan is great as a beginner if you want deep understanding of the graphics pipeline and are ok with some pain and confusion and a lot of "boilerplate", which comes from Vulkan having few defaults. Its a good representation of how game engines tend to use graphics APIs vs toy applications, academic projects and indie games you might see as smaller scale examples. As a beginner and a hobbyist you probably don't need Vulkan or DX12 for anything you'll build and you'll quickly be exposed to a lot of concepts you won't really understand, but I think sticking with it will give you a level of understanding much deeper than someone that dabbles with OpenGL.
I suspect Vulkan will require the same sort of effort. I bought the Programming Guide in the first preorder campaign, but I think the way I will learn Vulkan is by transplanting my pet ES2 projects into an existing Vulkan skeleton.
If by GPU programming you're thinking more compute focused than graphics, reading Nvidia's CUDA documentation and tutorials could be a good start.
For 3d Objects: 1. Create a mesh. There are a lot of tutorials/free asset store helper classes that can show you how to do this, alternatively just copy the mesh out of an instanced object 2. Assign a pre-made shader to it 3. Render it with OpenGL, e.g. GL.DrawMesh/Instanced
For general starter OpenGL you can just make calls using GL.Begin etc.
The nice thing about doing this is that things like lighting, shaders, OpenGL state switching/machine etc. are already taken care of for you (and those little things can take a long time to figure out if you're new).
Even with simpler OpenGL it's not so easy. You need to have quite a bit of knowledge before you even get your first triangle (hello world of graphics programming). Context creation, extension loading, buffer objects, matrices, shader writing and compiling. Even with frameworks to help you, it's much more complex than your usual hello world.
It also makes it easier to transition from "use red color for a rotated triangle" to "use this shader that uses the red color i asked for a rotated triangle" to "use this shader that uses this vertex attribute (that happens to be a color) and this global (that happens to be a transformation matrix)".
The only issue with this approach is that "officially" that stuff is deprecated but at least in practice Nvidia has said that they're not planning on ever removing that functionality and it also seems to be the case with AMD's own OpenGL implementation. The only issue is with the Linux drivers that depend on Mesa (and i hope this is a temporary roadblock), like the open source AMD drivers, and with Apple's OpenGL implementation. But even then this would only be an issue when you want to start using the more advanced stuff (since you can still use the older API in both Mesa and Apple, it is just that you cannot mix it with the newer calls), at which point you'd probably be ready to switch to Vulkan anyway.
I've never thought this, in fact I find the OpenGL API makes things harder to understand because of it's basically massive hidden state machine that it has going on. For beginners I agree to recommend using Unity/Unreal to understand all the stages of a game engine, as there is just so many layers these days.
Actually using Vulkan is something that comes much later, as a side project to learn how it works, or when you're in a company which has the resources to build it's own engine.
I wish there were more beginner-friendly tutorials of Vulkan compute.
If I'm not mistaken, only 2 out of the 7 tutorials listed cover compute.
That is a misconception, game consoles never fully supported OpenGL.
The PS3 was the exception with Open GL ES 1.0 + NVidias Cg for shaders, most developers just cared about Sony's own APIs anyway.
What they have are APIs, that to certain extent follow OpenGL concepts.
I mean I studied CS and had computer graphic classes, but this was mostly theory and clicking around in Maya.
What does it take?
I always find myself fiddling around with numbers for hours. Primitives, sizes, positions, transformations and it looks shitty in the end.
How do 3D people start a new project and focus on stuff that matters to get good results fast?
Vulkan means your users HAVE to run Android -- specifically, Android N (often they do not because of things like slow-moving carrier controlled OS updates).
iOS is not supported.
Secondly, the majority of games on mobile does not need Vulkan performance. Sure, extra performance is always great, but the majority of big sellers are your generic run of the mill 2d games.
But having said that, either way I really dislike the in-fighting between the companies, each trying to get their own API/vision to the top of the pile (The same is happening with VR etc). At the end of the day they're just damaging their own ecosystems.
How is this a different situation than with desktop or console? What in particular about mobile makes it worse for the indie developer?
For one thing, I contend that you have FAR more eyeballs in front of mobile screens than desktop or console.
"Secondly, the majority of games on mobile does not need Vulkan performance."
The majority of apps on mobile don't need Vulkan, but the ones that do CAN benefit from it (e.g. mobile VR is SO sensitive to framerate).
The problem with mobile is that you have more eyeballs, but less investment. The price of mobile games (if bought) are ridiculously low compared to PC/console. As a result, go and look at the top sellers in the mobile market. The big winners are all the f2p games that can sell in-app purchases to whales, netting them a lot of money.
Your average developer (because of the giant size of the store) gets sidelined by the store with no exposure, because the store doesn't believe he'll make any money...and as a result he doesn't because no one discovers his game.
If you look at a graph of sales its heavily skewed to the front/top where they're making all the money, then there's a rapid drop in profitability. The guys on the bottom consider themselves lucky if they can recoup even the cost to use the store.
This of course isn't true for all indies, there are many that are successful (and once you are you can continue based on people knowing your previous games). Sadly in general though odds are much better for you on desktop.
https://www.netmarketshare.com/operating-system-market-share...
* Metal is a dealbreaker since it does not work anywhere that's _not_ Apple.
* Vulkan is a dealbreaker since it only works on Android (mobile) or requires fairly new drivers/GPU (PC). Does not work on consoles.
* Direct3D 11 is a dealbreaker since it does not exist outside Microsoft platforms, and does not have some modern stuff (async compute etc.).
* Direct3D 12 is a dealbreaker since it does not exist outside Microsoft platforms; and on PC requires Win10.
See a common pattern? All of them can be considered "dealbreakers" for one or another reason. The (perhaps sad) reality today is, that you can't cover "all platforms" with a single graphics API.
Not that it's a big issue though... making a renderer/engine that works on more than one graphics API is not that big of a deal, compared to challenges everywhere else in game development.