BEST WAY to understand graphics and rendering code
Вставка
- Опубліковано 13 тра 2024
- To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/TheCherno. The first 200 of you will get 20% off Brilliant’s annual premium subscription!
Patreon ► / thecherno
Instagram ► / thecherno
Twitter ► / thecherno
Discord ► / discord
Hazel ► hazelengine.com
🕹️ Play a game we made in Hazel for FREE ► studiocherno.itch.io/dichotomy
🌏 Need web hosting? ► hostinger.com/cherno
🔗 LINKS
Code ► github.com/Eduard0110/Path-tr...
RenderDoc ► renderdoc.org/
Nvidia Nsight ► developer.nvidia.com/nsight-g...
💰 Links to stuff I use:
⌨ Keyboard ► geni.us/T2J7
🐭 Mouse ► geni.us/BuY7
💻 Monitors ► geni.us/wZFSwSK
This video is sponsored by Brilliant.
Thanks for watching - hope this was helpful to those spelunking through graphics projects!
Don't forget you can try everything Brilliant has to offer-free-for a full 30 days - just visit brilliant.org/TheCherno. The first 200 of you will get 20% off Brilliant’s annual premium subscription!
we love you cherno
Been waiting for a RenderDoc showing! Learned about it in university, but didn't get much but basic exposure. Thanks Cherno!
This is really useful! Many years ago i wrote a SPH Fluid Simulator (Fluid Sandbox) and was rendering it with OpenGL using a complex image based fluid rendering technique. Without the help of such tools like render doc or nsight, i propably never could have finished it, because finding and fixing rendering bugs is extremely hard without looking at the actual internals.
So again, extremely useful! Thanks for reminding and showing us this ;-)
This is really awesome. I'm learning OpenGL and I was looking for a way to properly debug the rendering stuff. This video helps me a lot. Thanks Cherno!
It's great to see you're back, making videos again 🎉❤
I've often thought it'd be nice to have a graphical viewer showing a tree view from a function. That is - click on a function, and choose "show tree" and it would have the function as the root node, splitting off into functions that function calls, with them splitting the same way. It would then be simple to visualise it without potentially having to skip between files. Clicking on a node could show the variables, types etc used there, with links off to them as sub-nodes too. I'd like it anyway! It would be even nicer if it also worked while debugging, to show the values, and calls that might not be known at compile time.
Try chartographer for visual studio code, it does this, and appears to be language agnorstic (I use it for C++)
There used to be an open source tool that did almost exactly what you have described but they stopped developping it. It was called sourcetrail. I liked it a lot for looking at large, unfamiliar code bases
Technically your run of the mill debugger does that via stack traces. Set a breakpoint somewhere in the code - run it in debug mode, ensure it hit the breakpoint, inspect the stacktrace. Obviously is not 'graphical' but I don't think it would particularly help, since code is text. If you really wanted to do you could dump the stacktrace and then write a small generator that creates boxes and what not, but I don't see the point imho.
It gets more complicated with many threads, but you can still get some good insight.
@@sergiuferentz9125 yeah I’e been using debuggers for over 30 years. Pretty familiar with them. For examining code though a graphical interface appeals to me a lot. Hopping from file to file to file is not a great experience, or even very efficient really.
Thank you! Thank you! Thank you! Thank you! I have been encountering some incredibly frustrating bugs in my renderer (including one right now) and this tool has already proved to be very useful.
Thank you, @The Cherno, for showing me this. It looks amazing, and I am hoping they are evolving it to include generative transformers as well.
thank you!
One more time
We love you cherno
great video, just great
thank you. the cherno channel...goodluck
I didn't read the code, but maybe that bloom texture is just a map for which pixels are above the bloom threshold and then it takes the actual values from the other texture? That would explain why it only has 0 and 1 as values.
How in the world do you start coding something like the project in the video? College doesn't go into this at all. We haven't even learned about i/o and i'm 1 class away from my associates (which is algorithms).
I feel like the answer to this question will solve a lot of my confusion. Thanks in advance.
You can just find some tutotials in Google and follow them or even copy-paste all the code trying to figure out what is going on there
Self study. You have to go beyond the university. I don't know a single graphics programmer who was spoon-fed in the uni, even though it would be nice, especially if the specialization is graphics-related, but the reality is that everyone grinds it themselves.
@@pavlo2692 This guy graphics.
Computer science is less focused on the mechanics of actually programming and moreso focused on understanding the theory behind how and why computers work in the first place.
Even if your degree is focused on the more technical programming end of the spectrum though, it will not reach you much beyond the absolute bare minimum you need to self-learn everything else.
Being a programmer means committing to self-learning massive amounts of information, because no matter how long you spend in class you'll always need to self-learn once you get out.
I want to try to answer your question though. It heavily depends on your goals, but I assume you want to gain expertise in graphics and get comfortable with it, so you'll try to build your own stuff. There are three sides of this in my opinion - programming experience, knowledge of graphics-related concepts, and "fluid" intelligence that is developed by solving similar problems.
Example: I want to build a raytracer. I can go read "Raytracer over the weekend"(or smth like that) or I can read about raytracing algorithm and code it myself (ultimate goal I suppose?). Well, in order to code it yourself you need to have an intuition for it that is developed from solving similar but easier problems. Try to make a small game, draw triangle in OpenGL, maybe try reimplementing DOOM-style rendering when you get to this point. Just by investing yourself in these topics, you will learn lots of concepts that are close to graphics programming.
Don't get me wrong though, it's not bad to watch tutorial for a thing you want to build, but just make sure that you don't need it next time you want to improve your program. So don't hesitate to read stuff like "Raytracer over the weekend"(or smth like that), but try to make the most out of it.
I hope it helps! Maybe it's obvious and I'm learning myself, but this sort of approach really helped me improve faster.
Interesting as always. I started using Intel's Graphics Monitor suite several years ago - and now kind of regret not finding the open source equivalents before embedding GPA into my toolset. Maybe I'll make the effort and switch - as it would be (possibly...) easier to extend the open source tool (which is why I'm starting to think about learning C++) rather than fight with Intel's tools to get the output I want. Thanks for the videos.
Hi cherno!
Interesting video. Was cute to hear you saying that after 13 years you don't like to read code to troubleshoot and investigate :) I've been doing this as my daily job for more than 25 years and nobody really read code by itself because it doesn't really make much sense, unless you are looking at a small program. For most part you use tools, disassemblers or tracers and step into the code with breakpoints.
also as far as rendering, the pipeline is for most part the same no matter what engine you use; so if you know that there is a set of passes for each layer and then everything goes to the compositing engine, you can derive the flow of the data more easily. Each company of course makes their own engine and workflow for it, but at its core, you render by making passes and compose the image in an aggregator in the end... All the roads lead to Rome after all :)
There are also plenty of open source engines that are great for learning how 3d rendering works; so many times there is not even a need to go hacking into an application to figure things out (unless you want to know how THAT application is actually working).
> the pipeline is for most part the same no matter what engine you use
Oof - that may be true in OpenGL but now with Vulkan/WebGPU becoming a thing, you will have custom pipelines so every application can technically customize it completely to fit its own purpose. Sure, some steps will be the same and knowing the standard rendering pipeline as laid out in GL will take you 80% of the way there, at least for the time being.
@@sergiuferentz9125 That is a valid point, but even so, you can use Vulkan and standard pipeline still and get what you need.
The whole point why OGL and DX were created was so people don't need to learn 2300 APIs to put a pixel on screen; as it used to be before those (and before Glide, if you remember it) were made.
So standardize the pipeline is something that eventually will happen no matter what.
Then for anything more "exotic", of course it is an unexplored and uncharted area; but that is what makes it interesting in the end
RenderDoc is a really helpful tool! I recently finished my master's thesis with OpenGL and it helped me a lot, especially with the ability to read data from buffers. Another modern capability that is very useful is the breakpoint debugging feature. It's unfortunately only usable with Dx12 and Vulkan, but if you can enable it, it's certainly next level shader debugging. :D
With the RGB8, couldn't we use a switch case? Basically, if N×1, if N×1.1, if N×1.2, etc. This way we can make a short spectrum instead of just a boolean of white or black?
I think your main obstacle with this is that files longer than 200 line probably should be balkanized.
Any idea on how to profile with RenderDoc with Vulkan on MacOs ( with MotlenVK) without using Xcode ?
RenderDoc doesn’t specifically list MacOs as a fully supported platform, as of now unfortunately. The only viable option might still be Xcode’s GPU debugger
Don't worry about the side tracking, it is what you do.
i can't get the nintendo switch version to work because i don't have keys to reencrypt it to run on a hacked retail switch, and i don't have a devkit
anyone know the VS theme he used ?
i think its the theme that comes with the Visual Assist plugin
It would be nice a code review of HandMade Hero source code..
This game you made, I downloaded it. It lags a lot on Windows, doesn't have a menu to leave, doesn't have ability to stop the timer or doesn't stop when you reach end of the level. It's really bad.
RayTracing series continuation when
hi cherno i am just 15 years old and want to learn grapgics writing and making game engines with c++ but i dont know where to start i know c++ to vectors and a little of pointers Is there any tutorial series you can recommend me or direct suggestions? and what library should i use? i am using clion my school has the licence so with cmake my teacher tells me to use vs if its a big project but vs looks bad for me and i want to clion but i cant understand cmake
Cherno has a long C++ tutorial series for C++ and one for OpenGL and one for Game Engine programming, so check his playlists
@@ChrisBrown-dn3tf thank you
early enough the title is stuttering.
"to to"
Thanks for the video, but debugging an app is different from understanding it. To understand graphics and rendering code, there are no shortcuts, and more often than not, we have to refer to theoretical background and understand the main idea before attempting to comprehend the code itself.
the ppl in renderdoc chat get super angry if you ask about programs you have no business tracing.
if you publish games plz include a license for debugging.
Focous more on game engine series
better do first time correct so that you dont create secondary work in vain for other people or yourself, there is another way instead of the screen space light accumulation btw, yep light mapping accumulation on the objects, I hate most screen space algorithms, not actual global persistent illumination.
My pet peeves are coders 1) not knowing how to use debugger properly, 2) not knowing how to use profiler, 3) not knowing how toolchain works (i.e. how your code compiles) and 4) not knowing build tooling like CMake, premake, meson or something like that. As a C++ bonus, header including headers including headers until your build takes an hour.
I'd say that it looks like each function definition is trying to do too much. Ideally you shouldn't have a function that runs more than a couple paragraphs. That code is a mess. But there's definitely a difference between code that works and otherwise.
stop stealing videos from other creators
Do you even know who the hell you talking to?
@@caitlyn8415 get lost, hater
he isn't going to steal any content from other creators.
what?
@@Daniel-ww2io the only one hating here is you