Right now Google Analytics is loaded but there is no tracking code configured! Not the biggest fan of trackers but definitely would want that configured if my post would be on the HN front page.
While the final rendering code for visualizations may look very differently from game rendering code, the underlying techniques are exactly the same unless you are doing some really hard out of core stuff or something else that is really extreme. So I do not see the point for separate resources, to be honest. Visualization is much more about the pipeline that you execute before you start rendering.
Visualisation usually has much much smaller scope than game development. So frequent vs infrequent developer problems apply here, as in https://news.ycombinator.com/item?id=16561901
Any new concept or tool dependency, e.g. 3D editor or shader, is a pain point here since it increases project compexity superlinearly.
Also, many "game engines" which aim to speed up development impose a lot of constraints on client code. For example, they're not compatible with non-GL windows from same process or with external event loop. I made a mistake trying to use a few of those and impedance mismatch was really painful. Had to divest to plain OpenGL.
Realtime rendering is independent from game engine implementations and especially from content creation pipelines. If you are looking at resources that explain how to use game engines then you're looking in the wrong place. What you want is resources that teach how to write rendering code.
I mean, yeah. If you try to use a framework intended for games, it won't be a great fit for other use cases. Look into Open Scene Graph if you want a higher level API that isn't as opinionated towards games.
Vulkan isn't a higher level API though, which might be why you and the other guy are kind of talking past each other.
As I have been explained, Monogame is not even a game engine, rather a framework for writing game engines.
That's a particularly poor fit for 3D visualisation. No primitives, expectations of bringing your own shaders, inability to work with Forms in the same process...
Why would you want that exactly rather than CUDA or OpenCL?
Although I haven't written a compute shader yet, compute in Vulkan looks trivial to use once you have waged your initial battles against the rendering pipeline setup. Most of the complexity with Vulkan lies in understanding descriptor sets, pipeline layouts and pipeline objects. I find that the Vulkan interface is remarkably consistent once you get over the initial - and substantial - hurdles.
It is unclear to me whether the target of the statement is runtime interop between OpenCL and Vulkan or something else, like implementing (a subset of) OpenCL on top of Vulkan. I have not seen statements recently from Khronos that would hint at the later.
>The OpenCL working group has taken the decision to converge its roadmap with Vulkan, and use Vulkan as the basis for the next generation of explicit compute APIs – this also provides the opportunity for the OpenCL roadmap to merge graphics and compute.
From the article suggests at some point OpenCL is going to run on top of Vulkan.
Because Vulkan is cross-device, cross-platform. I dont want to tied to the Desktop or to Nvidia.
Vulkan Compute shaders work in recent Android devices and on every Windows/Linux PC that has a <5 year old dedicated GPU. And for iOS/OSX there is an interop layer in the works that will enable Vulkan over Metal.
Well the author did say “if you have a different vision, or opinion, about what Learn Vulkan should be, don't hesitate to contact me as nothing is set in stone yet”, and while I think that may have been primarily about the book/website combo I think now is a perfect time for you to contact the author (contact details on the page) and ask them about including Vulcan compute on the site.
Vulkan compute is super simple compared to vulkan graphics. In the graphics you have to consider renderpasses, tons of GPU state, and whatnot.
In compute you just dispatch kernels and put barriers to prevent race conditions. Pretty much like OpenCL Out Of Order queues except the arguments are passed via descriptor sets rather than given individually.
The author's earlier project, learnopengl.com, helped me catch up to modern OpenGL after having been away from OpenGL since shortly after it became Open. (I learned iris GL first.) Looking forward to the Vulkan version.
Well, I just bought OpenGL SuperBible and was eventually going to go about making a simple game engine from scratch and learn the linear algebra required for graphics engines.
Would anyone still suggest learning OpenGL/building a graphics pipeline or just proceeding on to Kronos's Vulkan?
+1, if you really care about learning just the math OpenGL is a lot simpler from an API perspective. Once you start caring about performance then dig into Vulkan to understand the various render commands/pipelines/etc.
I would also assume that OpenGL is better supported on multiple platforms, by virtue of having been around much longer. You'll also be able to get more help if you run into issues with OpenGL.
OpenGL is still very relevant, and it works on more hardware than Vulkan. You can get very good performance out of OpenGL if you try to follow AZDO practices, and it'll be good practice, should you later decide to learn Vulkan.
38 comments
[ 3.0 ms ] story [ 67.4 ms ] threadIn my experience it is a pain point.
Any new concept or tool dependency, e.g. 3D editor or shader, is a pain point here since it increases project compexity superlinearly.
Also, many "game engines" which aim to speed up development impose a lot of constraints on client code. For example, they're not compatible with non-GL windows from same process or with external event loop. I made a mistake trying to use a few of those and impedance mismatch was really painful. Had to divest to plain OpenGL.
Realtime rendering is independent from game engine implementations and especially from content creation pipelines. If you are looking at resources that explain how to use game engines then you're looking in the wrong place. What you want is resources that teach how to write rendering code.
Vulkan isn't a higher level API though, which might be why you and the other guy are kind of talking past each other.
I've been playing with Monogame (used to be Microsoft's XNA) lately, which is cross-platform and very easy to get up and running with.
That's a particularly poor fit for 3D visualisation. No primitives, expectations of bringing your own shaders, inability to work with Forms in the same process...
I want Vulkan compute.
Although I haven't written a compute shader yet, compute in Vulkan looks trivial to use once you have waged your initial battles against the rendering pipeline setup. Most of the complexity with Vulkan lies in understanding descriptor sets, pipeline layouts and pipeline objects. I find that the Vulkan interface is remarkably consistent once you get over the initial - and substantial - hurdles.
From the article suggests at some point OpenCL is going to run on top of Vulkan.
Vulkan Compute shaders work in recent Android devices and on every Windows/Linux PC that has a <5 year old dedicated GPU. And for iOS/OSX there is an interop layer in the works that will enable Vulkan over Metal.
Actually no.
Vulkan is an optional API, so unless we are talking about Samsung and Google flagships phones, there is no guarantee of it being available.
So far Google hasn't even bothered to add it to the dashboards.
For compute, only Renderscript is required.
In compute you just dispatch kernels and put barriers to prevent race conditions. Pretty much like OpenCL Out Of Order queues except the arguments are passed via descriptor sets rather than given individually.
Would anyone still suggest learning OpenGL/building a graphics pipeline or just proceeding on to Kronos's Vulkan?