rtcSetGeo...dFunction(3)
π rtcSetGeo...dFunction β bestie edition β¨
okay so this is from the Embree Ray Tracing Kernels 4 manual (rtcSetGeo...dFunction(3)), and it's all about teaching your custom geometry how to get occluded. no cap, this one's a vibe. π¦
β¨ NAME β¨
rtcSetGeometryOccludedFunction β sets the callback function to test a user geometry for occlusion π
π SYNOPSIS π
#include <embree4/rtcore.h>
struct RTCOccludedFunctionNArguments
{
int* valid;
void* geometryUserPtr;
unsigned int primID;
struct RTCRayQueryContext* context;
struct RTCRayN* ray;
unsigned int N;
unsigned int geomID;
};
typedef void (*RTCOccludedFunctionN)(
const struct RTCOccludedFunctionNArguments* args
);
void rtcSetGeometryOccludedFunction(
RTCGeometry geometry,
RTCOccludedFunctionN filter
);
πΈ DESCRIPTION πΈ
so basically, rtcSetGeometryOccludedFunction registers a ray/primitive occlusion callback function (that's the filter argument, bestie) for the user geometry you picked (that's the geometry argument π«Ά).
one (1) callback per geometry, periodt. only a single callback function can be registered per geometry, and if you call this again it just overwrites whatever you set before β no stacking, no drama. and if you pass NULL as the function pointer? that disables the registered callback function entirely. bye bestie π
the callback you registered gets invoked by rtcOccluded-type ray queries, and its whole job is testing whether the rays of a packet of variable size are occluded by a user-defined primitive. the callback is of type RTCOccludedFunctionN and it gets a bunch of arguments handed to it through the RTCOccludedFunctionNArguments structure. let's break down the cast, iykyk:
Nβ the ray packet sizevalidβ points to an array of integers saying whether each corresponding ray is valid (-1) or invalid (0)geometryUserPtrβ points to the geometry user data you set earlier throughrtcSetGeometryUserDatacontextβ points to the ray query context that got passed to the ray queryrayβ points to a ray packet of variable sizeNgeomIDandprimIDβ identify the geometry ID and primitive ID of the primitive to intersect
so what's the actual task here? the callback function has to intersect each active ray from the ray packet with the specified user primitive. and listen:
- if the user-defined primitive is missed by a ray of the ray packet, the function should just return without modifying the ray. leave it alone, it's fine π§
- if an intersection of the user-defined primitive with the ray was found in the valid range (from
tneartotfar), it should set thetfarmember of the ray to-inf. slay.
β heads up! a primitive might have multiple intersections with a ray, so if you actually want filtering of intersections, the occlusion filter function needs to be invoked by the user geometry occlusion callback for each encountered intersection. you can do that with the rtcInvokeOccludedFilterFromGeometry call.
and the best part: within the user geometry occlusion function, it is safe to trace new rays and create new scenes and geometries. go off, main character energy π
π EXIT STATUS π
on failure an error code gets set, and you can go query it with rtcGetDeviceError. not me checking the error code every time π
π SEE ALSO π
[rtcSetGeometryIntersectFunction][rtcSetGeometryUserData][rtcInvokeOccludedFilterFromGeometry]
that's the whole page bestie, you ate it π
β¨ this was rtcSetGeo...dFunction(3) from the Embree Ray Tracing Kernels 4 manual β go forth and occlude responsibly π«Άππ
π¦ where this page comes from
- alpine 3.24: embree-doc 4.4.1-r0 Β· Apache-2.0
- arch rolling: embree 4.4.1-1 Β· Apache-2.0
- fedora 43: embree 4.4.1-1.fc43 Β· Apache-2.0
- fedora 44: embree 4.4.1-1.fc44 Β· Apache-2.0
- nixpkgs unstable: embree 4.4.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms