Ray Tracer Sandbox in Vulkan
github.com
github.com
It still blows my mind that Mandelbrot fractals (and now ray tracing) that would take 10s of minutes to render at 640x480 on my first computer, now render at 60fps on a 4k display with real-time panning/zooming.
But is also amazing raytrace algorithms improved over time. So both hardware and software make real-time raytracing possible.
A very nice 'guide' for papers that make software improvements possible is the YouTube channel 2 minute papers.
Counting the lines of a renderer I have lying around it's 300 lines (including much whitespace). That's very full functioned, it correctly positions the window in the center of the monitor, handles errors properly, takes mouse and keyboard input, sets up the view/projection matrices, uses shaders, etc.
https://github.com/jleahy/gldemo
That's a full OpenGL setup, with all the fiddly bits taken care of. Obviously it's a bit over the top (you don't need vertex buffer region management for one triangle), you don't need SIMD matmul, but that's the maximum.
You could port that to any language with OpenGL bindings.
Generally I'd also say stick with 3.x (rather than 4.x) unless you need tesselation shaders.
Back in January, I discovered this really cool .NET Standard 2.0 library for abstracting Direct3D 11, Vulkan, Metal, OpenGL 3, and OpenGL ES 3 called Veldrid: https://github.com/mellinoe/veldrid
The documentation is pretty good, for its own parts, and it has a fair number of examples for setting up things like different windowing libraries. I was able to put together a set of code for a single demo running in Windows Forms, WPF, and Xamarin Forms fairly easily. It also has support for SDL2.
Currently, I'm going through a Codevember exercise where I teach myself WebGL from scratch.
From what I've learned so far, most of the graphics APIs these days work in very similar ways. And Veldrid polishes over the few differences (esp. in the case of OpenGL). WebGL does, too, in that they present an OpenGL front-end, but the back-end can be implemented in different graphics APIs (for example, on Windows it's actually implemented in D3D 11 through ANGLE).
In general, you need to create a Shader Program--which is a combination of multipe Shaders of different types, e.g. Vertex, Compute, and Fragment--construct one or more Buffers to which you will load data (generally in a big, ol' smash of data), and configure how ranges within those Buffers will map to pointer locations within your Shader Program.
However, I've generally found that there is little documentation anywhere on how to architect a data pipeline to use all of the various GPU resources efficiently. Everyone talks about "use as few draw calls as possible". But they don't really tell you how to achieve that.
My feeling is that a Shader Program is loosely analogous to a Material in something like Three.js or Unity. I'm guessing that the ideal approach is to take all of the Meshes in Three.js, or all of the Renderers in Unity, that have all of the same Materials, and then combining their Geometries into a single block of memory. And that's where Uber Shaders come in, as an attempt to also combine all of the different ways in which you'd want to render different Materials into a single Shader Program.
You should also be careful of monolithic Uber shaders especially if they branch as shader divergence can really kill gpu performance on some hardware. There is no one solution, just the one that best fits your usecase, hardware and coding time budget.
But with dynamic content loading over the 'net and teleconferencing and corporate authentication and general Unity update fuckery, it just got to be too much to manage. A lot of my users can't have Facebook accounts, so I need to support as many other headsets as possible, and Unity's tooling for that is way too constantly-in-an-ever-shifting-landscape-of-broken.
With OpenXR starting to really take off, and upcoming .NET 5 promising much more robust multiplatform support, I might be able to go back to .NET with Veldrid. Though I'd still have the teleconferencing and authentication bits being a lot harder to pull off outside of the browser, and having a native app would mean we would have to deploy through the Oculus store, which I definitely don't want to do.
My goal is to have a framework where I can experiment with different parts of OpenGL by sub-classing something and then override a method or two, and have it "just work" with everything else in the framework (shaders, viewers, animation, user interaction, etc.)
https://github.com/Zielon/PBRVulkan/blob/master/PBRVulkan/Ra...
This is the code
for each command list
upload vertex data
upload index data
set scissor
bind texture
draw
Because it's an example and because so many unexperienced programmers use it they assume it's some official part of the library. It's not.
> Moving backends code from examples/ to backends/… 24 days ago
One of the main reasons/goals/points of Dear ImGUI is being able to ingrate it into existing projects. It's deliberately API agnostic. It generates a very simple command list that you can then trivially render yourself in your own engine.
Everything else, all the platform specific code in the repo is entirely there to help people understand how to use it or to get started.
It's a mistake to think otherwise because it incorrectly limits Dear ImGUI's perceived usefulness. If you believe you have to take a backend or use one of the APIs provided then you'll mistakingly believe it would be hard to put in your existing game. If you understand what it's really about then it's trivial to put it in almost anything. That is by design.
I think it's a bit of both. From the point of view of game programmers and custom engine users/creators, it's important to know that Dear ImGui will be easy to integrate in whatever odd-custom tech they may have, and I am on the watch to hold that guarantee around, and to keep communicating it.
At the same time, effectively probably 90% of homebrew custom engines not build in a professional context are build over common known technology, Win32 API, SDL/GLFW, DX11 etc. And it makes sense to provide the ready-to-use glue to ensure you can integrate Dear ImGui is most apps with <20 lines of code. It's even more meaningful to have that possibility when you are bootstrapping a new projects or are wholly unfamiliar with programming or graphics technology.
The feature scope of Dear ImGui has grown meaningfully over the years, and although the only "required" elements are still mouse pos/buttons, time and rendering those vertices with scissoring, in reality there are many other desirable things which adds up to more work to provide (clipboard, keyboard, gamepads, mouse cursor shape, IME hooks, dpi queries, not mentioning multi-viewports).
You can see my reasoning for renaming examples/ to backends/ here: https://github.com/ocornut/imgui/issues/3513 If anything, I found the tendency of my-weekend-engine people to do their first foray into Dear ImGui often improductive and detrimental to the perception of using Dear ImGui. They tend to struggle 4 hours to get a feature-incomplete backends done instead of first plugging fully working existing backends with <20 lines THEN considering if they really need to rewrite that. I believe that did more bad than good to Dear ImGui because they end up using feature incomplete versions. It's also that years fixing those backends to try to have them work everywhere has been helpful in growing the confidence of calling them backends.
I believe this is mostly communication issue: we should keep hammering that backends are reasonably easy to rewrite and keep documenting that process.
Ref: https://github.com/ocornut/imgui/blob/master/docs/BACKENDS.m...
Many libraries claim to be cross platform and turn out to be hugely painful to use on anything outside of a few intended targets. I still have nightmares about Scaleform!
Not sure what stops Sony from doing it.
Things went better with OpenXR.
Let see if it as successful as OpenCL 2.x that had to reboot back into OpenCL 1.2 for version 3.0.
OpenXR doesn't define the 3D APIs, it is just device management, one can use it with whatever APIs one feels like it.
And then there is Hollywood switching to CUDA based render farms, like OTOY, because Vulkan Compute doesn't deliver what they need.
https://www.khronos.org/conformance/adopters/conformant-prod...
There's also a platform integration extension attributed to NVIDIA and Nintendo
https://www.khronos.org/registry/vulkan/specs/1.2-extensions...
Seems unlikely they would go to that trouble if Vulkan weren't actually exposed to developers
You can use vulkan on Mac and iOS using MoltenVK.
As a rendering engineer, I have lots of doubt that those vendors will move away from their proprietary APIs, they provide significant advantages, and from anecdotes from around the industry, I think this state is preferred by engineers in AAA development, which I think is where much of the forces in the industry come from.
[0] https://en.wikipedia.org/wiki/PlayStation_4_system_software
It is kind of DirectX 12 like, with a shading language similar to HLSL.
Also Switch is always referred as an example of Vulkan support, they also do OpenGL 4.6, but what really matters for native titles on the platform is NVN.