Video není dostupné.
Omlouváme se.
Real-Time Ray Tracing | "RTX ON in Vulkan" | Vulkan Lecture Series Ep. 6, Real-Time Rendering Course
Vložit
- čas přidán 14. 08. 2024
- Take a deep-dive into hardware-accelerated ray tracing! Learn about top-level and bottom-level acceleration structures, get to know the acceleration structure traversal loop inside out, learn when ray generation shaders, intersection shaders, any-hit shaders, closest-hit shaders, and miss shaders are invoked, witness a comprehensive shader binding table example, and see how to perform acceleration structure traversal on foot using ray query.
00:00 Introduction
03:34 Acceleration Structures
14:07 Bounding Volume Hierarchy Traversal
17:39 Tracing One Ray, traceRayEXT
20:49 Ray Tracing Pipeline in Depth
26:43 Tracing All the Rays, vkCmdTraceRaysKHR
28:01 Shader Binding Table
33:54 Shader Binding Table Example
38:44 Hit Group Record Address Formula
42:26 Recursive Rays: Refraction Rays, Reflection Rays, Shadow Rays
49:54 Miss Shader Record Address Formula
50:20 Ray Query
This lecture has been recorded as part of the 186.140 Real-Time Rendering course at TU Wien, winter term 2021.
Brought to you by Johannes Unterguggenberger, Research Unit of Computer Graphics, Rendering and Modeling Group, Institute of Visual Computing & Human-Centered Technology, TU Wien, Austria.
Slides can be downloaded here: www.cg.tuwien....
These lectures are some of the most valuable resources for learning Vulkan in existence. Thank you so much for producing these videos, they've helped improve my understanding and mental model of Vulkan tremendously! Please please please make more of these.
What a fantastic video, as well as series in general. Your diagrams and examples always make things approachable and work well as an introduction, and yet you explain with enough detail to make it easy to then pick up and read the official specification afterwards. Well done, and I can't wait to see the rest!
It's not easy to do vulkan tutorials, and you did a fantastic job of giving both a conceptual overview and introduction into the details! Thanks :)
this is the most epic real-time rendering course
You are godsent. This is brilliant video.
Remarkable work.
Finally!! 🔥🔥
Having actual working code for the shaders would be very nice! Especially, when it could have been just a little hello-world explaining the basics.
Yup, same.. looking for simple to understand ray tracing code, without weird nvidia libraries or smth...
@@aspidintonyou are watching lecture 6 in a course about the vulkan graphics api, the focus is about vulkan and not necessarily about raytracing.
For resources about specifically learning about raytracing, there is the following:
Peter Shirley's Raytracing In A Weekend series,
Computer Graphics From Scratch by Gabriel Gambetta
The raytracing lectures from UC Davis' ECS 175 by ken joy
There's probably tons of other stuff out there as well
@@schelney thanks for the material, however i think i understand the concept of ray tracing, and i need RT implementation in vulkan. I think Sascha Willems' basic ray tracing is the best option.
Also this repository might be helpful: github.com/maierfelix/VK_KHR_ray_tracing
Do we need an RTX GPU to take this course on our own? :)
Naaah, only for real-time ray tracing! ^^
Some non rtx cards offer raytracing extensions under vulkan, the difference being it falls back internally into a compute pipeline, but is equally functional.
Good vodeo! Though it would be much easier to digest if the information would be phrased for audio/video consumption, as opposed to being phrased for textual reading as it very obviousely has been. What works well for reading simply doesn't work well at all for listening. So much so, that it would have been probably easier to just get a transcript to read through than to listen to this being type-read verbatim like this (and it's not the first time such a comment is made on this channel, so a bit dissapointing).
Nothing at all here strikes me as being phrased specifically for textual reading. It's clearly *scripted* (as most well-balanced tutorials are), but the script is *strongly* supported by the visuals. Like, all the sections walking through the ray traversal examples (both the simple one in the beginning as well as the island one later) only make sense when following along with the visuals, and all the structs they talk about are walked through on-screen. I'm not sure what you're looking for exactly... I for one would very much like them to continue this style.
@@Sabre-dt2ng The slides and presentation quality in general are very high - that's actually what makes it frustrating to struggle through digesting it the way it's phrased.
Here's another video from this channel which contains many of my comments about phrasing that you can have a look at to get my meaning:
czcams.com/video/isbMMIwmZes/video.html
It's a bit like how books are written with a different phrasing than movie screenplays, or even live presentations/lecturing - even when authored by the same person. You can listen to famouse speakers and book authors, when they read their own books verbatim vs. when they give live presentations.
But even for text, phrasing well is a skill onto it's own and it just seems like the author could have used some help there.
Like, if a sentence has "..., which ..., which ..." that's typically a clear sign that it should be restructured internally and/or broken apart.
Example from this video:
"...before we move to acceleration structure traversal and to an in-depth look into ray tracing pipelines, let us quickly see how data for building bottom level acceleration structures is provided".
Compare this with:
"...before we move to ray tracing pipelines and traversing acceleration structures, let's quickly see how to provide data for building bottom-level ones".
Subtle perhapse, but the second one would demands less from a listener (in audio) then the first, while conveying the same information.
In text it's less noticeable, but I think still is.
Note how long and verbose the original sentence is, and note the gramatical reversing at the end as oppose to the more natual way of speaking.
People tend to have longer short-tem "context" memory when reading than when listening, and if a structure of a long sentence makes it difficult, we can always jump our eyes backwards for context. Scrubbing a video backwards is breaking the flow a lot more than jumping your eyes over text, and I found myself scrubbing a lot in this video and the other I linked to.
@@AinurEru As a native English speaker, I actually find your recommendations either no better, or in most cases actually worse... (And you ended up kind of spamming that other video; did you really need to make a separate top-level comment for each of your examples..?)
Like your example here:
1) You swapped the order of "acceleration structure traversal" and "ray tracing pipelines", but now they're in the *opposite* order of how the sections are laid out in the video (acceleration structure traversal @14:07, pipeline in-depth @20:49).
2) You did this so you could say "ones" at the very end because you seemingly disliked the repetition of "acceleration structure", but now "ones" is ambiguous could interpreted as *also* including ray tracing pipelines, but "building bottom-level ray tracing pipelines" is not a real concept.
3) This is made worse by removing the second "to" in "before we move on to X, and *to* Y", which makes it slightly less clear those are intended to be two separate sections and not one combined topic (note that the presenter put a pause between them as well, helping to demarcate the concepts; your phrasing doesn't lend itself to a natural pause there).
4) By changing to "before we move on to [...] *traversing* acceleration structures" as opposed to "acceleration structure *traversal* ", you're ambiguously making it sound like an activity *we're* doing (i.e. "we're moving on to traversing/exploring X"). But that's not the intent; "acceleration structure traversal" is a well-established operation the *GPU* does, and we're moving on to that *topic* .
5) You removed the "in-depth look" part about ray tracing pipelines. But that was meant to contrast with the *introduction* to ray tracing pipelines that *already happened earlier in the video* . Removing that part makes it sound like we're bizarrely re-introducing a topic we've already covered as opposed to providing an additional deeper dive that builds on that earlier shallow introduction.
In my opinion, your changes did a *lot* of damage to the comprehension of that sentence, and all for a ~20% reduction in length. And I feel similarly for each of the specific examples you gave in the other video.
This is a lecture, as opposed to a casual CZcams tutorial, so the presentation style is somewhat formal, but it didn't seem at all distracting to me.
@@Sabre-dt2ngFirstly, I am a non-native english speaker, but so is the author and likely most of his viewers (rendering/graphics programming has always been far more dominant in non-native english speaking countries).
As for labeling my comments on that other video as 'spam', can't see how that's valid. You can obviously see that they quote the video verbatim, and offer concise alternatives that - whether you agree with them or not - have obviously been given some thought. The breakdown to individual ones is incidental to their purpose. I could collapse them all into a single comment if that bothers anyone, but A) I dissagree that it would, and B) it makes it easier to comment on individual ones when broken down so is actually better for everyone that way.
Now that I look at it, your first 3 points would be aswered for by just removing the mention of pipelines in that sentence, as it is clearly meant to lead into a discussion on the construction of acceleration structures (the following section). The pipelines part of it is almost irrelevant to this preamble, and can simply be it's own sentense after that:
"...before we move to traversing acceleration structures let's quickly see how to provide data for building bottom-level ones".
"Following that we'll dive deeper into ray tracing pipelines."
But I'll comment on each point anyway:
1) Order swapping is natural in live-speaking, even in lectures, and given the accompanying slides it wouldn't actually bother anyone that much (if they even notice it at all).
2) Since you've noticed the reason behind the reversal, and given that you're a native english speaker, it's clear that you know that in that case the "ones" is *unambiguosly* reffering to "acceleration structure" being the 'latter' of the priorly mentioned comma-separated nouns (as you said yourself, I did it for that sake). It's been a while since my english classes in school, but I at least remember that. And as you said, building ray tracing pipelines has no meaning anyway, and that's made clear by the rest of the video, so - again - no potential for confusion there.
3) This little bit may be valid, though again with the slides on there, it's a non-issue as it's easilly visible that they are separate sections. That said, it's easy to adapt my alternative phrasing to it accomodates that:
"...before we move to ray tracing pipelines and *to* traversing acceleration structures, ..."
4) I can't see how even a non-native english speaker might get confused there. The verb "traverse" is never used to denote covering a topic in a presentation.
And for the record, I've written CPU ray tracers from scratch, including BVH traversal algorithms, so no need to educate me there.
5) "...before we move *to an in-depth look at* ray tracing pipelines and *to* traversing acceleration structures, ..."
What makes it easier to digest is a reduction in complexity and needless verbosity, and I dissagree that it's only "slightly" formal - it's very much "overly formal to a fault", and that's my overall point in all of this. Passed some point it becomes counter productive to it's purpose when it damages information transfer - the core purpose of any lecture.
The "formality" aspect though is not even the main issue - the phrasing in these examples is needlessly convoluted to a fault in other ways than just "fomality".
It's clearly just a lack of proof-reading when scripting and not putting the additional effort to simplify the scripts for the sake of ease of consumption.
Videos like this (especially successful ones) tend to have much more time being spent on being *consumed* than on being produced, so additional time into improving consumption is a net-win.
@@AinurEru I think we can just agree to disagree here. Ultimately since I'm very happy with how these lectures are going, I'd rather not get into too huge a discussion; just wanted to make sure it was mentioned to the presenter that someone felt otherwise, as I'd be disappointed if they pivoted too hard as I find their current phrasing all but perfect as-is. If others agree with you they can chime in here too and strengthen your feedback.
Just want to clarify my intent behind a couple things I think you took as attacks before I go:
> As for labeling my comments on that other video as 'spam', can't see how that's valid. [... They] have obviously been given some thought.
I meant that as a soft suggestion; in hindsight "flood" would be a better word. I didn't mean they were in bad faith or that the contents weren't relevant. Clearly you're trying to give actionable feedback because you care about the topic and this lecture series. But now 8 out of 18 top-level commenters on that video are you, and they're all supporting evidence for a single claim from a particular individual. My personal view is that top-level comments should map 1-to-1 with each individual's overall conversation topic, which is a courtesy that allows each person's feedback to be essentially equal in visibility. If the topics differ dramatically then two or (rarely) three are fine IMO.
> And for the record, I've written CPU ray tracers from scratch, including BVH traversal algorithms, so no need to educate me there.
That wasn't at all intended as a slight or an attempt to educate. I wanted to present evidence to support *why* I felt the existing phrasing was useful in that context. If anything, it hoped you *were already* familiar, in hopes that it'd establish common ground.