Head on over to brilliant.org/TheCherno to learn all of the math you’ll need and support this series! First 200 people will get 20% off their annual premium subscription ❤
It seems like the discount is not being applied properly. Regularly it’s £7.99/month for annual, but following your link Brilliant claims the regular price to be £8.75/month for annual and offers a discounted rate of £6.99.
It’s quite rare that you have a professional in some field also be a good teacher. These two things are rarely compatible but The Cherno manages it quite well👏
I'd absolutely love a video talking about memory managing, padding, pools of memory, stacks... I struggle a lof deciding which things to heap allocate and how to manage their lifetime and fragmentation
Could you make a review on Godot Game engine source code, it's architecture, techniques that they are using etc? Looking you reading other people's code is really exciting.
I think I must have missed this episode originally… Anyway, rewatching all of them as I'd like to pick ray tracing back up as a side project. And one year later I managed to work out how to get Vulkan to run on a mac 😂
You should consider caching your pixel position computation since you call it repeatedly but only access one pixel at a time. This should significantly speed up performance. Also could you cover profiling?
I think it is better to not calculate the light intensity in the closest hit shader since if you implement next event estimation you would need recursion in there. Even though ray tracing GPUs support recursion, AMD to my knowledge only supports a recursion level of two. The only advantage I can see to calculating lighting in the closest hit shader is to write different material shaders for different types of materials and have these in the SBT. Are there other advantages/disadvantages to the two design decisions?
I have used both. The major thing is that if you have different shaders that take a different amount of time or access other resources, the gpu can reorder those rays in a better access pattern; giving you better perf. You'd ofc have to limit recursion, so likely you'd implement a specular and diffuse eval shader and run those hit shaders from raygen shader. Never use real raytracing recursion in closestHit, as like you said AMD doesn't support it, it's slow (ray stack is garbage) and you'd have a limit. If you use a for loop for bounces you'd be able to trace as many bounces as you want
@@nielsbishere Thanks for your reply. Of Course you're right to not use recursion for tracing a path. Where recursion would be necessary is when evaluating the shadow path for next event estimation.
We literally cut our hairs at the same time when ny hair is lonğ then you pista vid with long hair when I go cut it then you post a vid with short hair
Hey guy, I am your fans.recently I am learning your c plus plus series,I think you are interesting and handsome,now become a little fat 😊😊😊thanks for your share !
here is how you can optimize your program right click project and under C/C++ enable Open MP support #pragma omp parallel for collapse(2) for (int y = 0; y < m_FinalImage->GetHeight(); y++) for (int x = 0; x < m_FinalImage->GetWidth(); x++) that way I optimize program from 30 ms to 5 ms
