I love how you explain code and shows us your little mistakes in there as well. It shows the natural thought process and shows that even you are human (even though you create these wonderful visualisations). Amazing work!
Wow, that’s very-very cool, I love it. It’s fun to see how things that are sometimes explained as if they were relatively simple are, in fact, not at all. ‘Cause firstly you think they are complicated, then somebody says “look, it’s easy!”, then you wonder why it doesn’t work as nice as it should, in the end realising it was never simple
You know it's good when the youtuber pulls out the research paper. I love this channel so, so much. Makes me wanna go out and write some code just because how fun it makes it look!
Awesome work. Wouldn't you ideally just calculate the BVH when importing a mesh into your project and store the data with the mesh, instead of having to redo it every time the program runs? Baking it, if you will
Haha, I didn't even notice that, Jacco is a former colleague of mine, back from when I worked at Davilex Games, small world indeed. Really interesting video, I've been creating some real-time ray-tracing shaders, but nothing using triangles yet.
Which is the correct starting point of any performance optimisation with code. NEVER just assume you know what is slowing the program down. Measure the performance „in action“. Then you start your changes.
For your next coding adventure you should try some multiplayer sync stuff if you haven't already. I recently have gone down a rabbit hole of different types of network sync models and there is still a lot of nuance that is left ambiguous in even the most detailed blog posts. Something that I would personally love to see.
@@SebastianLague yeah I always wondered how all of the battlefield games were able to host 64 players, events, vehicles, explosions with pretty good efficiency (benchmarked with my old crappy wifi connection) and all of that good stuff:)
these coding adventures get more and more complex. I reckon Sebastian's working on something big, but first has to learn every technique to its fullest before starting and then finishing it
Hey Sebastian, cool video! There's a slightly different approach that would let you try every possible cut in the SAH without too much additional cost. Right now you're evaluating each cut by looping over all the triangles (O(N*K) cost for N triangles and K cuts), but this does not take advantage of previous evaluations. Imagine you sorted the triangles along one of the axis, then computed and stored the bounding box of each prefix and each suffix of the triangle list. Now you can evaluate each cut in constant time (child A corresponds to a prefix of the list and child B to a suffix). Sorting has cost O(N log N), but then you can try all the cuts along that axis in O(N) time. Overall, the cost is O(N log N), which should be much better than O(NK) for large values of K. Here is an outline of the general approach: sort tris along the x axis prefixes = array of length n prefixes[0] = bounding box of tri[0] for i = 1 to n-1, assign prefixes[i] = bounding box union of prefixes[i-1] and tri[i] suffixes = arraay of length n suffixes[n-1] = bounding box of tri[n-1] for i = n-2 to 0, assign suffixes[i] = bounding box union of suffixes[i+1] and tri[i] for i = 1 to n-1, the cost is i*surfaceArea(prefixes[i-1]) + (n-i)*surfaceArea(suffixes[i]) As described, the idea involves performing three sorting operations at each node of the tree, but this is not strictly necessary. If you sort all the triangles along the three axis just once at the top level, it's possible to preserve the order as you go down the tree construction algorithm. This might be too complicated to implement while keeping the code readable, though.
My absolute favorite part of your videos is that the tone of your voice is like you are _smiling_ while speaking. I do not know why, normally I would consider it condescending, but from you it sounds _honest_ People who code well are rare. Equally rare are people who can explain well. People who can do _both_ are exceedingly rare. You deserve every bit of praise you get.
That was awesome. One of the structures I've used in the past when I have all the data ahead of time is a Sort-Tile-Recursive (STR) R*Tree. You sort the data in space first, then build the tree from the bottom up. The result is a very well balanced tree that is extremely quick to query. You then set the maximum number of children in a leaf, so you get even performance. I don't know if the query times would speed up that much after your final iteration, but my guess is, the build time would be infinitely quicker. As always, just an extremely informative and entertaining video!
Very impressive results, bravo. I keep being in awe by how you manage to make things work first, then optimize it in a structured way and without getting weighted down by premature optimizations and such.
If I were to make a guess, some of the content order is following papers / intuition and the rest is messing up a bunch, taking notes along the way, and then reforming into a delightful journey for viewers. Sebastian is a wonderful storyteller that I bet embellishes certain points and spends extra time on debugging tools for us. :)
Your detailed explanation style is very much appreciated. It's often a tiny "practical" thing between "the theory" and "the final program" which is the biggest coding hurdle to overcome. Your videos are great to overcome these hurdles and learn how to approach such problems in general. Important skills well taught.
yeah it's been like 5 years since he made that comment about voxel erosion, I've been binging cave exploration videos and thinking about how to approach doing it myself hahaha
always excited to watch these videos, even though i dont understand much of it, the things you accomplish are so cool to see and its nice to learn something i have no idea about!
At 40:38 You have a struct that contains two float3s and two ints. If I'm remembering correctly, due to the byte alignment this will actually result in 48 bytes. because unfortunately float3s round up to 16 bytes for alignment and the 2 ints (due to the highest alignment in the struct being 16 bytes) will also take up 16 bytes. I'm not entirely sure how well you can do this, but you might try stuffing the 2 ints into each of the float3s to make two float4s. resulting in a true 32 byte node. Not 100% sure about how much better this is though.
That depends on what language is used. HLSL aligns StructuredBuffer tightly. So in this case no extra padding is added. If it was a cbuffer you'd be right or if it was GLSL. It is still a good idea to move the int before the other float3 though, as this won't have weird behavior if you do want to store it in a cbuffer somehow..
@@nielsbishere This "align up to 16 bytes" behavior is not required: the default setting of "shared" (and "packed", which is similar) leave all details up to the implementation. The option of "std140" does introduce this alignment, however, but the newer "std430" does not.
@@pitust std430 does align float3 (or rather, vec3, which is the glsl variant) to 16 bytes. But it it doesn't have the 16 byte array stride that std140 has. For example: float[4] -> in std140, this is "similar" to float4[4], in std430 it is stored tightly like a single float4 A similar rule exists for structs in std140, which std430 also gets rid of. But std430 still has the special alignment rule for vec3.
Your visualizations are immensely beautiful and helps understand complex concepts like BVH. I am not lying when I said, I read this and implemented this myself, but I don't believe this is what my understanding was! Much love to your work
Also minor suggestion, add option to TIP on youtube videos. That way it would be easier for me or others to support your work without having to through Patreon.
Tbh I really love your videos. Your voice always feels like you're enjoying every moment of the explanation. Not only it gives both coding knowledge but also inspiring for me to continue my coding journey. I think it does the same things for other people too. Thank you for posting those videos!
The result is excellent, and the explanations are great. I think the key to sebastian's success is his attention to the small details. When he explains he may put a slight animation that you only see for 3 seconds in the video, but he has taken the time to prepare it carefully. That enhances the quality of an already 100/100 content. Thanks for taking the time to do the remaining 20% of things that enhance the content so much. Greetings from a big fan. Keep it up💪💪💪
The exploratory nature of your videos is why I will spend an hour of my life the next available moment I have watching your channel. I love learning, and as a non programmer and you just make it so fun and easy to understand. Thank you for the knowledge and enthusiasm you give me to keep knowing more. :)
HOLY DAMN THIS GUY BLEW UP. Context, I watched this guylike 8 years ago(maybe more but it feels like 8, 20k followers thought he was underated af, actually had a chat with him briefly about how to reverse an algorithm for I think it was moving platforms, quite a shock to see him over 1 mill, its like seeing and old friend and being happy for their success, feels good :3.
Two things I love about this channel, your ability to break down really complex programming concepts in to something easy to get my head around and the fact that your test and explainer side projects are damn near finished projects in their own right. Love it all!
I can definitely recommend NVIDIA Nsight/AMD RGP for debugging and profiling tools, they can even tell you per-instruction information in the shaders themselves (albeit only on newer APIs).
How about a kd-tree? It is a more efficient data structure for static scenes. It is so efficient because it can stop as soon as it intersects with something inside a bounding box, as it gives distance sorted boxes. The intersection math is also waay faster!
Build times and splitting triangles can be a problem there, but if it can be baked or is just for a demo it's a good option. It will also force you to build on the cpu
A quirk is that a triangle can't be split like that (well, it can, but it makes things more complex): a BVH can have each side overlap enough to get the triangles on each side fully contained. It's not a complete loss though, you can generally simply put the triangle on both sides of the tree.
At the end, when you made the walls of the rendering box fully reflective (49:40), I was immediately reminded of portal rendering. Building a raytracer with portals in mind could massively simplify the process, since it's just hooking into the most basic features of raytraced rendering. I would love to see you implement portals with your raytracing system, but really, I want to finally make a raytracer for myself and make this happen. Thanks for inspiring me! If anyone wants to give me a nudge in the right direction before I start, should I pick an existing 3D framework like unity and build upon that, or go for a ground-up approach in C++, as I generally do with my own projects? I think it could be a great chance to get more into constructing my own vulkan pipeline and all that jazz as well, but that then risks becoming a behemoth of a project that detracts from the time I can dedicate to other things. Have a wonderful :)
You will not believe it if I said I've been watching your channel for over 4 years now and I have just realized today that your name is Sebastian *Lague* , always thought it was Sebastian *League* how have I not realized this
I'm pretty sure that reprojection just allows for the reuse of render data from frames where the camera is in a different position, and doesn't actually decrease the amount of noise when the camera is static
@@user-dh8oi2mk4f For realtime previews it's very useful. For offline renders it doesn't reduce the noise. And in fact reprojection would add bias. For that, you should probably use ReSTIR (DI/GI/PT) or a spatial denoiser (adds bias though).
It's perfect timing. I’ve been diving into ray tracing concepts for about a year now, and it's impressive how you've managed to pull this off so quickly. Your video is inspiring and gives me some new ideas to explore. Keep up the great work! 👍
Great video as usual, though I'm surprised you didn't mention the performance implications of limiting the minimum number of triangles per leaf node, as making sure there's at least a few triangles per leaf node is a common practice in BVH construction. Unless you did and I missed it of course lol
Absolutely fascinating video! I like your work on BVHs. I'm just looking into SDFs and thought about a technique like this as a viable base for sparse SDFs. It's just a rabbit hole where you can easily get lost for years or more. I wonder if you get rid of some of the noise by applying ReSTIR or similar.
Amazing video! Always very excited when you upload and I wasn’t expecting more ray tracing but certainly happy to see it. Do you think it would be possible in the future to play with converting this into something that runs in Godot, or do you have any future plans to play more with the Godot engine?
This might be very inefficient but I, as a person who doesn’t code, have an idea. What if the rays were emitted from the camera, meaning that you don’t have to render any rays that don’t make it to it?
Hello someone named Success Games is scamming your project on Nintendo Switch eShop, called "Airplane Delivery Simulator 2024", is this open source for commercial use?
Another great video! The visualizations you use and the step-by-step approach make everything so much easier to understand than simply explaining the code and showing the result. There's only one thing I could think of that could possibly be improved on in this one: the distinct lack of cat 😿 Jokes aside, this video inspired me to do some additional reading on the topic, so here's something I learned that might be worth exploring: The current state-of-the-art (or at least crowd favorite?) type of BVH seems to use something called PLOC (Parallel Locally-Ordered Clustering). At least this appears to also be the algorithm implemented by the Radeon RADV Vulkan driver. The idea in PLOC is to first order the triangles using a space-filling curve, typically using Morton code (this is also called Z-ordering). This causes triangles close to each other spatially to also be close in index, so the BVH can be built bottom-up efficiently by comparing the surface area of all potential merged nodes within a fixed index range. The main advantage of PLOC is supposed to be it's creation speed since most of it can be done in parallel, but it supposedly also results in higher traversal performance. Plus it can be further optimized (also in parallel) by collapsing leaves using SAH. Definitely sounds promising. If you want to take a closer look, the paper on it is called "Parallel Locally-Ordered Clustering for Bounding Volume Hierarchy Construction" (Meister and Bittner, 2017), but the best resource I found on it was a blog by Arsène Pérard-Gayot ( madmann91 github io (replaced dots with spaces so YT doesn't get mad)) where it's explained in detail using code snippets.
Sebastian: uploads a video *fifteen treseptagintilion years pass* Sebastian: uploads a video Edit1: no way I got 11 likes that’s never happened before!
Love the vid, please keep them coming. Idea for a future iteration: (You probably already have this on your list, but I'm gonna say it anyway) Light Transport! Translucent materials and sub surface scattering. Have a wonderful life, because you are making all of ours better. PS. Watter hoërskool was jy? (as ek mag vra)
Yeah patronize me all you want about 871198 being more than 456 but remember, not everybody went to a fancy-pansy school like you did. Not everybody can be a mathematician. /s
Great Content as always! I noticed that leaf nodes go all the way down to being a box around one triangle (If i interpreted the numbers correctly). Why not have a lower limit of, for example 2 or 3 Triangles in addition to having a maximum BVH depth? I imagine pushing the child nodes and the one additional Box intersection test might just be slower than testing against a few triangles. This will also cut down on BVH size and therefore help in terms of memory.
I think your main play here is to optimize memory usage. Not only for how much you use but also how. For example, you could simply sort the bounding boxes first then swap the triangles. This way triangles physically close to each other will be close in memory and will significantly improve your cache hits! Also, you may be able to pack your normals in to a more efficient form. For example a 16 bit integer. I forget the exact way to do this but blender uses this trick extensively
8:20 So the splitting into boxes happens in a different function, not displayed here right now, right? Because otherwise, whenever the Ray hits, the main-box would be a leave, since it doesn't split automatically. But where does the splitting happen actually, mustn't it be called by this function? Or is the dragon always split in these boxes statically and not dynamically? Oooh I think this may be it lol
6:15 You might bring it up later, but it also shouldn't split up bounding boxes that contain 0 triangles. No point having a bunch of boxes in a gap in the model. Looking at it later, it looks like you're not splitting it up into boxes small enough to matter. But you could and if you did it could make a (small) difference. 22:30 Ah, there you go.
Read a paper/watched a video recently on the Noise function, and the new state-of-the art Spatio-temporal Blue-noise for real-time graphics: ruclips.net/video/tethAU66xaA/видео.html
In a future followup, it would super interesting to see you dive into triangle decimation / culling techniques. The UE nanite system is an extremely interesting algorithm, in how it reduces triangle dynamically with distance. I think you giving it a shot and trying to implement it would be a great coding adventure. This video itself was great, as all the coding adventures have been!
If you split up the mesh into convex polygons, I think you could use BVH to find which convex polygon to check next, then use a much faster method for the convex polygon.
There are some really good RT denoise models around, so you could look into that. And maybe check if you can use some raymarching techniques to improve certain calculations?
There is actually an error in your shader code I think. The nodeStack at 16:18 or also the index stack at 31:04 needs to be 1 bigger than your max depth. This is because lets say we have a max depth of 2. Then we have (up to) a total number of 2 lvl1 boxes and 4 lvl2 boxes. If we then go through your for loop pushing them onto the stack, it will look like this: start: [ lvl0_0 ] after step 1: [ lvl1_0, lvl1_1 ] after step 2: [ lvl1_0, lvl2_0, lvl_2_1] at this point we have 3 entrys in our stack! This probably causes undefined behaviour in the shader and thus may not cause any problems most of the time, but can basically crash your shader at any time (afaik).
I thought the surface area heuristic would be about the surface area of the triangles, where you order them on likelyhood of being hit by a random ray, but i suppose the gain from that would only be marginal compared to getting denser boxes.
Instead of going your way with RIS or other importance sampling methods, I advise you to do NEE (next event estimation), while its slower (does 2 rays instead of one, since one will be for shadows) it'll converge quicker and provide better data for an denoiser in the future. After implementing NEE, you can implement MIS (multiple importance sampling) + RestirGI (Spatiotemporal reservoir resampling for Global Illumination)
Wonderful video as always! I recently saw a presentation by EA on how blue noise using the golden ratio is a huge improvement to perceived quality when rendering, since each pixel is randomized with respect to its neighbors rather than the full spectrum. This could speed up rendering by lowering the number of rays needed, and helps a lot with depth of field blurring which can look patchy at lower quality with white noise. What's also neat is that blue noise applies to any pseudorandom function by making the frequency higher. Essentially, it makes the next roll related to the previous roll and allows the gambler's fallacy to no longer be false.
I’ve never been so excited to watch an hour long coding adventure before
Mee toooooo!!!!!
I more excited that I have an hour long video to watch while I wait for a game to install
Wait, that was almost an hour? I suppose it was!
Same!
the font vid was hype af too tho
18:10 the arm waves in the reflection was so real 😂
A hallmark of graphics programming
@@epiklizard6629 I've been getting back into Vulkan and yeah...
I wondered if I was the only one who saw that
Side channel leaking his appearance
I was searching for this comment
Half an eternity = 8 seconds
The Sebastian Lague theory
I love how you explain code and shows us your little mistakes in there as well. It shows the natural thought process and shows that even you are human (even though you create these wonderful visualisations). Amazing work!
Wow, that’s very-very cool, I love it. It’s fun to see how things that are sometimes explained as if they were relatively simple are, in fact, not at all. ‘Cause firstly you think they are complicated, then somebody says “look, it’s easy!”, then you wonder why it doesn’t work as nice as it should, in the end realising it was never simple
You know it's good when the youtuber pulls out the research paper. I love this channel so, so much. Makes me wanna go out and write some code just because how fun it makes it look!
I love how you make such complex topics such easily understandable
Those videos have a mind-soothing, zen-buddhist quality to them 😌
Yayaaaa its the best programming series on RUclips
BRAND NEW SEBASTIAN LAGUE VIDEO LETS FUCKING GOOOOOOOOOOOOO
Holy shit, what an amazing video. keep it up
Behold the goat! I love your style
This video made me realise we're learning important stuff in enginnering school :o
I can't really code, I don't even know what language you are programming in. But I greatly enjoy your videos and I love learning this sort of stuff.
When you wanted to do a fun little project, but end up doing actual science :D
this is really good 😃
One thing you could try is to make a denoising algorythm to help getting a smooth preview render.
Awesome work. Wouldn't you ideally just calculate the BVH when importing a mesh into your project and store the data with the mesh, instead of having to redo it every time the program runs? Baking it, if you will
Eid Al Adha came early
I wonder if graph partitioning helps. All problems can be solved with graph partitioning.
"Just recursively split the children in half" is my new favorite Sebastian Lague quote.
The venn diagram of data structure terms and serial killer terms is a bit closer than you think 😅
This is the type of thing I laugh of
reminds me of the "are you being intentionally dense?" scene
I was zoning-out a little, but hearing that got me immediately focused again.
Salomon Lague
"But sometimes, I suppose, one has to prioritise the computer's happiness over one's own."
No. The computer must suffer lest _we_ suffer instead.
@@GeorgeTsirosBut if the computer is happier now, then its work will be done faster, so we can be happy with that work sooner. It's a win-win!
@@ValeBridges It was mostly in jest
The true Bob Ross of programming.
@@GeorgeTsiros In my now decade of programming, I couldn't agree more
OMG you've found the blog of my thesis supervisor (JBikker)! My thesis is related to BVHs so this video is a treat to watch :)
Haha, I didn't even notice that, Jacco is a former colleague of mine, back from when I worked at Davilex Games, small world indeed.
Really interesting video, I've been creating some real-time ray-tracing shaders, but nothing using triangles yet.
Fellow Jacco student!
It's surprising how often he comes up in my own research 😄
Your supervisor has a very rich and informative github.
Hey Sietze. :)
@@jaccobikker Amazing to read that you are still teaching. The graphics course was the most engaging and fun course I've had the pleasure of taking.
> I want to measure our inefficiency so that we can track improvements to it
what a philosophy
maximum inefficiency is pretty much my life motto
Which is the correct starting point of any performance optimisation with code. NEVER just assume you know what is slowing the program down. Measure the performance „in action“. Then you start your changes.
Humm, how would you do it if not by finding the innefficiencies?
For your next coding adventure you should try some multiplayer sync stuff if you haven't already. I recently have gone down a rabbit hole of different types of network sync models and there is still a lot of nuance that is left ambiguous in even the most detailed blog posts. Something that I would personally love to see.
Perhaps, if I’m feeling brave!
@@SebastianLague yeah I always wondered how all of the battlefield games were able to host 64 players, events, vehicles, explosions with pretty good efficiency (benchmarked with my old crappy wifi connection) and all of that good stuff:)
@@SebastianLagueseconding this suggestion, although I understand the hesitation 😅
Network code is the path to madness
@SebastianLague The world of networking has always been a mystery to me, so I would love to see you cover it.
"Where we left off a year or so ago" dealt me 1d6 of psychic danage
2d20 of old age
It shows in your spelling😮
So real, it felt like only a few months have passed
@@bactrosaurushuh
these coding adventures get more and more complex. I reckon Sebastian's working on something big, but first has to learn every technique to its fullest before starting and then finishing it
The perfect Game Engine, offering the best performance on every possible aspect hahahahah
Sebastian in 50 years: Hello everyone and welcome to another episode of Coding Adventures. Today, I wanted to try simulating our universe.
He's actually working in reverse. Started out creating a universe, now he's on figuring out light.
at this point he's just doing his own thing for its own sake none of this is necessary for a game project or really anything past tech demos
@@ClaffAMV with incrdeible preview rendering
Hey Sebastian, cool video!
There's a slightly different approach that would let you try every possible cut in the SAH without too much additional cost.
Right now you're evaluating each cut by looping over all the triangles (O(N*K) cost for N triangles and K cuts), but this does not take advantage of previous evaluations.
Imagine you sorted the triangles along one of the axis, then computed and stored the bounding box of each prefix and each suffix of the triangle list. Now you can evaluate each cut in constant time (child A corresponds to a prefix of the list and child B to a suffix).
Sorting has cost O(N log N), but then you can try all the cuts along that axis in O(N) time. Overall, the cost is O(N log N), which should be much better than O(NK) for large values of K.
Here is an outline of the general approach:
sort tris along the x axis
prefixes = array of length n
prefixes[0] = bounding box of tri[0]
for i = 1 to n-1, assign prefixes[i] = bounding box union of prefixes[i-1] and tri[i]
suffixes = arraay of length n
suffixes[n-1] = bounding box of tri[n-1]
for i = n-2 to 0, assign suffixes[i] = bounding box union of suffixes[i+1] and tri[i]
for i = 1 to n-1, the cost is i*surfaceArea(prefixes[i-1]) + (n-i)*surfaceArea(suffixes[i])
As described, the idea involves performing three sorting operations at each node of the tree, but this is not strictly necessary. If you sort all the triangles along the three axis just once at the top level, it's possible to preserve the order as you go down the tree construction algorithm. This might be too complicated to implement while keeping the code readable, though.
My absolute favorite part of your videos is that the tone of your voice is like you are _smiling_ while speaking.
I do not know why, normally I would consider it condescending, but from you it sounds _honest_
People who code well are rare. Equally rare are people who can explain well. People who can do _both_ are exceedingly rare. You deserve every bit of praise you get.
I hear the "hello everyone" and I drop anything just to watch it. 10/10 dropped my phone on a lake.
On??
@@willmungas8964 yes, on.
Water physics are a WIP...
@@Xa31er lmfaoooo
@@Xa31er mine bounced off of it. Its still bouncing, it never stops. I dont know what im doing wrong
frozen lake
That was awesome. One of the structures I've used in the past when I have all the data ahead of time is a Sort-Tile-Recursive (STR) R*Tree. You sort the data in space first, then build the tree from the bottom up. The result is a very well balanced tree that is extremely quick to query. You then set the maximum number of children in a leaf, so you get even performance. I don't know if the query times would speed up that much after your final iteration, but my guess is, the build time would be infinitely quicker. As always, just an extremely informative and entertaining video!
I've never heard of that, but it sounds interesting -- will check it out. And thanks, I'm happy you enjoyed the video!
How did you get to see the video that fast
How tf did u watch 1hr video and replied when it only came out 1 min ago
@@dogeron8132 60x speed
How tf did you comment 23h ago when video was uploaded 18mins ago??
Very impressive results, bravo.
I keep being in awe by how you manage to make things work first, then optimize it in a structured way and without getting weighted down by premature optimizations and such.
If I were to make a guess, some of the content order is following papers / intuition and the rest is messing up a bunch, taking notes along the way, and then reforming into a delightful journey for viewers. Sebastian is a wonderful storyteller that I bet embellishes certain points and spends extra time on debugging tools for us. :)
Thank you!
the old motto of software design
make it work
make it right
make it fast
it's simple, but helps a lot
babe wake up sebastian uploaded
I hope he keeps these monthley uploads up that would be awesome
@@warriorsfg no 🅱️itches😔
exactly
Very nice video. Nice illustration of the BVH concepts! Greets, Jacco.
Your student and an old colleague commented on this video as well. Just letting you know in case you wanted to say anything to them.
Hi Jacco!
this guy a real one fr fr big shout out
I fell asleep watching this video and I'm not even joking, you have the calmest voice and I wouldn't trade it for anything!
hes going to be like "do i take this as a compliment (calm voice) or an insult (not engaging)" LOL
No it was engaging, I was just pretty sleepy I guess 😅 great video 👌@@pvic6959
Same! I was watching it last night and nodded off before I could finish, it’s too calming. I’m back to see the rest this morning though.
Your detailed explanation style is very much appreciated. It's often a tiny "practical" thing between "the theory" and "the final program" which is the biggest coding hurdle to overcome. Your videos are great to overcome these hurdles and learn how to approach such problems in general. Important skills well taught.
Can't wait for more fluid simulation next!
What about the volumetric effects?
yeah it's been like 5 years since he made that comment about voxel erosion, I've been binging cave exploration videos and thinking about how to approach doing it myself hahaha
Or rendering voxels. I’ve gone down that rabbit hole and I have yet to return. D:
ray traced fluid simulation with refraction and caustics
always excited to watch these videos, even though i dont understand much of it, the things you accomplish are so cool to see and its nice to learn something i have no idea about!
At 40:38 You have a struct that contains two float3s and two ints. If I'm remembering correctly, due to the byte alignment this will actually result in 48 bytes. because unfortunately float3s round up to 16 bytes for alignment and the 2 ints (due to the highest alignment in the struct being 16 bytes) will also take up 16 bytes. I'm not entirely sure how well you can do this, but you might try stuffing the 2 ints into each of the float3s to make two float4s. resulting in a true 32 byte node. Not 100% sure about how much better this is though.
That depends on what language is used. HLSL aligns StructuredBuffer tightly. So in this case no extra padding is added. If it was a cbuffer you'd be right or if it was GLSL. It is still a good idea to move the int before the other float3 though, as this won't have weird behavior if you do want to store it in a cbuffer somehow..
@@nielsbishere This "align up to 16 bytes" behavior is not required: the default setting of "shared" (and "packed", which is similar) leave all details up to the implementation. The option of "std140" does introduce this alignment, however, but the newer "std430" does not.
@@pitust yup. Ssbos with the correct layout are an exception indeed
@@pitust std430 does align float3 (or rather, vec3, which is the glsl variant) to 16 bytes. But it it doesn't have the 16 byte array stride that std140 has. For example:
float[4] -> in std140, this is "similar" to float4[4], in std430 it is stored tightly like a single float4
A similar rule exists for structs in std140, which std430 also gets rid of. But std430 still has the special alignment rule for vec3.
Your visualizations are immensely beautiful and helps understand complex concepts like BVH. I am not lying when I said, I read this and implemented this myself, but I don't believe this is what my understanding was! Much love to your work
Also minor suggestion, add option to TIP on youtube videos. That way it would be easier for me or others to support your work without having to through Patreon.
Tbh I really love your videos. Your voice always feels like you're enjoying every moment of the explanation. Not only it gives both coding knowledge but also inspiring for me to continue my coding journey. I think it does the same things for other people too. Thank you for posting those videos!
The result is excellent, and the explanations are great. I think the key to sebastian's success is his attention to the small details. When he explains he may put a slight animation that you only see for 3 seconds in the video, but he has taken the time to prepare it carefully. That enhances the quality of an already 100/100 content. Thanks for taking the time to do the remaining 20% of things that enhance the content so much. Greetings from a big fan. Keep it up💪💪💪
that was a year or so ago??????????!!!
Apparently!
hi oziji
@@SebastianLague fruit flies, arrows, bananas, etc, you know how it goes.
I measure the passage of time by the coming and going of Sebastian Lague videos
The exploratory nature of your videos is why I will spend an hour of my life the next available moment I have watching your channel. I love learning, and as a non programmer and you just make it so fun and easy to understand. Thank you for the knowledge and enthusiasm you give me to keep knowing more. :)
very nice video as always! I am implementing a simple raytracer in plain C right now as well, but i am using a simple grid instead of a BVH
Dude I feel like... _so_ smart while I'm watching this video.
HOLY DAMN THIS GUY BLEW UP.
Context, I watched this guylike 8 years ago(maybe more but it feels like 8, 20k followers thought he was underated af, actually had a chat with him briefly about how to reverse an algorithm for I think it was moving platforms, quite a shock to see him over 1 mill, its like seeing and old friend and being happy for their success, feels good :3.
21:11 ♫♪♫♪ I don't want to set the world on fire ♫♪♫♪
That’s exactly what I was thinking
This visualisation of the rays hitting the model and the BVH test at 8:50 is really quite awesome. Great videos, please continue Sebastian.
Two things I love about this channel, your ability to break down really complex programming concepts in to something easy to get my head around and the fact that your test and explainer side projects are damn near finished projects in their own right. Love it all!
I can definitely recommend NVIDIA Nsight/AMD RGP for debugging and profiling tools, they can even tell you per-instruction information in the shaders themselves (albeit only on newer APIs).
How about a kd-tree? It is a more efficient data structure for static scenes. It is so efficient because it can stop as soon as it intersects with something inside a bounding box, as it gives distance sorted boxes. The intersection math is also waay faster!
Build times and splitting triangles can be a problem there, but if it can be baked or is just for a demo it's a good option. It will also force you to build on the cpu
A quirk is that a triangle can't be split like that (well, it can, but it makes things more complex): a BVH can have each side overlap enough to get the triangles on each side fully contained. It's not a complete loss though, you can generally simply put the triangle on both sides of the tree.
At the end, when you made the walls of the rendering box fully reflective (49:40), I was immediately reminded of portal rendering. Building a raytracer with portals in mind could massively simplify the process, since it's just hooking into the most basic features of raytraced rendering.
I would love to see you implement portals with your raytracing system, but really, I want to finally make a raytracer for myself and make this happen. Thanks for inspiring me!
If anyone wants to give me a nudge in the right direction before I start, should I pick an existing 3D framework like unity and build upon that, or go for a ground-up approach in C++, as I generally do with my own projects? I think it could be a great chance to get more into constructing my own vulkan pipeline and all that jazz as well, but that then risks becoming a behemoth of a project that detracts from the time I can dedicate to other things. Have a wonderful :)
It's always great to watch a coding adventures video. I didn't know where the 50 minutes went by, your videos are always so interesting Sebastian!
It would be fun to see you explore HDR buffers and HDR tone mapping for this series, or just color space stuff in general!
You will not believe it if I said I've been watching your channel for over 4 years now and I have just realized today that your name is Sebastian *Lague* , always thought it was Sebastian *League* how have I not realized this
To make the image less noisy you can look into reprojection. There is a great article made by Jacco Bikker (same guy who made the bvh article)
Or some simple a-svgf
I'm pretty sure that reprojection just allows for the reuse of render data from frames where the camera is in a different position, and doesn't actually decrease the amount of noise when the camera is static
@@user-dh8oi2mk4f For realtime previews it's very useful. For offline renders it doesn't reduce the noise. And in fact reprojection would add bias. For that, you should probably use ReSTIR (DI/GI/PT) or a spatial denoiser (adds bias though).
Just had a stressful day coding a work - what better day to relax and switch off than by watching some coding adventures?
When choosing where to split based on the surface area huristic, you should do a binary search instead of checking 5 arbitrary splits along an axis
I don't think the surface area heuristic is monotonic with respect to the split position
@@user-dh8oi2mk4fUse linear interpolation / marching squares-esque to estimate it
I wonder how the integrated graphics of the R5 5500U will handle this 🤔
It's perfect timing. I’ve been diving into ray tracing concepts for about a year now, and it's impressive how you've managed to pull this off so quickly. Your video is inspiring and gives me some new ideas to explore. Keep up the great work! 👍
Great video as usual, though I'm surprised you didn't mention the performance implications of limiting the minimum number of triangles per leaf node, as making sure there's at least a few triangles per leaf node is a common practice in BVH construction. Unless you did and I missed it of course lol
Please keep making more coding adventure videos like this!
Lighting always confuses me because it’s so complicated.
Honestly, I could watch your videos forever. Great visuals, great background music, great explanations and great concepts!
Absolutely fascinating video! I like your work on BVHs. I'm just looking into SDFs and thought about a technique like this as a viable base for sparse SDFs. It's just a rabbit hole where you can easily get lost for years or more. I wonder if you get rid of some of the noise by applying ReSTIR or similar.
I remember watching your previous Raytracing Videos like it was yesterday. Its always nice to see when you upload. Keep up the great content
Amazing video! Always very excited when you upload and I wasn’t expecting more ray tracing but certainly happy to see it.
Do you think it would be possible in the future to play with converting this into something that runs in Godot, or do you have any future plans to play more with the Godot engine?
This might be very inefficient but I, as a person who doesn’t code, have an idea. What if the rays were emitted from the camera, meaning that you don’t have to render any rays that don’t make it to it?
he's already doing that, and it is efficient. though it is not so efficient in terms of finding rays that made it to light (it's reversed after all)
@stubman5927 luckily that's why NEE, MIS and gang exist. BDPT is also great if caustics are important
Beautiful.
So satisfying, watching someone that can actually get shit done.
Banger as always, thanks Sebastian!
I've never understood anything you've said, nor do I have an interest in coding but i keep coming back.
HERE WE GOOOOO
Hello someone named Success Games is scamming your project on Nintendo Switch eShop, called "Airplane Delivery Simulator 2024", is this open source for commercial use?
You are right! What a douche!
Bro has the most calming and relaxing voice ever🗣️🗣️🫠
sounds like he's smiling the whole time :)
Another great video! The visualizations you use and the step-by-step approach make everything so much easier to understand than simply explaining the code and showing the result. There's only one thing I could think of that could possibly be improved on in this one: the distinct lack of cat 😿
Jokes aside, this video inspired me to do some additional reading on the topic, so here's something I learned that might be worth exploring:
The current state-of-the-art (or at least crowd favorite?) type of BVH seems to use something called PLOC (Parallel Locally-Ordered Clustering). At least this appears to also be the algorithm implemented by the Radeon RADV Vulkan driver.
The idea in PLOC is to first order the triangles using a space-filling curve, typically using Morton code (this is also called Z-ordering). This causes triangles close to each other spatially to also be close in index, so the BVH can be built bottom-up efficiently by comparing the surface area of all potential merged nodes within a fixed index range.
The main advantage of PLOC is supposed to be it's creation speed since most of it can be done in parallel, but it supposedly also results in higher traversal performance. Plus it can be further optimized (also in parallel) by collapsing leaves using SAH. Definitely sounds promising.
If you want to take a closer look, the paper on it is called "Parallel Locally-Ordered Clustering for Bounding Volume Hierarchy Construction" (Meister and Bittner, 2017), but the best resource I found on it was a blog by Arsène Pérard-Gayot ( madmann91 github io (replaced dots with spaces so YT doesn't get mad)) where it's explained in detail using code snippets.
Sebastian: uploads a video
*fifteen treseptagintilion years pass*
Sebastian: uploads a video
Edit1: no way I got 11 likes that’s never happened before!
Lel :P
>
Love the vid, please keep them coming.
Idea for a future iteration: (You probably already have this on your list, but I'm gonna say it anyway) Light Transport! Translucent materials and sub surface scattering.
Have a wonderful life, because you are making all of ours better.
PS. Watter hoërskool was jy? (as ek mag vra)
21:13 Japanese citizens on august 6 of 1945:
Your videos about binary options trading are always very interesting and useful. I learned a lot of new things and learned to put them into practice.
Yeah patronize me all you want about 871198 being more than 456 but remember, not everybody went to a fancy-pansy school like you did. Not everybody can be a mathematician. /s
HELL YEAH I LOVE VIDEOS OF CODING RAY TRACING
Great Content as always!
I noticed that leaf nodes go all the way down to being a box around one triangle (If i interpreted the numbers correctly). Why not have a lower limit of, for example 2 or 3 Triangles in addition to having a maximum BVH depth? I imagine pushing the child nodes and the one additional Box intersection test might just be slower than testing against a few triangles. This will also cut down on BVH size and therefore help in terms of memory.
I think your main play here is to optimize memory usage. Not only for how much you use but also how. For example, you could simply sort the bounding boxes first then swap the triangles. This way triangles physically close to each other will be close in memory and will significantly improve your cache hits!
Also, you may be able to pack your normals in to a more efficient form. For example a 16 bit integer. I forget the exact way to do this but blender uses this trick extensively
8:20 So the splitting into boxes happens in a different function, not displayed here right now, right? Because otherwise, whenever the Ray hits, the main-box would be a leave, since it doesn't split automatically. But where does the splitting happen actually, mustn't it be called by this function?
Or is the dragon always split in these boxes statically and not dynamically? Oooh I think this may be it lol
6:15 You might bring it up later, but it also shouldn't split up bounding boxes that contain 0 triangles. No point having a bunch of boxes in a gap in the model. Looking at it later, it looks like you're not splitting it up into boxes small enough to matter. But you could and if you did it could make a (small) difference.
22:30 Ah, there you go.
Read a paper/watched a video recently on the Noise function, and the new state-of-the art Spatio-temporal Blue-noise for real-time graphics: ruclips.net/video/tethAU66xaA/видео.html
In a future followup, it would super interesting to see you dive into triangle decimation / culling techniques. The UE nanite system is an extremely interesting algorithm, in how it reduces triangle dynamically with distance. I think you giving it a shot and trying to implement it would be a great coding adventure.
This video itself was great, as all the coding adventures have been!
If you split up the mesh into convex polygons, I think you could use BVH to find which convex polygon to check next, then use a much faster method for the convex polygon.
There are some really good RT denoise models around, so you could look into that. And maybe check if you can use some raymarching techniques to improve certain calculations?
Excellent work, though 90% of the things blew my mind.🤯 I'll have to re-watch
just looked into audio programming and it seems way more complicated than I thought. might be fun to research yourself!
There is actually an error in your shader code I think. The nodeStack at 16:18 or also the index stack at 31:04 needs to be 1 bigger than your max depth.
This is because lets say we have a max depth of 2. Then we have (up to) a total number of 2 lvl1 boxes and 4 lvl2 boxes. If we then go through your for loop pushing them onto the stack, it will look like this:
start: [ lvl0_0 ]
after step 1: [ lvl1_0, lvl1_1 ]
after step 2: [ lvl1_0, lvl2_0, lvl_2_1]
at this point we have 3 entrys in our stack!
This probably causes undefined behaviour in the shader and thus may not cause any problems most of the time, but can basically crash your shader at any time (afaik).
Good point, thanks!
@@SebastianLague no problem, love your videos :))
I thought the surface area heuristic would be about the surface area of the triangles, where you order them on likelyhood of being hit by a random ray, but i suppose the gain from that would only be marginal compared to getting denser boxes.
Instead of going your way with RIS or other importance sampling methods, I advise you to do NEE (next event estimation), while its slower (does 2 rays instead of one, since one will be for shadows) it'll converge quicker and provide better data for an denoiser in the future.
After implementing NEE, you can implement MIS (multiple importance sampling) + RestirGI (Spatiotemporal reservoir resampling for Global Illumination)
Yay, he doesn’t forget other videos!
Wonderful video as always! I recently saw a presentation by EA on how blue noise using the golden ratio is a huge improvement to perceived quality when rendering, since each pixel is randomized with respect to its neighbors rather than the full spectrum. This could speed up rendering by lowering the number of rays needed, and helps a lot with depth of field blurring which can look patchy at lower quality with white noise.
What's also neat is that blue noise applies to any pseudorandom function by making the frequency higher. Essentially, it makes the next roll related to the previous roll and allows the gambler's fallacy to no longer be false.
Your videos make my day every single time. Good job, keep it up 👍👍
Something that would probably be good to add is a de-noiser, as in the darker spots it gets pretty noisy. (as seen in the final render)
not being able to use recursion broke my heart. Dfs with a stack on trees won't fill the hole in my chest :,(