rtcIntersect4/8/16(3)

💖 rtcIntersect4/8/16 — from the Embree Ray Tracing Kernels 3 manual, bestie 💖

okay so. you know how a single ray is cute and all? yeah well, this one's for when you roll up with a whole squad of rays at once. this is rtcIntersect4/8/16(3), and it's giving ✨ packet energy ✨. buckle up.

---

🌸 NAME 🌸

rtcIntersect4/8/16 — finds the closest hits for a ray packet. yes bestie, closest, we're not doing occluded today, that's a whole other page. 💅

---

✨ SYNOPSIS ✨

#include <embree3/rtcore.h>

void rtcIntersect4(
  const int* valid,
  RTCScene scene,
  struct RTCIntersectContext* context,
  struct RTCRayHit4* rayhit
);

void rtcIntersect8(
  const int* valid,
  RTCScene scene,
  struct RTCIntersectContext* context,
  struct RTCRayHit8* rayhit
);

void rtcIntersect16(
  const int* valid,
  RTCScene scene,
  struct RTCIntersectContext* context,
  struct RTCRayHit16* rayhit
);

like, same vibe three times, just with bigger numbers. 4, 8, 16. the girlies love a scalable API. 🫶

---

🦋 DESCRIPTION 🦋

okay so the rtcIntersect4/8/16 functions find the closest hits for a ray packet of size 4, 8, or 16 (that's your rayhit argument) with the scene (that's your scene argument). the ray/hit input is carrying both a ray packet and a hit packet, it's a whole two-for-one situation. 💖

if you wanna know how to actually set up and trace rays in the first place, go read Section [rtcIntersect1], bestie, that's where the lore is.

the valid mask, periodt: you must hand over a ray valid mask (the valid argument). it stores one 32-bit integer per ray in the packet, where -1 means valid and 0 means invalid. only active rays get processed, and the hit data of inactive rays is not changed. no touching, no spoiling, we respect boundaries. 🎀

callback ordering, no cap: the implementation of these functions is guaranteed to invoke callback functions always with the same ray packet size and the same ordering of rays as specified initially. so if you set it up one way, it stays that way when it calls back. iconic behaviour honestly. 👑

alignment check, don't skip this: ⚠️

• for rtcIntersect4 the ray packet must be aligned to 16 bytes
• for rtcIntersect8 the alignment must be 32 bytes
• for rtcIntersect16 the alignment must be 64 bytes

plot twist incoming: 🙈 the rtcIntersect4, rtcIntersect8 and rtcIntersect16 functions may change the ray packet size and ray order when calling back into intersect filter functions or user geometry callbacks. yeah. under some conditions though, the application can assume packets stay intakt — and you can figure out whether that's your situation by querying the RTC_DEVICE_PROPERTY_NATIVE_RAY4_SUPPORTED, RTC_DEVICE_PROPERTY_NATIVE_RAY8_SUPPORTED, RTC_DEVICE_PROPERTY_NATIVE_RAY16_SUPPORTED properties through the rtcGetDeviceProperty function. see [rtcGetDeviceProperty] for more info, iykyk. 🌈

---

💀 EXIT STATUS 💀

for performance reasons this function does not do any error checks, thus will not set any error flags on failure. it simply does not have the time, she's booked and busy. so like... check your own stuff, bestie. 😭

---

🌟 SEE ALSO 🌟

• [rtcOccluded4/8/16] — the "is anything in the way" sibling, go say hi 🍓

---

and that's the whole page, fr fr! 💜

cute lil sign-off: this whole thing comes from the Embree Ray Tracing Kernels 3 manual, page rtcIntersect4/8/16(3) — that's the source, the version vibe, and the page name all rolled into one. slay. ✨🎀💅