rtcOccluded4/8/16(3)

πŸ“¦ version 3.13.5, in epel 9, fedora 43, fedora 44

πŸ’– rtcOccluded4/8/16 β€” finds any hits for a ray packet πŸ’–

okay bestie, sit DOWN, because we're talking about rtcOccluded4/8/16 from the Embree Ray Tracing Kernels 3 era of your life. this is a <embree3/rtcore.h> situation, three functions, one job: is there literally anything in the way? πŸ¦‹


✨ SYNOPSIS ✨

#include <embree3/rtcore.h>

void rtcOccluded4(
  const int* valid,
  RTCScene scene,
  struct RTCIntersectContext* context,
  struct RTCRay4* ray
);

void rtcOccluded8(
  const int* valid,
  RTCScene scene,
  struct RTCIntersectContext* context,
  struct RTCRay8* ray
);

void rtcOccluded16(
  const int* valid,
  RTCScene scene,
  struct RTCIntersectContext* context,
  struct RTCRay16* ray
);

🌸 DESCRIPTION 🌸

so the rtcOccluded4/8/16 functions each take a ray packet of size 4, 8, or 16 (that's your ray argument) and check, for every active ray in it, whether there's any hit with the scene (yes, the scene argument, we love her). if you wanna know how to actually set up and trace occlusion rays, go read [rtcOccluded1] β€” she's the blueprint, bestie. πŸ‘‘

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. we respect the inactive rays' privacy in this house. πŸ™ˆ

the implementation of these functions is guaranteed to invoke callback functions always with the same ray packet size and ordering of rays as specified initially. consistent queen behavior, no cap. πŸ’…

now, the alignment tea β˜• β€” for rtcOccluded4 the ray packet must be aligned to 16 bytes, for rtcOccluded8 the alignment must be 32 bytes, and for rtcOccluded16 the alignment must be 64 bytes. get it wrong and it's giving πŸ’€, so please align properly.

also important: rtcOccluded4, rtcOccluded8 and rtcOccluded16 may change the ray packet size and ray order when calling back into intersect filter functions or user geometry callbacks. under some conditions the application can assume packets stay intakt, which can determined 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 information. iykyk. 🧚


πŸŽ€ EXIT STATUS πŸŽ€

for performance reasons this function does not do any error checks, thus will not set any error flags on failure. 😭 it's fast, it's reckless, it's literally not checking anything. main character energy, honestly.

πŸ”₯ SEE ALSO πŸ”₯

  • [rtcOccluded4/8/16]

and that's the whole vibe, bestie β€” rtcOccluded4/8/16, straight out of the Embree Ray Tracing Kernels 3 manual, rtcOccluded4/8/16(3) section, mwah πŸ’‹ stay aligned, stay valid, and may all your rays be occluded exactly when you want them to be. 🫢✨

πŸ“¦ where this page comes from