FAST Random in 3 LINES OF CODE // Ray Tracing series

🧭 FOLLOW ME

📚 Random number articles:

📚 RESOURCES (in order of complexity)

💾 SOFTWARE you'll need installed to follow this series

📚 CHAPTERS
0:00 - What’s the deal with random numbers anyway
4:07 - Series spoilers
5:50 - Your math dealer
7:21 - Easy random number functions
9:50 - Implementation
16:47 - Results

Welcome to the exciting new Ray Tracing Series! Ray tracing is very common technique for generating photo-realistic digital imagery, which is exactly what we'll be doing in this series. Aside from learning all about ray tracing and the math to goes into it, as well as how to implement it, we'll also be focusing on performance and optimization in C++ to make our renderer as efficient as possible. We'll eventually switch to using the GPU instead of the CPU (using Vulkan) to run our ray tracing algorithms, as this will be much faster that using the CPU. This will also be a great introduction to leveraging the power of the GPU in the software you write. All of the code episode-by-episode will be released, and if you need help check out the raytracing-series channel on my Discord server. I'm really looking forward to this series and I hope you are too! ❤️

💰 Links to stuff I use:

This video is sponsored by Brilliant.

[ConfusedNDazed]

All I want for Christmas this year is another video in this series 🎄

[ng.h]

That's wonderful 👍
Please continue this course (Ray Tracing) until the end...❤️
I love to learn Ray Tracing, , ,and your teaching is awesome 👍

[sumikomei]

I've said it before but I really like hearing your thoughts behind things. It's very interesting and helps me a lot, especially as a newer programmer.
I'd also really like to see the switch to compute shaders before moving to dedicated raytracing hardware.

[PawelStoleckiTechArt]

Thanks for the awesome series, looking forward to the next episodes.

[simonfrohlich]

The way you implemented it, the random unit vector is not distributed uniformly on the unit sphere but is more likely to give values further from the axis. Just something to look out for...

[bendev]

Dealing with random devices and stuff deterministically has been a bit frustrating for me lately as I've been building a particle system. The random method you defined here seems like it could be really useful to me in the future! Even though I'm not following along with my own Ray Tracer I really do appreciate the videos in this series. :)

[olavonstad]

13:15, please continue to include those sort of things🙏Gold nuggets, not a waste of time imo😄

[vladmunteanu]

WHERE IS THE NEXT VIDEO! I love this series please continue

[osakaandrew]

I've been studying floating point and assembly optimizations recently and got thinking about your `divide by I know the compiler will find a way to avoid that expensive division in the final assembly, but I'm now hyper-sensitive about using division in code and it got me thinking. You can retain all the integer binary data you get from your `PCG_Hash()` function, then overwrite the top 9 bits (what will become the sign and exponent portions of the float) with (so sign is 0 and exponent is 127), then change the datatype to a float. This will give you a number between 1.000... and 1.999...), so finally subtract 1 to get your random float. You could also get a value between -1 and 1 by changing that bitmask above to not overwrite the sign bit. Again, I know it's stupid to try to outperform the compiler, but I'm pretty sure this would be faster.

[fischi]

Ngl, this series is so great, it takes something that looks insane, and to be honest, if you start from scratch and need to find all the material on your own, it would probably take a long long time. And it just preps it up nicely, step by step, and makes learning about graphics really simple and approachable :)
Also, the videos being 20 mins long makes it really easily digestible :)

[haps]

When is the next video coming out for this series!?

[mastershooter]

Woahhh new cherno video let's goooo, thanks for your C++ and OpenGL series Charno, they've been super helpful!!

[davidcfrogley]

Phew, more than a year after the video originally dropped and I've finally caught up on the ray tracing playlist. It's kind of like reading the latest book from your favorite author and then having nothing to read until the next book is finished, which can take years in some cases. So, looking forward to the next ray tracing video, whenever that appears.

[aloluk]

At 14:30 why dont you take the *2 -1 outside the creation of the vector?

[JakobWesthoff]

Thanks for all the videos. Really enjoying them. The middle step you are talking about, like moving the code to compute shaders at some time in the future, would be something I would be really interested in, as would be a perfect introduction into the idea of using the gpu for this, before making things more blackboxed when moving to the raytracing cores.

[vacuumdiagrams]

I think the biggest problem with the "hacky" implementation of InUnitSphere is it's rather strongly biased towards generating points in the corners of an axis-aligned cube, as opposed to uniformly on the sphere (intuitively, it's comparatively unlikely that you'll generate x and y near 0 with z nonzero than to generate all three points far from 0).

The 'correct' way to generate uniform points on the sphere is to pluck the numbers from a normal distribution and normalize. Box-Muller is popular, but a quick and dirty way that would probably work just fine is to add up a few calls to your uniform generator (3-5 should be enough), so the central limit theorem saves you.

[miroaja]

I hate to be mathematically pedantic about gpu optimized code, however when it comes to generating numbers on spheres the approach shown at 14:15 is not all that good, essentially due to the procedure producing numbers in a cube then normalizing them it causes a really uneven distribution of points along lines on the sphere where the edges and corners of the cube project to (imagine as if there being more space to put points there than along the centers of faces, thus less even). To fix this clumping you should be using a normal distribution, which is radially symmetric, thus eliminating this whole square issue. There are some gpu implementations of normal distributions, and after some quick SO skimming it seems they're generally speaking pretty fast too!

[alexsemm]

Really enjoying the series so far, i am actually already somewhat hyped for when we start going to our gpu. This series is really great!

[szirsp]

12:45 I feel like using is just using UINT32_MAX with extra steps :)
(Technically it's not because UINT32_MAX is declared in stdint.h and is using UINT_MAX which is in limits.h when int is 32 bit, but still it's mostly just more work for the compiler and and the developer to write/read.)
To make it more C++ like (and actually more useful) I would suggest writing:

...which would allow changing the seed type without touching the function body.

[arnedebeer]

Eeyo, keep them coming! Really looking forward to see where the series is heading 🔥