The advice to not learn Vulkan first is actually pretty good, because it aligns with most people's goals when learning. Most people want to get some graphics on the screen and maybe understand what a shader is, how meshes are represented etc. OpenGL has less friction here, and I'd argue that you can learn a lot of this starting in a higher level environment like Unity, writing your own shaders and creating procedural meshes. This advice comes from the same place as "if you want to make a game don't write your own engine", which is probably works for most people.
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'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.
Graphics programming in general has a pretty steep learning curve in the beginning compared to other fields of programming.
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.
Yes, OpenGL is pretty low level too. It may be better to start with a high level library or framework, you can still drop down to writing shaders, octrees or tessellators
or whatever for experiments.
Well, you can ignore all that and use glBegin, glEnd, glColor, glRotate, glTranslate and all that stuff. If you are ok with having OpenGL manage your resources and GPU memory, you should also be ok with having OpenGL manage your vertex buffers and vertex attributes too.
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.
Is there a serious MOOC that gets into this? I'd like some academic rigour rather than some kid on YouTube. I tried the Unity route and had issues with shaders. Trying to get into GPU programming.
It's relatively easy in Unity to get OpenGL going.
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).
Thank you. The OpenGL calls you refer to .. is there a C# binding that is easy to setup with Unity? I tried OpenGL in a computer graphics undergrad course (sadly, one I dropped) and it was a crazy amount of C/C++ libraries and header files (along with esoteric things like GLUT, etc.). I didn't realize I could do OpenGL within a Unity/C# context.
What issues did you have with shaders? Unity doesn't always make documentation easy to browse, especially when it comes to shaders, but outside of shadertoy its one of the best environments to just start writing shader code with limited setup. If you don't understand Unity (like what a game object or component or material is) it will be challenging to drive into writing shader code first though. There is a MOOC on Udacity that is introductory, but could be good for you if you are a beginner. A lot of the deep information about graphics is in vendor documentation and GDC or siggraph presentations. Some of it is in blogs or books.
If by GPU programming you're thinking more compute focused than graphics, reading Nvidia's CUDA documentation and tutorials could be a good start.
I tried courses a few years back, but what actually helped me get into OpenGL (I started with ES2 because it was compatible with every device I owned) was to find an existing OpenGL ES 2.0 program which compiled and ran on my computer, and tinker with that week after week. I think I have a pretty good grasp now of shading and how to take good advantage of the pipeline stages.
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.
Unity! Incredibly satisfying for such a minimal learning curve. I'm currently learning WebGL/OpenGL from scratch - which is rewarding, but in the same time it took me to get a few perspectively-rendered triangles on the screen I made a weird "puppy simulator" in Unity (https://unity3d.com/) for my nephew and niece that they spent hours playing with. They had far less interest in my triangles.
Mobile game revenue just surpassed desktop (and it's been on that trajectory for several years now).
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).
Well, two things. Firstly a generic indie hoping to get a slice of that giant mobile pie of cash is most likely going to end up very disappointed.
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.
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.
* OpenGL is a dealbreaker since modern things in it (compute etc.) don't work on iOS/Mac; and elsewhere has a lot of driver stability problems. Does not work on any consoles.
* 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.
The Vulkan equivalent of WINE really isn't the right solution IMO -- especially given that it means relying on closed source third party software with a non-zero monetary cost.
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.