RTCSETNEWGEOMETRYBUFFERHOSTDEVICE(3)

💖 rtcSetNewGeometryBufferHostDevice(3) — Embree Ray Tracing Kernels 4 💖

okay bestie, buckle up, because this one is literally from the Embree Ray Tracing Kernels 4 manual (rtcSetNew...HostDevice(3), if you're keeping receipts) and she is a baddie. no preamble, let's go ✨

---

✨ NAME ✨

rtcSetNewGeometryBufferHostDevice — creates and assigns a new host/device data buffer pair to the geometry 🫶

---

🌸 SYNOPSIS 🌸

#include <embree4/rtcore.h>

void rtcSetNewGeometryBufferHostDevice(
  RTCGeometry geometry,
  enum RTCBufferType type,
  unsigned int slot,
  enum RTCFormat format,
  size_t byteStride,
  size_t itemCount,
  void** ptr,
  void** dptr
);

---

🦋 DESCRIPTION 🦋

so the rtcSetNewGeometryBufferHostDevice function creates a brand new host/device data buffer pair — the format is whatever you pass as the format argument, the byte stride is your byteStride argument, and the number of items is the itemCount argument — and then it assigns that whole thing to a geometry buffer slot. which slot? that's the type and slot arguments, and the geometry in question is the geometry argument. no cap 💅

the buffer data is managed internally and it gets automatically freed when the geometry is destroyed. so like, don't go freeing it yourself, she's got it handled 🎀

the byte stride (that's the byteStride argument) must be aligned to 4 bytes, otherwise rtcSetNewGeometryBufferHostDevice will fail. periodt. that's non-negotiable 😤

also, the allocated buffer gets automatically over-allocated slightly when it's used as a vertex buffer. why? because the requirement there is that each buffer element should be readable using 16-byte SSE load instructions. it's giving "room to breathe" energy ✨

if ptr is not null, it gets used to return the address of the host data buffer. if dptr is not null, it gets used to return the address of the device data buffer. either ptr or dptr or both can be null, no stress. in that case, rtcGetGeometryBufferData and rtcGetGeometryBufferDataDevice can be used to get the addresses of the host and device data buffers. slay 🫶

now, the important part — the application is responsible for keeping the host and device memory in sync. you heard me. the host memory has to be updated before calls of rtcCommitScene involving the associated geometry. don't forget, bestie, she will not do it for you 😭

if Embree has no SYCL support, or the associated Embree device is not a SYCL device, then the dptr argument will return the same address as ptr if on null. in this case the function rtcSetNewGeometryBufferHostDevice will behave like rtcSetSharedGeometryBuffer. iconic, honestly 💀

⚠️ friendly reminder that the sync-it-yourself bit is on you, not on Embree. host memory, updated, before rtcCommitScene. every time. 🙈

---

👑 EXIT STATUS 👑

on failure an error code is set, and you can query it using rtcGetDeviceError. go check her, she'll tell you what went wrong 🔥

---

💀 SEE ALSO 💀

• [rtcSetNewGeometryBuffer]
• [rtcSetGeometryBuffer]
• [rtcSetSharedGeometryBuffer]
• [rtcGetGeometryBufferData]
• [rtcGetGeometryBufferDataDevice]

---

okay that's the whole page babes, every last flag, arg, and warning accounted for, nothing skipped, we ate 🍓

rtcSetNew...HostDevice(3) — mwah, go touch some geometry buffers, ily, byeee 💜🧚‍♀️