Hacker News new | comments | show | ask | jobs | submit login
Beginner-Friendly Vulkan Tutorials (stephaniehurlburt.com)
171 points by ingve 128 days ago | hide | past | web | 35 comments | favorite



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.


> OpenGL has less friction here

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.


On the old days OpenInventor was a good introduction to OpenGL, nowadays maybe something like three.js or babylon.js. Just to get the hang of it.


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.


Start with WebGL? The concepts are the same.

http://webglfundamentals.com


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.


For those looking for something similar with Rust: http://vulkano.rs


Or, you know, look at the third tutorial in the list.


Ha. I read the intro piece, not the tutorial links...


It saddens me that so many people focus on the graphics aspect of Vulkan.

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.


Vulkan seemes to be caught in a bad situation since it's not usable on Mac or iOS. With OpenGL at least all major platforms where covered.


Hardly. Apple's drivers are notorious for their... "idiosyncrasies." Not to mention that at best, you can expect 4.1 support.


> With OpenGL at least all major platforms where covered.

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.


OpenGL was also universally very buggy so most applications opted to use DirectX on Windows even though OpenGL was available.


MoltenVK apparently fixes this.


Apple's choice, since they try to push metal and related instead.


How do you get started with 3D in general?

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?


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.


Vulkan is great except it doesn't work on anything Apple. Dealbreaker if you want users.


Not if you're making desktop games, where the vast majority of the users are on Windows.


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).

iOS is not supported.


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.


"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."

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).


Sorry for the late reply.

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.


It's not that hard to abstract the Vulkan details away and implement a Metal backend for Apple. Metal is actually less low level.



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.





Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: