8 posts tagged with "article"

If you're like me, you've thought to yourself at least once: "Hey, making a UI can't be that hard! I wouldn't need to add any more headers or libraries to my project!" Because not having to deal with C++ is a good reason to write your own UI.

Well, I did it for my game, Twin Gods. I can't remember why anymore beyond "hey, that sounds like fun". Am I glad I have it? Yes! You very much learn a lot about how a UI works. Would I do it again? Probably not.

What came out the other end is a confusing mixture of knowledge, a lot of head-bashing, years of code that went sideways more than once, and a working UI for a functioning game. Let's see how it works, shall we?

This is not an article to sell you on using my UI (*0). This is only intended as a showcase of how it works, why it works that way, what went into making it, and how difficult it is to make a UI from scratch. And I cannot overstate how difficult it is -- and how much time it takes -- to make a UI from scratch.

Don't worry! your triangle running at a mere 300 fps is perfectly normal. The purpose of this post is to try to convince you it is not a good use of your time to try to optimise hello-triangle.

• 300fps is still pretty fast! ~3.33ms

• FPS can be a misleading performance metric, as it changes non-linearly as you optimise your frame. A 10fps difference from 60 to 70fps is ~2.38ms while the difference from 300 to 310fps is ~0.107ms. To actually profile your application it is much better to use dedicated tools like Nsight Graphics or Tracy.

• Modern GPUs are very complex, and performance does not scale linearly with scene complexity, for example, if one triangle runs at 300fps this doesnt mean five triangles will run at 60fps. GPUs are designed to have really good throughput at the cost of latency.

• When rendering one single triangle, most of your frametime may just be overhead, this could be your window manager, driver or API state validation to name a few.

• hello-triangle is simply not a representative workload for real applications, which are way more complex with lots of factors affecting performance and a compromise between speed and quality. In order to properly judge the performance of your engine, you should at least use a test scene such as Intel Sponza or Bistro.

Good luck on your journey learning graphics!

Reduce and scan operations are core building blocks in the world of parallel computing, and now Nabla has a new release with those operations made even faster for Vulkan at the subgroup and workgroup levels.

This article takes a brief look at the Nabla implementation for reduce and scan on the GPU in Vulkan.

Then, I discuss a missing execution dependency expected for a subgroup shuffle operation, which was only a problem on Nvidia devices in some test cases.

Real time rendering performance is often limited by 3D assets as much as it's limited by code. Good low poly assets inevitably rely on baking, the process of transferring details from a high poly mesh with a complex material to a low poly one with a much simpler material. Unfortunately, however, there seems to be a lack of info regarding baking around. Especially in Blender, things can sometimes be a bit unintuitive regarding baking. In the process of working on my game, A Short Odyssey (ASO), I came up with a workflow that works quite well for me, so I will share it with you today.

For this tutorial we are going to use this wooden bowl model from the fantastic website Polyhaven.

Described as "the most important numerical algorithm of our lifetime", the FFT has applications in a plethora of domains.

In this article I show how to run an FFT in Nabla, talk about different optimizations and showcase one application in graphics: FFT Bloom.

While a common way to use GLSL, editing bare text files or embedded strings is not a scalable way to write programs.

This article will show how to make programming in GLSL more tolerable with linting and various means of code reuse.

All code for this guide is in C++ and the full source code can be found here.