UNLIMITED textures in your Shaders! (OpenGL tutorial)

Рет қаралды 12,097

Күн бұрын

Пікірлер

@JtagSheep 10 ай бұрын

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.

@GGodis Жыл бұрын

Thank you for a really interesting and clear tutorial! Can't wait to see more.

@lowlevelgamedev9330 Жыл бұрын

thank you 💪 there will be more tutorials whenever I find interesting stuff like this

@xamogxusx 11 ай бұрын

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.

@lowlevelgamedev9330 11 ай бұрын

thanks I didn't know that, I have to look into it

@galloscript 5 ай бұрын

the last shader snippet is missing some line where you assign v_textureSampler = textureSamplerers[whatever_index];, may be a bit confusing.

@Finding_Fortune Жыл бұрын

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 Жыл бұрын

yes precisely + for textures arrays I think you need to recreate the array to add a new texture to it

@KropedStudio Жыл бұрын

ejj we meet again xD

@Finding_Fortune Жыл бұрын

lol@@KropedStudio

@smugtomato5972 11 ай бұрын

@@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

@tokyospliff 8 ай бұрын

Great video man. Why are the handles uvec2 in the fragment shader?

@lowlevelgamedev9330 8 ай бұрын

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

@tokyospliff 8 ай бұрын

@@lowlevelgamedev9330 Nice, makes sense, I thought it might be something like that, very handy.

@tokyospliff 8 ай бұрын

@@lowlevelgamedev9330 is the array of handles bound with glBindBufferBase and GL_SHADER_STORAGE_BUFFER?

@JacobElliottSermons 4 ай бұрын

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!

@lowlevelgamedev9330 4 ай бұрын

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 💪

@TSD_Finance Жыл бұрын

how much harder is Vulkan then OpenGL? Do most things still apply?

@lowlevelgamedev9330 Жыл бұрын

it is much much more difficult. But yes all graphics apis are very similar and you also have something equivalent in vulkan

@tokyospliff Жыл бұрын

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.

@PaulSpades 9 ай бұрын

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.

@lowlevelgamedev9330 9 ай бұрын

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