If you dont care about having to bind textures and dont care about supporting old OpenGL version then you can just use new GL calls like glCreateTextures(GL_TEXTURE_2D, 1, &texId); and glBindTextureUnit(slot, texId); Still giving you tons of textures since you choose what is bound when.
The description of residency and nonresidency is wrong. You are not loading anything from memory. You are telling OpenGL driver how to do low level synchronization, same way you do by binding to units.
Cool! I suppose the advantage of this over say a 2D texture array, is that all of the textures could be any size versus a texture array only handles textures of one size?
@@lowlevelgamedev9330 No, you can just add data to the buffer with glTexSubImage3D. Assuming you've allocated enough space for your texture array in the first place of course
good question, the handle needs to be an unsigned 64 bit int, to acces the texture, however you can't have 64 bit numbers without another extension, so this extension allows you to use a uvec2 aka 2 32 bit ints to use as one 64 bit number
Ridiculously more difficult, but I do recommend spending 6 months to a year in Vulkan. It forces you to structure things and interact with the GPU efficently and when you return to OpenGL you will be writing much better code because of it.
That's nice and all, but the GPU still has a limited number of TMUs, maybe 8, maybe 256. You are limited to that number, for each draw call, not because openGL wants to limit you, but because that's what the physical hardware is. Second, if you bypass the binding, you don't get access to the most compute intensive function the GPU (at least in games), which the TMU does - the filtered sampling. Bindless textures was a technique developed for feeding compute shaders(or all unified shaders) with arbitrary data. That's what you should use it for. If you want more textures than your player has texture unit hardware, you simply use more shader programs with different texture sets. Game engines typically bundle shader porgrams+textures as a data structure called a material.
this is kinda of a bold claim so I will have to investigate, as far as I know bindless is the modern way to go and for example ID7 engine switched from its mega texture from ID6 (and that thing is not easy to implement) and now they go with a fully deferred material system that uses bindless textures. But I don't use bindless to acces more textures but to be able to draw more without having to bind a different uniform each time, so maybe the title is missleading
Hey @Low Level Game Dev, I am so confused about shaders with OpenGL/C++: Is there any good documentation on *how many* shader programs you need when making a custom 3D engine? I.e, do you have a shader program for each type, like grass blades and rocks, but also different shader programs for different types of grass and rocks, etc? To me, this should be addressed when learning OpenGL and shaders, but I haven’t found anything so far directly addressing it. Do you know a direction you could point me in? I figure to ask you, because you get the reason for wanting to make your own custom 3D engine like I want to!
yo so this is a difficult question, so first of all, read some render studies like Doom eternal / Doom 2016 render study, you can also find resources like that on my discord or you can tag me there if you want to ask me more questions. Ok so basically you will probably have one shader per feature, like for bloom you need one shader to blur, and another one to apply the bloom, and a shader of chourse can apply multiple things so for the post process step you will have probably one shader to do it all in the end. Now for rendering things, in general it's good do not have too many shaders because switching the shader can get expensive, so doom eternal has for example an uber shader that knows how to draw any type of geometry, and they do it all in one draw call using some cool tricks, (that you can read in that articles) so you can for example have a basoc shader for most things like most objects, and maybe a few shaders for special effects. You also don't want your shader to get too big cause it can cause performance problems but thats already an advanced topic, remember to always measure the speed when testing performance 💪
If you dont care about having to bind textures and dont care about supporting old OpenGL version then you can just use new GL calls like glCreateTextures(GL_TEXTURE_2D, 1, &texId); and glBindTextureUnit(slot, texId); Still giving you tons of textures since you choose what is bound when.
Thank you for a really interesting and clear tutorial! Can't wait to see more.
thank you 💪 there will be more tutorials whenever I find interesting stuff like this
The description of residency and nonresidency is wrong. You are not loading anything from memory. You are telling OpenGL driver how to do low level synchronization, same way you do by binding to units.
thanks I didn't know that, I have to look into it
the last shader snippet is missing some line where you assign v_textureSampler = textureSamplerers[whatever_index];, may be a bit confusing.
Cool! I suppose the advantage of this over say a 2D texture array, is that all of the textures could be any size versus a texture array only handles textures of one size?
yes precisely + for textures arrays I think you need to recreate the array to add a new texture to it
ejj we meet again xD
lol@@KropedStudio
@@lowlevelgamedev9330 No, you can just add data to the buffer with glTexSubImage3D. Assuming you've allocated enough space for your texture array in the first place of course
Great video man. Why are the handles uvec2 in the fragment shader?
good question, the handle needs to be an unsigned 64 bit int, to acces the texture, however you can't have 64 bit numbers without another extension, so this extension allows you to use a uvec2 aka 2 32 bit ints to use as one 64 bit number
@@lowlevelgamedev9330 Nice, makes sense, I thought it might be something like that, very handy.
@@lowlevelgamedev9330 is the array of handles bound with glBindBufferBase and GL_SHADER_STORAGE_BUFFER?
how much harder is Vulkan then OpenGL? Do most things still apply?
it is much much more difficult. But yes all graphics apis are very similar and you also have something equivalent in vulkan
Ridiculously more difficult, but I do recommend spending 6 months to a year in Vulkan. It forces you to structure things and interact with the GPU efficently and when you return to OpenGL you will be writing much better code because of it.
That's nice and all, but the GPU still has a limited number of TMUs, maybe 8, maybe 256. You are limited to that number, for each draw call, not because openGL wants to limit you, but because that's what the physical hardware is.
Second, if you bypass the binding, you don't get access to the most compute intensive function the GPU (at least in games), which the TMU does - the filtered sampling.
Bindless textures was a technique developed for feeding compute shaders(or all unified shaders) with arbitrary data. That's what you should use it for.
If you want more textures than your player has texture unit hardware, you simply use more shader programs with different texture sets. Game engines typically bundle shader porgrams+textures as a data structure called a material.
this is kinda of a bold claim so I will have to investigate, as far as I know bindless is the modern way to go and for example ID7 engine switched from its mega texture from ID6 (and that thing is not easy to implement) and now they go with a fully deferred material system that uses bindless textures. But I don't use bindless to acces more textures but to be able to draw more without having to bind a different uniform each time, so maybe the title is missleading
I guess I won't be watching at 2x
😂😂😂😂 yeah bro that's my slow speed btw
😂
Hey @Low Level Game Dev,
I am so confused about shaders with OpenGL/C++: Is there any good documentation on *how many* shader programs you need when making a custom 3D engine? I.e, do you have a shader program for each type, like grass blades and rocks, but also different shader programs for different types of grass and rocks, etc? To me, this should be addressed when learning OpenGL and shaders, but I haven’t found anything so far directly addressing it. Do you know a direction you could point me in? I figure to ask you, because you get the reason for wanting to make your own custom 3D engine like I want to!
yo so this is a difficult question, so first of all, read some render studies like Doom eternal / Doom 2016 render study, you can also find resources like that on my discord or you can tag me there if you want to ask me more questions. Ok so basically you will probably have one shader per feature, like for bloom you need one shader to blur, and another one to apply the bloom, and a shader of chourse can apply multiple things so for the post process step you will have probably one shader to do it all in the end. Now for rendering things, in general it's good do not have too many shaders because switching the shader can get expensive, so doom eternal has for example an uber shader that knows how to draw any type of geometry, and they do it all in one draw call using some cool tricks, (that you can read in that articles)
so you can for example have a basoc shader for most things like most objects, and maybe a few shaders for special effects. You also don't want your shader to get too big cause it can cause performance problems but thats already an advanced topic, remember to always measure the speed when testing performance 💪
THANK YOU SO FUCKING MUCH I LOVE YOU
glad you found it helpfull 💪💪
what so why my game engine has unlimited texture storage (i tink it is cus i'm using a custom texture implementation)
because they do something like this. Also it is possible to have unlimited textures without this, but not use all of them at the same time
Any ways on DirectX?
yes, I don't know dorectx but there should be one for directx also, I think bindless resources are available starting with directx12
I used it in my research of image synth in 2018. one of the best extension in OpenGL.
note that mobile does not support this.
Actually, VRAM is probably for Video RAM, not for Virtual memory here
wait did I say Virtual memory? sorry for that 😅