How do Games Load SO MANY Textures? | Sparse Bindless Texture Arrays

How do modern video games manage to load hundreds of high resolution textures when OpenGL expects them to limit themselves to 16 or 32 per draw call? In this video, we go over Sparse Bindless Texture Arrays, a collection of advanced graphics programming techniques in OpenGL and Vulkan, which can be used to get the most out of the video memory available. We also cover texture compression and vertex memory layout, two other techniques which can be used to reduce the memory footprint of games.
I'm a University Student in Computer Science, and I'm endeavoring to be an indie developer. I'm creating Zepha, my own voxel engine, which I'm using to create my own game, as well as an extensible, stable modding framework for community creations. I learned about the techniques in this video first-hand from the 4+ years I've spent developing it.
If you're interested in the type of stuff I show in this video, then be sure to subscribe to be notified when I upload more videos like this! I would really appreciate any sort of interaction, as my channel is super small right now and I'm hoping to grow it in anticipation of my game's release :) Otherwise, thanks for watching!!!
My other social medias:
Discord: aurail.us/discord
Twitch: / aurailus
Patreon: / aurailus
Tumblr: tumblr.com/zephagame
Livestream VODs: ‪@AurailusVODs‬
Video Chapters:
00:00 - Introduction
02:14 - Sparse Textures
04:10 - Texture Arrays
06:25 - Bindless Textures
07:19 - Texture Compression
08:58 - Vertex Optimization
10:39 - Final Notes
11:07 - Closing Remarks
Music Used:
5PM - Animal Crossing
Tabloid Jargon - Sonic Mania
Pandora Palace - Deltarune
Lights, Camera, Action! - Sonic Mania
CORE - Undertale
7AM - Animal Crossing
Useful resources:
learnopengl.com
www.gdcvault.com/play/1020791...
www.khronos.org/opengl/wiki/A...
registry.khronos.org/OpenGL/e...
www.khronos.org/opengl/wiki/B...
registry.khronos.org/OpenGL/e...
#opengl #gamedev #coding

[@FredericoKlein]

Acerola looks different

[@Aurailus]

But Acerolaaaaaaaaa, that's not you, that's just some other nerd on the Internet talking about graphics!

[@fabiangiesen306]

I work on Unreal Engine on numerous things including most of the texture processing/streaming stack, some notes: 1. GL implementation's low texture bind point limitation is really just a GL-ism. For example, on Windows, going back as far as D3D10 (that was 2006!), D3D required support for 128 texture bind points _per shader stage_. So you could have 128 textures for vertex shaders, another 128 for your fragment shaders, all in the same batch. GPU HW has supported way higher limits than GL usually exposes for decades. 2. That said, even though the actual limit is usually way higher than you can access with unextended GL, bind point limits are per-batch. You can change the bound textures for every draw call if you want, and it is in fact completely normal for games to change active texture bindings many thousands of times per frame. This is true for GL as well. 3. For a powers-of-2 size progression, if you don't want mip map filtering (and when you're using pixel art, you probably don't), you could just create a texture array at size say 512x512 with mip maps (which makes it ballpark 33% larger in memory than without) and then mip map 0 of it is a 512x512 texture array, mip map 1 is a 256x256 texture array, and so forth. You can use texture sampling instructions in the shader that specify the mip map explicitly and this will let you collapse a whole stack of texture sizes into a single bind point, if you want to avoid changing bindings frequently. 4. That said, most games don't use texture arrays much. The most common path is still separate 2D textures and changing all texture bindings whenever the material changes between draw calls. 5. Likewise with sparse textures. You need to distinguish between the technique and the actual hardware feature. The actual HW feature (what GL calls "sparse textures") exists but is rarely actually used by games, due to some fundamental problems with how it works. For example, Unreal Engine doesn't use it at all and instead just does it manually in the shader. See e.g. Sean Barrett's "Virtual Textures (aka Megatextures") video on KZbin, a re-recording of a GDC talk he gave in 2008. 2008 was before the dedicated HW feature existed, and most games and engines still use the old all-in-the-shader method. The issue is that the HW method involves manipulating the actual mapping of GPU virtual to physical addresses used by the GPU, which is security-sensitive since there might be data in GPU memory from a different process that you're not allowed to see. (Imagine e.g. a user having a browser tab with their email, a messaging app or their bank app open). So whenever you change the actual GPU virtual->physical mapping, any changes you make need to be vetted by the driver and the OS to ensure you're not trying to gain back-door access to memory you have no business looking at. That makes the "proper" sparse texture mapping update path relatively restricted and slow. The "old school" technique works purely with a manual indirection through your own textures, none of which requires any privileged access or special validation; you're allowed to poke around in your own texture memory, that's fine. So even though it's more work in the shader, updating the mapping can be done from the GPU (the official sparse texture mapping update is CPU-only, since the OS needs to check it) and is much more efficient, and this turns out to be a more important factor in most cases than the higher cost of texture sampling in the shader. 6. Bindless, likewise. This has been around for a while and some games now routinely use it, but most games don't. For example, as of this writing (early Jun 2024), bindless support in Unreal Engine is being worked on but hasn't actually shipped. Currently, most games really just have a bunch of textures around and change bindings more or less every draw call. (These days through somewhat more efficient methods than GL's bind points, but it's still explicit binding.) 7. Texture compression is not really transparent generally. I think some drivers (especially on PC) support creating a texture in a compressed format and then passing in RGB(A) texture data, but this is a convenience thing, not the normal way to use compressed textures, doesn't tend to exist on mobile targets at all, and tends to give pretty poor quality. The normal approach is to compress textures to one of the supported formats off-line using a texture compressor library (these are much slower but higher quality than on-the-fly compression) and then pass that in. 8. DXT3 and DXT5 are the same for the color (RGB) portion and differ only in how they handle A. In practice, ~nobody uses DXT3, and there is not much of a reason to. DXT5 gives better quality pretty much always. 9. One very important thing to keep in mind is how textures are stored in GPU memory. In short, really small textures tend to be incredibly inefficient. It's not rare for texturing HW to require textures (and often individual mip maps) in GPU memory to be a multiple of some relatively large size, often 4kb or even 64kb. This is not a big deal if you're dealing with high-res textures. A 4096x4096 DXT1 texture with mip maps is around 21.3MiB. Rounding that up (even if it happens at the individual mip map level) to multiples of 64k does not change things much. If you're doing pixel art with 16x16 and 32x32 textures though, then even with uncompressed RGBA8, a 32x32 pixel texture is 4kb of payload, and if your GPU requires 64k alignment internally, that means your GPU memory usage is 15/16ths = ~94% wasted space. This is one of the bigger reasons why atlasing and related techniques are so important for pixel art, font rendering and other cases where you have many small images. It's worth noting that texture arrays do _not_ necessarily make this any better. It depends on the GPU, but if you have something like an array of 32x32 images, it's totally possible (and not even uncommon) for the GPU to internally require memory for 64x64 pixels or more per array element. Basically, current GPUs are _not_ built for really small texture sizes, and if that's most of what you use, you need to keep an eye on how much memory that ends up consuming because it can be surprisingly horrible.

[@fabiangiesen306]

oh, bonus note: 10. Texture streaming. Both for sparse/virtual and regular textures, you have these high-res assets on disk (one of the main reasons why modern AAA games are so big, just tons of high-res textures in the package) but just because you're using a texture doesn't mean to have it fully resident all the time. In something like UE (and many other game engines), if you load a map or world chunk, that'll include a very low-res version of the texture - the last few mip levels. For UE, typically, those textures are around 64x64 pixels with mip maps. That part of the texture is always resident as long as the part of the world referencing it is (it's no use making it much smaller than 64x64 due to the texture storage size limitations mentioned earlier). But the actual size these textures are built from is generally much larger, these days usually at least 4096x4096 pixels and often much more. So we have more larger mip levels on disk: there's a 128x128 mip, a 256x256 mip, and you might go all the way up to 8192x8192 or whatever on disk or you might have the highest resolutions only in the source art (just in case, for archival purposes or in case there's a remaster in a few years) and have the largest size stored on-disk for a texture be 2048x2048 pixels or similar. Anyway, those larger mips will get loaded only once you get close enough to something in the world using those textures to actually see them. That threshold is usually generous (we like to start loading the high-res mips a bit early because it takes a while to load them!) but still, even though high-res versions of most everything tend to exist on disk somewhere, most textures at any given time only have a subset of their mip maps loaded because you're nowhere near close enough to be able to see the full thing. Pure mip map-based streaming has the problem that if you do end up needing those larger mips, e.g. a 4096x4096 or 8192x8192 mip in a close-up of an important character model or whatever, that's still a lot of image to load at once and a lot of VRAM to need from one frame to the next. Overall games are using sparse/virtual textures much more for that kind of thing. These can be partially resident and dice up large textures (and their mip levels) into something much more manageable like 128x128 pixel units. So even if you have your close-up hero shot of some character or NPC, then you need a high-res version of the face resident, and the highest-rest version of the "body" texture up to their shoulders or so, but their back isn't visible at all and neither are most of their arms, legs or torso, so the extra-creamy 8192x8192 textures for those can stay mainly on disk instead of having to be resident in your precious GPU memory pool that instant. Texture streaming is the biggest single reason we can make this stuff fit. Most 3D games released in the past 15 years lean pretty heavily on it.

[@Aurailus]

Oh wow, thank you for the thorough response. It's super cool to hear from someone experienced in doing these things the AAA way. Looking back, I can see I made a lot of mistakes on this video, some of which have been pointed out already. Particularly I think I really failed to emphasize the GL-ness of all of these problems, since I had no experience with any other frameworks at the time I put this video together. I've since moved my project entirely over to Vulkan, and it's such a different beast. I'm really happy for the change. For your point on mip-mapping, you might have been misled by the way that I reused some textures in the section where I showed the different textures in the texture arrays. That was honestly just because I didn't have enough assets to work with. I do use proper texture mip-mapping on all of my uploaded textures. I'm aware that a lot of games do swap textures normally, I'm mostly coming at this from the perspective of a voxel game developer, in particular, a voxel engine developer. I need to be able to support any combination of any blocks in any chunk in the game, which could possible entail supporting one mesh with every single registered texture rendering at once. Obviously that's a huge pain, but it's also a great use-case for texture arrays, and bindless textures, so I'm glad that they exist. I'm not sure I see what you're saying with bindless textures not being used commonly. I know some games may not need it, but from my understanding, a lot of games use it, or similar techniques with large descriptor arrays in Vulkan. Perhaps large engines are better at optimizing and organizing texture atlases, but in the indie dev scene, it's been pretty ubiquitous from the people I've talked to that moving towards bindless techniques is the way to go. In retrospect, I'm quite dissappointed at the way I represented sparse textures. I got most of the knowledge for this video from the 2014 GDC AZDO talk, where a lot of these features were new, and looked at very optimistically by the developers. I put a bit of work into implementing them, and while they seemed to function, I didn't put due dilligence into testing their performance to see if they were actually better in the modern day. It's a shame that information of the "right" way to do things in graphics programming is so fragmented. When looking for ways to improve my engine, that talk was the first resource I was told to learn from by several people, which is odd given a lot of the techniques they discuss in it turned out to be quite slow and unwieldy in the modern day. The security angle for sparse textures is something I hadn't considered. I found out after making this video that sparse texture access was quite slow, but I didn't know why. Very interesting! In a similar vein to the AZDO thing, comments on this video were how I realized that the page on texture compression on the OpenGL wiki hasn't been updated in almost a decade. That was a fun discovery after I uploaded my video 🥲. Honestly, the state of OGL documentation and a huge amount of work I had to go through because OGL refused to report errors to me were what finally pushed me over the edge, and I've now reimplemented the entire render pipeline of my engine in Vulkan. I'll be making a video on that process soon. I had no idea that textures were aligned to such large memory regions in VRAM? Does this alignment apply to individual textures in texture arrays as well, or does it treat a whole texture array as a single block? Depending on what it does, I may need to rearchitect a few things :) Where does one find out these low level details for how graphics cards lay out memory and execute the render pipeline? I'd love to get a more thorough understanding of the hardware I'm using, but it's very hard to find modern, comprehensive information on anything in this area. I've witnessed texture streaming in games before (mostly when they're doing it poorly, although I'm sure well implemented games do it so well that it's invisible.) I don't think that's an issue I'll need to handle in my engine, as I'm mostly optimizing for low-ish resolution assets, but it's regardless a cool thing to discuss. Thank you for taking the time to write all this out! I really enjoyed reading and replying to it! - Auri

[@fabiangiesen306]

@@Aurailus Re: bindless textures not being used commonly, in the AAA space people are slowly starting to use them but mostly only within the last 2-3 years or so. There's a ton of inertia, and with bindless especially the debugging experience on most platforms is still significantly worse than with explicit binding. This is a significant hurdle for big projects because there are so many unexpected interactions in complex projects and you often need to debug code that was originally written 5 years ago by someone who's no longer at the company. Good tooling support is just absolutely essential to get anything to work at all, and deploying anything that makes it harder is an uphill battle. Explicit bind points have been around since forever and AAA games virtually never start from scratch, they mostly either use a licensed engine or start from an earlier version of an in-house engine. In both cases there's a lot of shaders and custom tooling around that all need to be touched and updated to move to bindless. I can't emphasize enough just how big the scale of that problem is. As of this writing, a change has just landed in the shader build pipeline for Fortnite that makes it so the ~764000 (not a typo) PC "shader model 6" shaders (that's the generation that even supports bindless, there's a whole separate set of shaders for older and integrated GPUs that can't really do it) in Fortnite are now merely 7GB instead of the 18.6GB they were earlier (in the compressed form they use on disk, that's 4GB and originally 11.6GB, respectively). Fortnite is a bit of an outlier and has been shipping continuously since 2017 (mostly adding to it, much less often removing things) and it's not like these shaders are all hand-written (it's a combination of ubershaders and an extensively artist-customizable material system), but the sheer quantity is a problem and it all has to keep working. Even testing that you didn't break anything important after a change takes a long time. I recently spent around an afternoon writing a fix for the way textures were packaged on the Nintendo Switch to save a few tens of megabytes of memory (always tight on that target) and reduce CPU/GPU load for texture streaming. It then took around a week of iteration to find a shippable way to put the "enable" toggle for the new way of doing things into the engine config in a way that actually worked correctly in all possible texture build paths (several of which don't have access to the normal engine config facilities for complicated reasons) and was going to work for other Unreal Engine licensees too. And then another ~4 weeks of testing to make sure it actually worked right in-game in all cases it needed to work in. "Perhaps large engines are better at optimizing and organizing texture atlases" - not really, no. UI things (especially icons and fonts) are usually atlased but for the textures used for your main rendering viewport it's up to the artists. If you have a character model, environment art or prop, there's usually some manual (or at least adapted from a semi-automated UV unwrap) atlasing there but across meshes, there's really usually nothing. These things usually all have different shaders anyway so it's usually separate batches regardless. (With deferred shading, which has been common for over a decade at this point, you do have opportunities to do most of the complicated material shading across mesh boundaries if you want to.) "I had no idea that textures were aligned to such large memory regions in VRAM? Does this alignment apply to individual textures in texture arrays as well, or does it treat a whole texture array as a single block?" Vulkan and D3D12 do expose at least some of the memory sizes and alignments, so you can see some of it, if you know where to look. The details of texture layout vary greatly between GPUs, there's not even any general agreement on what order things are stored in memory :) - e.g. for a texture array with mip maps, do you store a mip chain for element 0, then a mip chain for element 1 and so forth, do you store mip 0 for all elements, then mip 1 for all elements, or something even funkier? I've seen variants of all three. But usually, the base address of the texture is aligned, the base of each mip level also needs to be aligned (sometimes to very large units like 4k or even 64k, but usually at least to some multiple of 256 or 512 bytes), and yes, the array elements usually also need to be aligned. The GPUs with large alignment requirements generally have some way to relax them for the smallest few mip levels, but usually the last few mips (say 8x8 downwards) really are mostly alignment padding on most GPUs. If you're on game consoles, you tend to get access to a bunch of low-level hardware docs so you know what's going on, as a PC or mobile dev you're unfortunately mostly stuck with the crumbs the APIs, vendor-specific debugging tools and the occasional support thread with an IHV give you.

[@asandax6]

Thanks for the info. This will save me a lot of time in researching techniques to optimize textures.

[@gaberil]

how many hours did you spend writing this xd?

[@dstry_Flightman]

I have no idea what you're talking about but this is very well made.

[@Aurailus]

❤

[@aarthificial]

Fascinating topic! I've only ever heard about these techniques in the context of raytracing but using them for a voxel engine makes so much sense. (Btw, love the visualizations in your video)

[@Aurailus]

Thank you so much Jacob!! Seeing your comment broke my brain a little, your devlogs are a huge inspiration for me, and I definitely wouldn't have started doing anything like this without Motion Canvas. I'm glad that my video was able to show you something new! I'll definitely be making more stuff like this in the future :)

[@Aurailus]

*Corrections and Notes* (thanks for putting up with me ♥) - People have informed me that "we're back to ground zero" is a malaphor, and the actual phrase is "we're back to square one". I looked this up and it's actually a pretty widespread phenomena. Is this a mistake, or just language becoming weirder and weirder as we all stumble deeper into insanity? I'll let you decide... - I swapped really abruptly between talking about video memory and bind slots, which might be confusing to some people. Bind slots are not related to video memory, they are effectively a place that you input a texture that already exists in memory to be used for rendering. These slots only really exist in software, limitations are imposed on them by the graphics APIs, not the physical hardware of the card. Video memory, on the other hand, is the stuff that actually stores the texture, which is physically limited by the design of the card. - Some people wished I was more clear that these tips were directed at OpenGL specifically. That's very fair! I have a habit of forgetting how different other graphics APIs are. Vulkan doesn't have the same issues with Bind Slots that OpenGL has, and thus does not need Bindless or Array textures. However, it does, from my understanding, have an understanding of Sparse Textures. It also can benefit from Texture Compression & Vertex Optimization, although the texture compression algorithms might differ, I'm not too sure. As for DirectX, I do not care. Windows specific graphics API bad

[@LoganDark4357]

did you forget to pin this?

[@ultimaxkom8728]

It's best to pin these notes.

[@akumatensei5466]

based

[@duxtorm]

You deserve way more recognition! That engine you're working on is gorgeous! And this video was very informative, in fact, I've even saved it as a resource for my game-making journey

[@meerkat22]

I've worked with all of this techniques. I didn't expect so much insight from the video. Information about this topics usually is kind of dull and limited. However, the explanations are just brilliant, great job.

[@Aurailus]

Thank you so much! I'm glad that I was able to entertain and inform you 😸

[@najunix]

I always love to see how magnificent works of art work under the hood, even though I have barely a grip on the exact science. This video made me connect a lot of computer science dots, especially in graphics processing! Thank you so much for this!

[@Aurailus]

Thank you! I'm glad you enjoyed the video ❤Lovely soweli profile pic :)

[@drgabi18]

6:38 "It turns out that over the last several decades of computer gaming, GPUs have changed a lot. GPUs used to need explicitly bound textures to know what to draw, but that's just not a limitation anymore." This is the knowledge I went with into this video, only knowing just random limited stuff from Acerole and other ppl. I genuinely heard every concept for this video for the first time FROM here. If your ideal viewer who needed techniques was me, this 100% would have helped since it's not regurgitating the many other videos repeating the same stuff. Do what you want with this feedback! Also I'm surprised you didn't just use Renderdoc or that N-Sight to just see what that game dose.

[@ross_codes]

I liked this video! Good presentation, very easy to understand. It may be worth emphasising the "OpenGLness" of both the problem and solution with regards to binding large numbers of textures. Most AAA games use DX12 or Vulkan which handle all the texture book keeping with descriptor sets (kinda already bindless). You might enjoy Faith Ekstrand's "descriptors are hard" blog post - she's a Linux Vulkan driver developer.

[@Aurailus]

Thanks for your kind words!! You're probably right, it's easy to get sucked into thinking the framework you're working with is the standard that everyone uses, but some of these techniques are very OpenGL specific. I'll be more clear about what API the content is about in my next video. I'm pretty sure that the Sparse Arrays part of the video would translate to Vulkan, as well as the Vertex optimization section. I could be wrong, though!

[@Tarvman]

While descriptor sets allow groups of resources to be easily swapped in and out for each draw call, a descriptor set cannot be swapped in the middle of a draw call. This means if you only bind individual textures in your descriptors, it is not so easy to draw multiple objects with different textures in a single draw call, I.e., with instanced draw calls or multiple indirect draw calls. In those cases, the virtual texturing and bindless approaches are still very useful in Vulkan and DX12. Overall, I liked this video - it would have been nice to have had this when I was figuring out textures.

[@omerfurtun4115]

In the very recently released Unreal Engine 5.4, there's an improvement referred to as "RHI - Bindless Rendering (Experimental)" which is essentially what this video talks about, which is something I didn't know about. I'm not sure if it's the algorithm being spot on or just sheer luck but I was shown this video just today. Subbed!

[@Aurailus]

Ooh, that's exciting! I don't use pre-made engines for my own projects, but having them adopt more advanced rendering techniques is better for everyone! I know at least in the Vulkan world, this stuff has been properly supported for a while. Thanks for watching!

[@Clawthorne]

It makes me happy more informational and educational videos on graphics rendering have started popping up since the whole Unity implosion. Your videos are good. Especially enjoyed the animations. They were fun and underlined your points really well. Keep it up!

[@Aurailus]

Thank you, I'm glad you liked it!! Hoping to get another video out soon on efficient voxel lighting :)

[@josephpolon6837]

I cannot believe I stumbled upon a gem of a creator like you at the beginning of you channel. Keep up the good work, you WILL SUCCEED! You are a inspiration congratulations ahead of time.

[@Aurailus]

This is where I pull a fast one on you by never posting another video ever again! 😈 Just kidding, with how positive of a reception this video got, there's no WAY i'm stopping now. Thank you so so much!!!! Your comment made me feel all warm and fuzzy inside :)

[@GaleLD]

I love this! Helped me understand why I should use integers whenever possible, rather than floats. I hope to see more of you ❤

[@jordicoma]

Very interesting video. I remember when id first implemented (on software) virtual textures on rage, and then some years ago I read about when they added bindless textures to OpenGL, but never I listened to a simple description why it's so important to have the bindless textures. I thought that was only for performance. Great video.

[@Aurailus]

I never thought they were important either, until I took the time to learn about them. But I'm happy that I took the time to figure out why they matter!

[@toffeethedev]

i love your video editing style so much its so fun!!! very cool visualisations, ive done engine graphics programming but i had no idea about some of these features, thanks so much!! 💞

[@Aurailus]

Thank you!! I'm glad that I was able to introduce you to new things!!

[@WebbstreMain]

This is so useful! I don't know why KZbin decided to grace me by suggesting this video, but you just gained yourself subscriber 144!

[@Aurailus]

Thank you so much!~

[@hazard-funk]

I am currently just getting started on graphics programming and learning basic stuff on OpenGL. Seeing this video literally made my head spin, but neatly put together tho. And your voxel engine looks cute!

[@Aurailus]

Thank you! I hope my video was able to help in some small way. Best of luck on your learning!!

[@fernandogoncalves7297]

Im so happy to have found this channel, when I was younger and tried to delve deeper in this kind of topic, it was really hard to find information that was begginer friendly. Now this niche part of youtube is more active and growing a lot. I hope to be contributing soon too. Good work!

[@Aurailus]

I'm really glad that the indie dev scene exists on KZbin now as well. I've wanted to make games since I was 10, and there was a lot less of this sort of content out there at that point. I knew when I started seeing indie-dev videos on my home screen for like two months straight that it was finally time to try making something myself, and I'm really glad it turned out the way I did! I know I've been radio silent on this channel for a while, but I have a video coming out soon on my switch from OpenGL to Vulkan, and I'm really hoping that people like it as well. ❤️ Thank you for watching!!

[@ZalvaTionZ]

Great video! I have no practical use for this knowledge currently, but it's presentation is great! Wish there was more content like this every time I want to dive into some specific techniques.

[@Aurailus]

Thank you so much!! I love videos that go over topics I've never heard of before, which is why I made this one! Because despite all the long-time graphics nuts knowing all of these things, I'd never heard of them and I figured other people wouldn't've either! Do let me know if there's anything specific you'd like me to cover, and I might do it if I like the topic!

[@nincompoop17]

I randomly stumbled upon your twitch channel at the beginning of ludum dare, asked you a question and you were so polite and immediately helped me out. Now I see you won 2nd place for Ludum Dare, that's insane! And this video is full of such incredibly high quality golden nuggets. You are extremely talented, I'm wishing you all the best on your journey!

[@Aurailus]

Hey, thank you so much!! I love chatting with people live, so I'm glad I made a good impression :) I am still totally shocked about getting 2nd in Ludum Dare as well. I'm (slowly) working on making a video about my experiences with it, which I think should be pretty cool. I really appreciate the kind words, have a great day!!

[@drinkwwwaterrr]

I had no idea that storing textures was this complicated but this was really nice and informative :D

[@Aurailus]

Thank you! Game engines abstract a lot of this away, but I'm building my own game engine, so I don't really get any of those benefits :P I also just like learning how all this stuff works on a low level!

[@thombruce]

Such a fantastic video, I couldn't really believe my eyes when I saw you only have 400 subs... Great production value! Have one more subscriber. 🔔

[@Aurailus]

Thank you so much!! (sorry for the repost, KZbin is being odd right now.)

[@JaapioNL]

Cool, a few years ago I stumbled onto bindless textures while checking out the RTX samples by Nvidia and I already knew about texture arrays but never about sparse textures, that’s so cool. I wish I had discovered your channel earlier, subscribing now.

[@Aurailus]

Hey, thank you!! Bindless Textures really are the star here, they sort of make every other technique obsolete. The main reason I covered Texture Arrays and Sparse Textures was because of the somewhat poor driver support for Bindless Textures in OGL. I've learned now though that they're actually part of the core Vulkan spec, which is super cool! I'm shifting my engine over to use Vulkan, and I'm going to be taking full advantage of them there.

[@Mittzys]

Ooh, your channel is gonna blow up! I loved this, it was extremely informative. Also, your outro is beautiful!

[@Aurailus]

Thank you so much!! ❤️ I had a lot of fun recording that outro. It's my favorite place in my city :)

[@robot7338]

this was awesome! im excited to see what you make in the future!

[@Aurailus]

Thank you!!!

[@zooidiotgaming5784]

I'm not a graphics programmer but I've been coming back to this video a lot just because it's such a cool video that explains things so well. And I love the editing so much!

[@Cokodayo]

Woah, how do u have only 500 subs wtf. This is too well made for a channel this size. Very interesting topic. Looking forward to more of your vids.

[@Aurailus]

Thank you so much! I've got a lot more videos planned, but I'm struggling to find time to put them together in between university classes. But hopefully I'll have some other stuff here soon!

[@Cokodayo]

@@Aurailus take your time, don't stress too much about pushing out more content. Uni is important too. But hey, what do I know, I'm just a random guy on the internet.

[@lhilbert_]

this is amazing, so happy i found your channel! :) Keep it up!

[@cosmotect]

Awesome video, thanks for sharing the knowledge! I would be very interested to see a separate video on generating and storing all the vertex data :)

[@WeirdRubberDuck]

This was exactly the information I needed! Thank you for the thorough walk-through and pedagogical format! This video is awesome :)

[@Aurailus]

Thank you!! I'm glad that you liked it, and I hope it helped you!!

[@takikat]

these visualizers helped a Lot even for someone who struggles with programming logic, big props

[@Aurailus]

Thank you! I put a lot of work into them, so I'm really happy people are enjoying them! I want to go even further with visualizations next time :)

[@MustacheMerlin]

Vulkan Descriptor Set Indexing is super cool. Forget texture arrays of fixed dimensions - you just store however many whatever sized textures you want and access the correct one in your shader with an index integer. It's the next step of bindless textures, notice there's no "texture" in the name - that's because descriptor set indexing is bindless _everything._ Anything that has a descriptor is bindless. If you're using OpenGL tho like it seems you are, the keyword you want to google to learn about this kind of stuff is "AZDO OpenGL" AZDO stands for "Approaching Zero Driver Overhead" and most of those ideas were what eventually grew into Vulkan and DirectX 12. basically. exactly these issues you are running into and the lack of those limitations is what people mean when they say Vulkan and DX12 are "next generation" graphics api - and why OpenGL is implicitly "last gen"

[@lightspeedlife8299]

Woah, this was in depth! I'm not working on implementing anything like this myself right now, but if i had more time, I'd like to grind out a custom engine with opengl for device compatibility, and i'll definitely be following your channel for more insights like this when i get there. I'd like to see more about your game, too!

[@Aurailus]

Thank you so much! I'm probably going to be making a video about my game pretty soon, I'm just waiting to have something extra-interesting to say :)

[@markoradojevic4813]

I can't wait to see your other videos, keep up the amazing work. You deserved a sub!

[@Aurailus]

Thank you so much! I have much more planned! 😺

[@sukruciris]

nice video. i also make a voxel game with opengl and C nowadays. i think that's why yt recommended your video :) and i am a computer engineering student too. i implemented batch rendering recently. if i have a problem with textures i will watch this precious video again carefully :)

[@Aurailus]

Thank you! Best of luck on your project!

[@smlgd]

This video is so good I couldn't tell it was your first attempt at this format. Great job. Also I'm surprised that it showed up on my home feed given you don't have many subs and views. Only thing I'd like to point out is to maybe look more closely at the audio mix as there are some obvious seams and the volume is swinging up and down between cuts. Other than that it feels great to me

[@Aurailus]

Thank you so much! I seem to have triggered the KZbin algorithm to start recommending this video somehow because I've been getting a steady stream of organic views for the past several hours! I definitely was aware that the audio mix had problems. I recorded all of the lines in one session initially, but on review the next day I realized some of them didn't sound right, so I had to re-record them, and that's what the seams are. It's shockingly difficult to replicate the sound quality of a recording even just a day apart! I'm sure I'll be able to get better at that as time goes on though. But yeah, thank you thank you!

[@GreatCollapsingHrung]

The Algorithm works in mysterious ways, guiding The Lost in their search for the Place of Belonging. All hail The Algorithm!

[@rmjrmj4]

You did well to explain the ins and outs of texture loading methods. I would us some if I knew how... but sadly you never explained the ways to apply them in a game engine like unreal or such. I'll just have to cram it in for another lesson in another video, but thank you for all your hard work. I do hope your game comes out with will reviews!!

[@DanaTheLateBloomingFruitLoop]

Fascinating topic and great presentation! As an amateur gamedev I am always glad to have things demystified about what is actually going on in a computer. Makes it all feel less daunting.

[@Aurailus]

Glad you enjoyed it!

[@PreschoolFightClub]

This video is truly fascinating. Even more so considering that my contribution to game dev is music and this doesn’t help me at all. But I can still appreciate the processes and information (and suffering) that the others on my team go through. Excellent video.

[@BreakingStupidity]

You make really good content and I look forward to seeing more of your stuff!

[@Aurailus]

Thank you so much!

[@vertexcubed]

This is all really fascinating stuff that I didn't know about! I'm also an aspiring game dev and I've been really interested in learning about rendering and graphics optimizations so this video is really helpful :)

[@mathieuouvrard3848]

Awesome video, very clear and concise ! Thanks, it helped me a lot :D

[@Aurailus]

Glad to hear it! Thanks for watching!

[@SasLuca]

I often asked myself about this so much, this video was awesome

[@AusSkiller]

Great video. Sounds similar to what ID was doing with mega textures way back when I was still new to the industry. Unfortunately I haven't had the time to keep up with modern techniques as much as I would have liked because it is so rare to be working on new engines these days. I'm glad to see some people are still poking around with engine level code though, it really gives you a much better understanding of how things work and there are so many types of games that can benefit from engine level optimizations.

[@CBaggers]

Nothing to add, except to say, please make more of these!

[@Aurailus]

That's the plan! 😸

[@DrawSage]

I took a shot everytime I heard the word texture, and am now a furry. Thank you.

[@Aurailus]

That's a known occupational hazard of watching any of my videos. I wish you a speedy recovery!

[@mystifoxtech]

have you recovered yet?

[@chocothechip]

Amazing video, thank you for providing all this info in such an easy to understand manner! I normally stick to painfully simple textures and low poly just to avoid all the hard work that comes with graphics rendering, but your explanation has made me more confident to try working with serious big boy graphics. Also your voxel engine looks awesome, I'm rooting for your success! 📈🔝🔝

[@morgan0]

really interesting video. also nice to see someone else who remembers /r/place fondly

[@fluffy_tail4365]

This is an incredible overview, subscribed for sure

[@Aurailus]

Thank you so much!

[@Ryutsashi]

Thanks for contributing knowledge in a that's not already readily available in a video format. Your body of work so far is too small for me to give you more substantial feedback but... Thanks :D Keep doing this

[@naturally_rob]

You remind me of StyroPyro with how you present information; but with programming. This is exactly what I've looked for

[@Aurailus]

I'll have to check out their videos. Thanks!

[@JosefdeJoanelli]

Excellent video! Please don't stop

[@Aurailus]

Thank you so much! I have more planned but just zero time right now. Hopefully I'll be able to get another video out soon!!

[@rubenwardy]

Good job! This is going to be such a great resource for the next person looking into this. Great animations and your personality shines through. I'm looking forward to seeing what you make next

[@Aurailus]

Thank you so much!! If I can help others to find these features of OGL then I'm happy! I have several more videos in the works. The next one will likely be on more advanced lighting in voxel space. Glad you enjoyed the video!~

[@alexamand2312]

great work ! you deserve way more viewer !

[@Aurailus]

Thank you!

[@tanysfoster2819]

Congrats on ×100 followers since uploading this video. ❤

[@PaulMetalhero]

Very informative video, thank you!

[@Aurailus]

Glad you enjoyed it!

[@ahuahu4785]

You're pretty good at educational content :D I enjoyed it very much!

[@IanDiaz]

Great video, especially for your first educational video! A few things I'd like to point out... I'm guessing you probably haven't run into this due to the size of your textures, but just FYI, hardware sparse textures are very rarely used in big games, specifically because binding the pages is INSANELY slow on Windows due to issues with WDDM. There may have been improvements to this Windows 11 (haven't tried it myself in several years), but as of the last time I checked, it was still effectively useless for the texture sizes you'd see in modern AAA games. Pixel art is likely small enough that it wouldn't be noticeable, though, and on Linux, it's a non-issue AFAIK. For a long time, it was relatively common to do software virtual textures - you may recognize the term "megatextures" from idTech - where individual textures were replaced with page indirection textures that referenced NxN blocks of texture memory in physical atlases (often with some padding so that hardware texture filtering can be used, as you noted for classic atlases, but some implementations just do manual texture filtering). This was initially done because hardware didn't support proper virtual memory (megatextures were first implemented on the Xbox 360 iirc, which came out in 2005 lol), but continued (and continue) to be used because of the slowness of hardware sparse textures on Windows. SVT is typically paired with a readback system wherein a render target is generated during rendering that tells the CPU which texture pages need to be loaded in, which is why games like RAGE and DOOM 2016 have a lot of subtle texture pop-in - you can only load the correct pages a frame after they're needed at the earliest. Nowadays, though, most games just go bindless and stream in progressively higher resolution mip levels depending on some heuristic like distance. SVTs are supported in many off the shelf engines these days, and they're not too bad to implement yourself if you take the time to understand what they're doing. Some games use them in highly specialized ways - for example, Battlefield and some of the Far Cry games use SVTs that are generated on the fly on the GPU to optimize highly detailed terrain rendering with tons of decals basically for free - whereas others use them in more or less the same way as you currently are using hardware sparse textures. I've actually been meaning to use them as the foundation of a procedural texturing system for my own game engine for a few years, where a visibility buffer would be used to determine which pages are needed, then a series of compute shaders are dispatched to generate the necessary pages/garbage collect unneeded pages, but yeknow... free time lol. One more thing - DXTn are sort of antiquated these days. BCn work on the same principle of lossy block compression, but some can achieve a higher quality:size ratio (BC1-3 is effectively the same as DXT1/3/5 iirc, but other BC formats, such as BC7, are much more complex). There are other formats as well, especially on mobile, but I mostly just wanted to point out that DXT is no longer the state of the art and hasn't been for quite some time. I'd encourage you to read up on how the block based formats work if you haven't already - it's fairly simple, but I remember finding them quite clever when I was learning about them :P It's also generally worth doing texture compression offline imo as offline tools typically achieve a higher quality than your OpenGL driver will (and because there's overhead to doing it at runtime), but doing it in-driver can certainly be good enough. There are also formats like basis universal that can be efficiently transcoded at runtime into a variety of different GPU compression formats, which can be useful if you're looking to target multiple platforms. Some SVT implementations, such as that of Far Cry's terrain, actually do block compression in GPU compute live while filling the physical texture, and there are some freely available code snippets you can find online for how to do so.

[@Aurailus]

Woah, thank you for the response! I'll tackle these comments one by one. I don't use Windows, so I had no idea that sparse textures had issues with it! I did find the performance even on Linux to be sub-par, and I eventually realized that for my use case, it didn't make sense to have them be sparse, but instead to just allocate however many layers I could for any given image size, up to a certain maximum resource size in bytes (I allocate in blocks of 128 MB, which allows me to have max array layers all the way up to 128x128 images). I'm amazed that games would actually use texture atlasing with filtering methods like anisotropic filtering! I had to put so many pixels of padding to avoid artifacting at texture borders. I thought that artifacting was based on how big the texture was on screen, not how many pixels it was, and I probably incorrectly assumed you'd need even more pixels of border around high resolution textures in an atlas. Either way though, bindless textures do seem like the way forward. Apologies for the out of date information I gave on DXT compression. I hadn't actually used texture compression in my engine yet, but I wanted to talk about it a bit because I imagined it would be useful to some people. I had no idea that the khronos wiki was so horrifyingly out of date. I've looked a little deeper and apparently like nobody has permission to even edit it, which means it's just going to get worse as time goes on. For my personal use, I actually entirely swapped my graphics backend over to Vulkan after having further frustrations with the way that persistently mapped buffers and multi-draw indirect worked in OpenGL. I'm sure that there are many people using advanced OpenGL features effectively, but it just felt like I was wading through decades of poor decisions all stacked atop each other, with no guard rails whatsoever. So I messed around with Vulkan a bit, and I find it so much nicer! I've gotten a lot of the rendering pipeline back to how it was in OpenGL, and I'll be making a video on that once I've fully completed the changeover. Thank you so much for all the information, it was great reading such an in-depth response. Apologies for not responding sooner, I visited family for the christmas season and KZbin (probably rightly) slipped my mind :) Hope you had a great New Year's!

[@grace15625]

Good job on the video!

[@Aurailus]

Thank you!!

[@AlexLuthore]

This was super cool and educational!

[@Faimyn]

Really great info!

[@Aurailus]

Thank you! I'm glad it was helpful :)

[@maddyv5948]

Great video, very informative 👍👍 Thanks!

[@Aurailus]

Glad you enjoyed it!!

[@bcmpinc]

This makes me want to get back into voxel engine development. Its almost 10y ago I worked on it. Learning about ADZO and sparse memory allocation on the GPU. Even wrote a tutorial on how to setup and use a modern OpenGL 4.5 context. It was just before when Vulcan released. Compute shaders were not flexible enough to do what I needed for a sparse voxel octree rendering. Your voxel engine looks really cool.

[@Aurailus]

Hi! Thanks for watching the video! :) I tried looking up the term ADZO and I couldn't find anything on it, if you could elaborate I'd be really interested! It's really interesting to hear about voxel games back when they were still first entering the game dev scene. If you made a video about that, I'd watch it!!

[@bcmpinc]

​@@Aurailus: I mixed up the acronym, it's called AZDO, Approaching Zero Driver Overhead. The idea is to use Direct State Access and avoid all OpenGL glBind* calls. I wrote a wordpress blog about it under the same username.

[@Aurailus]

Oh fantastic, thank you for your reply! I'll definitely read it!

[@chsxf]

Very interesting video. I've learned a lot.

[@Aurailus]

Glad to hear it!! 😸

[@xanderlinhares]

Thank you so much for making this. Please make more. There’s a shortage people making this kinda of content. It would great for you to join SimonDev and Acerola!

[@Aurailus]

Thank you! I plan to make much more, I hope you stick around!

[@gravechest7392]

Very intresting, did not know that you can just use textures on the graphics cards without texture slot, btw great video, at the quality level of a big channel/

[@Aurailus]

Thank you!!

[@lelaleasl]

this is so good! how do you only have 100 subs!?

[@Aurailus]

I mean hey, this morning I only had 19! Thank you!!

[@NoTengoIdeaGuey]

You dropped this 👑

[@Aurailus]

Yoooooo :)

[@jonasls]

Amazing and so valuable!

[@Aurailus]

Thank you!

[@Heeroneko]

Oh....so that's why that Minecraft resource pack I like using loses so many frames. lol Thanks for making a video explaining this stuff.

[@Aurailus]

Thanks!

[@shantanukumar8064]

thanks for making this video :)

[@Aurailus]

My pleasure! I'm glad you liked it :}

[@thelastfortress2043]

Very good presentation. Thanks a lot.

[@Aurailus]

Glad you liked it!

[@serwizzart]

Cool video :) very informative

[@Aurailus]

Thanks! ❤️

[@RealDaveTheFreak]

Even though I am just a simple designer turned Unreal Developer, this is still way over my head. Still, it's very interesting and I love getting into those nerdy details... for one day I may understand them myself. 😁

[@Aurailus]

Hey, thank you! It's all a learning experience, if you keep practicing something, the knowledge will come!

[@daniellapain1576]

I really need to start making videos about optimization. I forgot how scattered the information was on this topic until you pointed it out. I have a hobby in just fiddling around with optimization for games. There are quite a few. Also textures can be interesting for optimization. Say you have a few textures on a Texture Atlas for example. If multiple parts of textures on your atlas actually match each other you can use a mapping piece of code to shrink the images into the matching shapes and have it realign the pieces like a puzzle back into the original texture. This is an old technique that has not been used too often because of having to get custom code to work nicely with the engine but these days it should be possible for AI to accomplish this task even quicker. Another way to optimize is to use Steganography, the art of hiding two different digital images inside of each other. However it can be used differently in our case because one texture atlas can become 4 with this method by splitting the image into each RGBA channels and once filled you then take them into a grayscale filter and then re-colorize the textures in the game engine. This method also can be used for every type of mapping system you need. The downside of using this is that once you’ve saved your image you cannot edit the saved file in any way other than temporary file compression. Once the image is made you can’t mess with it because it will ruin the textures and blur them together or worse lock together the channels into a single image. So save and hold onto the editing file for future changes to the Atlas. Combine these with the methods you mentioned and you will have much more textures to work with.

[@Aurailus]

Hey, thanks for the comment! Steganography is definitely a useful technique, but you have to make some pretty strong assumptions about the format of your images, like making sure that they only have one color that you're going to multiply the greyscale texture with. I do plan on baking multiple textures into different channels for PBR & normal images, as they need a lot less bits per pixel to properly represent their data.

[@daniellapain1576]

@@Aurailus Nice I have an image example I go off of that explains every option you can go with for steganography. I have since forgotten the name of whom I received this from but he was in the game industry at the time for a AAA title.

[@Aurailus]

​@@daniellapain1576 ooh, do share!

[@braulee7]

wonderful video good mix of educational and entertaining, i like seeing practical examples so that would be my only improvement

[@Aurailus]

Thank you! I appreciate the feedback. I'll try to include some more practical examples in future videos.

[@orels1_]

Great video! Wish we could do bindless in Unity but they seem to be not interested atm 😔 Was surprised to see such a well produced piece of content for such a small channel. Keep it up! ♥

[@Aurailus]

Thank you so much!!

[@sauce729]

This is great! I've never heard of sparse texture arrays! I mostly write graphics code through Qt's RHI framework that ports graphics code between Metal, OpenGL, D3D, and Vulkan. Unfortunately, it doesn't seem to support this, probably for portability reasons. I'll just have to stick with texture arrays for now.

[@Aurailus]

Hey, thanks for watching! I've heard from some people since publishing that the performance of sparse textures is heavily hardware dependent, which may be another reason that cross-platform frameworks don't bother including it. Texture arrays are quite powerful in themselves if you're working with relatively small textures. I've actually moved away from using sparse-textures in my project, and I'm just allocating max length texture arrays whenever I need more space to put graphics. (I also swapped entirely over to Vulkan, which is the topic of my next video coming out soon! It made it a lot easier to implement bindless-esque texture management.)

[@DonC876]

Really interesting video. I think i will have to investigate further to see how and if i could possibly use that technique in Unity. Though i am pretty sure that for tiling textures especially, you should use the full two float for the texture coordinates, but i can see how this could work for the kind of game/engine that you are working on. Also i usually try to store the indices in vertex color channels since those are byte instead of float (though you're limited to 0-255 range then). Also i would love to see you make a video about bit shifting, since i can't seem to wrap my mind around that completely. The few times i attempted to do that it would always work only 95% of the time. Anyways, instant sub from me :) looking forward to seeing more from you

[@Aurailus]

Hey! Thanks for the kind words!! I actually do have a video on Bit Shifting planned, which will specifically go into Word Level Parallelism, which is one of the coolest techniques I've discovered recently for manipulating data. I'm curious if you can elaborate further on your comments that you should use floats for indexing tiling textures. Is it just because integers will be imprecise? When you refer to storing indices in color channels, I assume you're talking about some sort of pre-set vertex attribute in Unity? If so, that's a smart use of the space that it's already allocating for you! I don't have any unused attributes in my engine, because I wrote it in raw OpenGL, so I have complete control over the vertex layout.

[@DonC876]

@@Aurailus yeah i was talking about precision problems when using less than float for texture coordinates. I noticed that when texure coordinates extend beyond 0-1 range like having a tiling texture across a larger surface it can become noticable. I imagine that's a non issue in a minecraft like game? Yeah i unity basically all other mesh data is full float, except for the Vertex Colors, though i only tested on Oculus Quest maybe it's different on other platforms? That's the bad thing about working with a black box like unity with no source code access. I hope one day i will also be able to get into the nitty gritty and build my own renderer ontop of opengl or vulkan, but till then i'll watch and learn from more talented graphics programmers like you :). Looking forward to the bit shifting video

[@jumbledfox2098]

you are so cool, i hope i make stuff like this one day!! :3

[@Aurailus]

Oh wow, thank you so much!! I honestly have no idea what I'm doing, I just threw out this video to see if it would stick. If you want to do stuff like this, then just do it! You have no way of knowing if it'll catch people's attention until you try!! ❤️

[@DerClaudius]

Good content, so here's some engagement.... Keep it coming...

[@Aurailus]

Thank you, I plan to!! This video has gotten way more interaction than I expected, so I'm pretty hyped to keep going :)

[@optiphonic_]

Your game is looking verry pretty, good luck!

[@Aurailus]

Thank you so much! My next video is going to be laying out my goals and ideas for the game, and I think people are really going to like it!

[@jackthehacker05]

very nice video 👍

[@Aurailus]

Thank you!!

[@mohsenzare2511]

And now you have 1000 sub, nice talk by the way

[@Aurailus]

Thanks!

[@Selicre]

Nice to see youtube pushing smaller creators. You have a very coherent style and presentation already, and as someone interested in bare openGL development this is really useful. However, "irregardless" is not quite what you want to say. It's "regardless".

[@Aurailus]

I have no idea what you mean... I definitely didn't specifically use the double negative form because it annoys people :P

[@Selicre]

@@Aurailus I'm not a prescriptivist, I just don't like auto-antonyms.

[@DogsRNice]

AAA Developers: you bought all that vram don't you want to use all that vram?

[@Aurailus]

Hahaha! We're kinda in a weird place right now where we still usually only have one application heavily using VRam at any given time, so it actually makes sense for all games to utilize it as much as they can. Personally, I want to get a lot of Level of Detail effects into my game to render very distant terrain, and I'll probably be querying how much VRam the host GPU has and filling it up as much as possible :)

[@beamo6264]

great vid!

[@rowmen]

No time wasted! You're just building up your ability to learn the next thing faster!

[@Aurailus]

You're right! I do love learning :) I just wish that I knew to learn the right thing from the start.

[@negrastormentas2865]

Very good video.

[@hyleyy]

Love ur cat images

[@Aurailus]

😸

[@joseph-montanez]

First, thanks, so much great information! I recently watched another video similar using “mega textures” on the Nintendo N64! Second, what program did you use for all these awesome animations?

[@Aurailus]

Thank you!! I think I watched that same video. Kaze Emanuar? It was fascinating. I used Motion Canvas for the animations. It's FOSS and made by a (much better) devlogger on KZbin, Aarthificial. They have a discord server if you want to see more! discord.com/invite/XnnWTrHYAW

[@joseph-montanez]

​@@Aurailus "How I implemented MegaTextures on real Nintendo 64 hardware" by James Lambert is the video.

[@torgath5088]

This is a fantastic video as to an indie developer, but I am using UE5 so I can only find how to use texture arrays, but that's about it for now

[@Aurailus]

Thank you! I would expect a proper game engine to optimize / handle this stuff on its own, but I honestly have very little experience with existing engines so YMMV. Hope you can figure it out!!

[@Gamovore]

That's very interesting, thank you very much! I just discovered this video. May I ask you how you've learned all of that and how you find the motivation to go that deep? Is it your full time job? Trying to sort my life out so I ask other people how they organize themself 😅

[@Aurailus]

Thanks!! I think I kinda cheated, because it feels like my brain just gave me this as my life's purpose. Ever since I first played Minecraft when I was 11, I have had the singular goal to make this project. It drove my learning how to code, going to university, learning pixel art, and pretty much everything I know about gamedev. Unfortunately, I don't have an easy answer for how to get motivation like that, because I feel like I didn't really do anything to get it, it just happened. But I'm happy it did. This isn't my full time job but I hope to make it so! I currently do freelance web development for work while studying computer science in university.

[@curiouspers]

very nice!

[@Tenchinu]

I'm really new at optimization... so I can see myself rewatching this a 100 times while glancing at the extra google tab to actually understand what ur talking about... but I love it!! :) out of total ignorance on my part, how is this implemented in engine? or, do u know of a link that could maybe show how this works in practical terms inside UE5? thnk u for making it fun and informative! keep the education coming!! :)

[@Aurailus]

Hey there, happy you enjoyed the video! I don't work with pre-existing engines so unfortunately I don't have any resources to share on that front. If I were to guess, I imagine they probably handle stuff like this already under the hood. But it can be really valuable to learn about this stuff regardless to get a better idea of how the underlying mechanics of the engine work to deliver the graphics you tell them to!

[@justahuman4862]

Cool video. What engine you using? Also it would be cool to see how to apply what your talking about. Like a video of you going through the process in a real example.

[@Aurailus]

Thank you!! I'm using my own engine, which is build on top of raw OpenGL. My videos are mostly going to be concept-focused, as opposed to specific implementation, I think. But, I stream development of my engine on Twitch every Saturday, and we're currently at the point of implementing these techniques over there! We had a stream yesterday where I discussed Sparse Bindless Texture Arrays in a lot more detail, as well as answered questions about the KZbin video, if you're interested!

[@arbitervildred8999]

I don't remember using any binding in my game, I just load the texture, pass it through the shader to be mapped on the block sides, and just reload the different textures on the same var, load, draw, dispose.

[@Aurailus]

Hi! Super late reply, butthat sounds like it's just a single bind slot! A bind slot is basically just a variable in the shader that you pass a texture into. The problem with bind slots comes in for games that do a lot of mesh generation, and need to render using a lot of textures in one shader call, like voxel games. It's also generally quite slow to swap out textures in a shader, so minimizing that is preferable when struggling with performance. Hope that makes sense!

[@arbitervildred8999]

@@Aurailus I see, you trade memory for performance

[@Aurailus]

Sort offfff, but you should still have all of your textures loaded but not bound, even if you're using regular texture binding. Do you load your assets from disk every frame? If that's the case, you definitely should look into keeping them resident in GPU memory, as that's a ton of wasted time & energy.

[@SwapChain]

Awesome! Please more educational content :)

[@Aurailus]

Thank you!! Will do!

[@Heeroneko]

I dunno if this would be relevant or interesting to you, but I'd enjoy a video covering old texturing techniques like how the og Unreal game did it w those close up texture blends n stuff. The evolution of texture tech would also be interesting to go over, like the evolution of bump mapping n all that stuff up to whatever the hell the UE5 is actually doing.

[@Aurailus]

I'm not super familiar with past rendering techniques, but I might look into it more. I'm really into Kaze Emanuar's Mario 64 modding videos, they go into a ton of detail about how old hardware handles textures and stuff!