Fragment Shaders are “just” special programs that determine the color of a pixel. What makes them complicated is that we are doing more physically accurate calculations of light. 2D shaders are a great way to learn them. ShaderToy is a great place to see 2D, 3D, and compute shaders.
Lovely, its refreshing to see such low level implementations still happening. I think this kind of work that can open up the gates for new way of doing stuff, instead of relying on premade game engines.
Thank you that's a lovely complement. One of the coolest things I've found from making these videos is finding out other people are also making their own tech which is awesome, like you man. I live for making my own tech it's the only way I will make games.
Bevy engine looks cool, it's made in Rust too! Yeah I highly recommend vulkan, even though it's difficult but it's certainly worth it all works. I hope you're project is going well Robert.
Command in command buffers are, in fact, NOT executed sequentially. That's why you explicitly synchronize different passes because otherwise, GPU can reorder the work in the way it likes. But overall, good video, keep it up man!
Brilliant! This is partly why I'm making these videos to find people who can give me corrections/feedback. Right that makes a lot of sense, at this point in the renderer, I had 1 pass. So I thought that if I just submit the command buffers to the queues they and they just run in order as they were submitted. Right now I'm building up the different passes I want to have to have different effects. I will pay close attention to what happens once I've finished parsing the sorted graph (DAG) that is the frame graph. Thanks for the correction my man.
Good question. I started coding in legacy OpenGL, so way before vulkan existed. If were starting from scratch I wouldn't try to learn OpenGL first if your end goal is to learn vulkan, even though there is some cross over, I would just start with vulkan. I'm still learning vulkan and I'm by no means an expert but because vulkan is hard my approach to learning vulkan have been code it first, then really study what I've after. Like with memory layout for example. You can use the vulkan tutorials I linked in the description, type them up and then really dig into what the memory layout means in the context of the tutorial you've just learnt.
As a Vulkan enthusiast, I thoroughly enjoyed this talk on the Vulkan API! Does the book you recommend ("Mastering Graphics Programming with Vulkan") explain how multithreading works in a beginner-friendly way, or should one first practice multithreading in a simpler context than Vulkan?
Thank you! I'm glad it was enjoyable. Yes, I would say so it introduces task and fibre based threading systems and then talks about how to implement a task based one with vulkan tasks. I found I still needed to study things outside the book like listening to talks and asking other programmers about threading to understand what was going on exactly.
@@EscPointDev Sounds good. Thanks for the reply. I've been looking for a good Vulkan book recently, so I'll check it out. Amazing stuff, Keep it coming!
@11:16 you need tonemapping 😄. Super simple to implement, and the result will look soo much better xD. Easiest tonemapper: Reinhard, xyz / (1.0 + xyz) My favourite easy one: Adjusted Reinhard, xyz / (1.0 + max(x,y,z)) The one I use in my game engine: convert sRGB to linear, Adjusted reinhard, plus mixing towards white with very bright colors, back to sRGB.
Thanks for pointing that out to me, I hadn't heard of that before, it seems simple enough to add I will give it a shot. I'm hoping that once I finish this frame graph that I'm working on I will start being able to fix these type of things. Since this was done in one pass. Thanks for the feedback my man, I very much appreciate it
your tone mapping is a naive approach,it costs gpu performace but the importance is it can't provide other color tonalities.I use some smart way for the mapping without gpu to do it because i did precompute the thing using materials and then i even have unlimited color profiles.Your solution only make all bring red to white but can't make it to yellow or anything else conveniently enough at modeling stage.
@@lanchanoinguyen2914 You still have to map HDR values to a finite amount/interpolated one. What do you do instead? sdr = lut[hdr/(1+hdr)]?, lut being a 3d texture
I see you have something like "dynamically recreate descriptor sets", I advise you to look into bindless it will be much more convenient, so you have only 1 descriptor set per frame with N bindings(like samplers, textures, images, whatever you want.)
I think that might been earlier on, I do now have bindless support. I also have a fall back option for older GPUs. That's a great way of describing bindless by the way :D
@@EscPointDev Yeah, keep it up wanna see where it goes next, something tells me you gonna build the high-performant multithreaded vulkan renderer I've been dreaming of (: edit: Also my previous experience with multithreaded secondary command buffer recording shows that it only pays off, if only time(literally sync point) that you wait after the recording on all threads isn't that high(otherwise your single core perf better), so you don't waste your CPU time on syncing your threads, but utilizing the actual load.
@@absorbingdude Thanks dude! I will continuously keep learning and coding to do the best I can. Although from what I've seen from your stuff, you might beat me to it. Yes, that's why I went with the task based threading system. It avoid the synchronisation of threads. Assuming the tasks aren't too dependent on other tasks you can just throw them on the work queue and fire away. Thanks for the heads up.
I will, I'm likely going to go with the technique of dividing up a something like a cylinder which will be the players collision geometry into 3 sections, the very bottom section that contains the just the feet wont collide with any level geometry so you don't get stopped by tiny stones or bumps. The next section will push the player up and will be for things like stair which and this will follow from the bottom section of the cylinder which will likely go up the knee height of the player. Finally the rest of the cylinder will be solid so you can't watch through walls or other obstacles. This might change depending on the type of game I eventually want to make.
Frankly, I didn't understand most of the stuff you are talking about here. And I can bet vast majority of other people either. If you are talking about the code, it would be nice to show some of the code at least. Otherwise everything gets mixed up and it's not clear what are you talking about here. Or drawings at least. Don't show the engine footage if there is nothing interesting happening there.
Thanks for the criticism! Someone else who watched this video had more or less the same criticism. I want to make the video visually interesting for the people who don't know a thing about coding but in the next one I certainly want to add more drawings and maybe I will show more code. I will work on my writing too to try and nail the explanation.
@@EscPointDev good to hear that. I'm definitely waiting for that because just the things you talk about here, have very nice learning potential and value.
@@nan0s500 Thank you, I will give it my all. One of my major goals with these videos is help the younger version of myself who could've used vidoes likes these when I was starting out. So I very much appreciate your comment.
Ive always been amazed by people who understand shaders.
Thanks man
yae
Real...
Fragment Shaders are “just” special programs that determine the color of a pixel.
What makes them complicated is that we are doing more physically accurate calculations of light.
2D shaders are a great way to learn them.
ShaderToy is a great place to see 2D, 3D, and compute shaders.
Shaders are just programs that work on your vertices or pixels.
Just the for-loop is hidden, the rest is pretty much the same.
Lovely, its refreshing to see such low level implementations still happening. I think this kind of work that can open up the gates for new way of doing stuff, instead of relying on premade game engines.
Thank you that's a lovely complement. One of the coolest things I've found from making these videos is finding out other people are also making their own tech which is awesome, like you man. I live for making my own tech it's the only way I will make games.
Super cool stuff! I'm working in Bevy engine, but I can't help but feel I'll end up learning Vulkan at some point.
Bevy engine looks cool, it's made in Rust too! Yeah I highly recommend vulkan, even though it's difficult but it's certainly worth it all works. I hope you're project is going well Robert.
Neat, I'm currently on go with ebiten, I will definitely checkout bevy after it reaches 1.0, before that I want to play around with XNA/FNA/monogame
Command in command buffers are, in fact, NOT executed sequentially. That's why you explicitly synchronize different passes because otherwise, GPU can reorder the work in the way it likes.
But overall, good video, keep it up man!
Brilliant! This is partly why I'm making these videos to find people who can give me corrections/feedback.
Right that makes a lot of sense, at this point in the renderer, I had 1 pass. So I thought that if I just submit the command buffers to the queues they and they just run in order as they were submitted. Right now I'm building up the different passes I want to have to have different effects. I will pay close attention to what happens once I've finished parsing the sorted graph (DAG) that is the frame graph. Thanks for the correction my man.
Did you jump straight into Vulkan, or did you start out with something like OpenGL?
Good question. I started coding in legacy OpenGL, so way before vulkan existed. If were starting from scratch I wouldn't try to learn OpenGL first if your end goal is to learn vulkan, even though there is some cross over, I would just start with vulkan. I'm still learning vulkan and I'm by no means an expert but because vulkan is hard my approach to learning vulkan have been code it first, then really study what I've after. Like with memory layout for example. You can use the vulkan tutorials I linked in the description, type them up and then really dig into what the memory layout means in the context of the tutorial you've just learnt.
As a Vulkan enthusiast, I thoroughly enjoyed this talk on the Vulkan API! Does the book you recommend ("Mastering Graphics Programming with Vulkan") explain how multithreading works in a beginner-friendly way, or should one first practice multithreading in a simpler context than Vulkan?
Thank you! I'm glad it was enjoyable. Yes, I would say so it introduces task and fibre based threading systems and then talks about how to implement a task based one with vulkan tasks. I found I still needed to study things outside the book like listening to talks and asking other programmers about threading to understand what was going on exactly.
@@EscPointDev Sounds good. Thanks for the reply. I've been looking for a good Vulkan book recently, so I'll check it out. Amazing stuff, Keep it coming!
@@suras8849 No problem. Yeah it's a great book if you already know some vulkan. Thanks :) I will keep working hard on it.
engine performance after you said vulkan and cpp ++++++++++++++++++++++
Thanks! Yeah I'm gonna try and make this as fast as I can.
@11:16 you need tonemapping 😄. Super simple to implement, and the result will look soo much better xD.
Easiest tonemapper: Reinhard, xyz / (1.0 + xyz)
My favourite easy one: Adjusted Reinhard, xyz / (1.0 + max(x,y,z))
The one I use in my game engine: convert sRGB to linear, Adjusted reinhard, plus mixing towards white with very bright colors, back to sRGB.
Thanks for pointing that out to me, I hadn't heard of that before, it seems simple enough to add I will give it a shot. I'm hoping that once I finish this frame graph that I'm working on I will start being able to fix these type of things. Since this was done in one pass. Thanks for the feedback my man, I very much appreciate it
your tone mapping is a naive approach,it costs gpu performace but the importance is it can't provide other color tonalities.I use some smart way for the mapping without gpu to do it because i did precompute the thing using materials and then i even have unlimited color profiles.Your solution only make all bring red to white but can't make it to yellow or anything else conveniently enough at modeling stage.
@@lanchanoinguyen2914 You still have to map HDR values to a finite amount/interpolated one.
What do you do instead?
sdr = lut[hdr/(1+hdr)]?, lut being a 3d texture
I see you have something like "dynamically recreate descriptor sets", I advise you to look into bindless it will be much more convenient, so you have only 1 descriptor set per frame with N bindings(like samplers, textures, images, whatever you want.)
I think that might been earlier on, I do now have bindless support. I also have a fall back option for older GPUs. That's a great way of describing bindless by the way :D
@@EscPointDev Yeah, keep it up wanna see where it goes next, something tells me you gonna build the high-performant multithreaded vulkan renderer I've been dreaming of (:
edit: Also my previous experience with multithreaded secondary command buffer recording shows that it only pays off, if only time(literally sync point) that you wait after the recording on all threads isn't that high(otherwise your single core perf better), so you don't waste your CPU time on syncing your threads, but utilizing the actual load.
@@absorbingdude Thanks dude! I will continuously keep learning and coding to do the best I can. Although from what I've seen from your stuff, you might beat me to it.
Yes, that's why I went with the task based threading system. It avoid the synchronisation of threads. Assuming the tasks aren't too dependent on other tasks you can just throw them on the work queue and fire away. Thanks for the heads up.
please make climbing stairs easy
I will, I'm likely going to go with the technique of dividing up a something like a cylinder which will be the players collision geometry into 3 sections, the very bottom section that contains the just the feet wont collide with any level geometry so you don't get stopped by tiny stones or bumps. The next section will push the player up and will be for things like stair which and this will follow from the bottom section of the cylinder which will likely go up the knee height of the player. Finally the rest of the cylinder will be solid so you can't watch through walls or other obstacles.
This might change depending on the type of game I eventually want to make.
Frankly, I didn't understand most of the stuff you are talking about here. And I can bet vast majority of other people either.
If you are talking about the code, it would be nice to show some of the code at least. Otherwise everything gets mixed up and it's not clear what are you talking about here. Or drawings at least.
Don't show the engine footage if there is nothing interesting happening there.
Thanks for the criticism! Someone else who watched this video had more or less the same criticism.
I want to make the video visually interesting for the people who don't know a thing about coding but in the next one I certainly want to add more drawings and maybe I will show more code. I will work on my writing too to try and nail the explanation.
@@EscPointDev good to hear that. I'm definitely waiting for that because just the things you talk about here, have very nice learning potential and value.
@@nan0s500 Thank you, I will give it my all. One of my major goals with these videos is help the younger version of myself who could've used vidoes likes these when I was starting out. So I very much appreciate your comment.
would you be interested in making me a game, it's very simple, what can i get for a thousand dollars?
Yeah totally. Making games is so fun, I do it for nothing.
@@EscPointDev for real? i have a video called "elevator pitch for my game" the ground work is 15v15 capture the flag on a soccer field
hopefully it's browser based, but doesn't have to be
@@rexoverwatch That honestly sounds like a lot of fun to play. I would certainly check that out :D
@@EscPointDev thanks, and to be honest, i would prefer no graphics,,, just capsules and lasers :)
command buffers.
Yep, it's all about setting up the command buffers correctly with multi-threading.