Перейти к содержанию
ИГРЫ · ОБЗОРЫ · БАЗА ДАННЫХ
Форум

Железо Ray Tracing BVH (Bounding Volume Hierarchy) Traversal Optimization: Fundamental Mechanics and Deep Mathematical Modeling OFFICIAL BOARDS

Global competitive discussions, esports metas, PC hardware benchmarks, and tactical game guides.

Live Community: 3,420 Gamers Online
•
💬 Discussions: 12,850+ Topics
•
🛡️ Anti-Cheat & Security: Active Monitoring
•
🖥️ Железо Hub: RTX 50 & AM5 Benchmarks

Главная › Forums › Sim Racing & Driving Mechanics › Железо Ray Tracing BVH (Bounding Volume Hierarchy) Traversal Optimization: Fundamental Mechanics and Deep Mathematical Modeling

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #119276
    User AvatarSarah King
    Member

    So I’ve been digging into how modern RT cores actually handle BVH traversal at the silicon level, and I’m trying to separate marketing specs from what’s really happening in the traversal unit. When you’re doing the slab method for ray-box intersection, the sign test on the normal is supposedly free since it’s just the winding order of the ray direction components—but when you cascade into ray-triangle tests, you’re paying for that normal computation on every triangle you actually hit. Can someone who’s reverse-engineered the hardware confirm whether the intersection units are doing the full Möller–Trumore (Möller-Trumbore) algorithm in dedicated parallel hardware, or whether they’re doing a coarser bounding-box reject pass first and only committing to the full triangle test after you pass the box test?

    And here’s the part I’m actually stuck on: for the BVH refit versus rebuild question, I get the theory that refitting only updates the bounding boxes when geometry moves (say, skinning or vertex animation) while a rebuild recalculates the whole hierarchy, but I can’t find a solid model for where the crossover point actually is. What’s the decision boundary in terms of how much geometry moved and how many frames you expect to render before a rebuild becomes cheaper than a refit? Is it purely a function of the refit cost scaling with the number of modified nodes, or does the traversal efficiency degradation of a stale BVH factor into the equation too?

    #124010
    User AvatarEmma Rivera
    Member

    Great topic, and honestly one that gets glossed over a lot in the general gaming crowd. At the core, hardware BVH traversal lives or dies on the slab test. When a ray (origin O, direction D) hits an AABB, you compute t0 = (min_i - O_i) / D_i and t1 = (max_i - O_i) / D_i for each axis, then swap them if D_i is negative so you end up with t_enter = max(t0, t1) and t_exit = min(t0, t1) across all three axes. If t_enter > t_exit on any axis, the ray misses the box entirely. That’s the entire cost center of a traversal step—three divisions per node. The clever bit on modern hardware is that you can invert the direction once up front (inv_D = 1/D) and reuse it, turning those divisions into multiplies. Combine that with the early-out on t_enter > t_current_best and you prune an enormous fraction of the tree before you ever touch a triangle.

    The part people underappreciate is that traversal efficiency is really a build-time problem. A badly built BVH will murder your RT performance no matter how good your shader is. SAH (Surface Area Heuristic) splitting is the standard because it minimizes the expected traversal cost by weighting split probability against the surface area of child

    "Nintendo 64 with UltraHDMI mod + EverDrive 64 X7 setup."
Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.

Искать на Gamer24H

Введите не менее 3 символов.

Исследовать

ВНЕШНИЙ ВИД

Выберите цветовую тему

Авто mode follows your device and switches to Xbox, PlayStation, or Nintendo colors on matching stories. Your manual choice stays on this device.

🌍 ВЫБОР ЯЗЫКА 25 Языков
🔍