RTCSETGEOMETRYINTERSECTFILTERFUNCTION(3embree4)
β¨ NAME β¨
rtcSetGeometryIntersectFilterFunction β okay bestie, this one sets the intersection filter for the geometry π
πΈ SYNOPSIS πΈ
#include <embree4/rtcore.h>
struct RTCFilterFunctionNArguments
{
int* valid;
void* geometryUserPtr;
const struct RTCRayQueryContext* context;
struct RTCRayN* ray;
struct RTCHitN* hit;
unsigned int N;
};
typedef void (*RTCFilterFunctionN)(
const struct RTCFilterFunctionNArguments* args
);
void rtcSetGeometryIntersectFilterFunction(
RTCGeometry geometry,
RTCFilterFunctionN filter
);
π DESCRIPTION π
So rtcSetGeometryIntersectFilterFunction is the function that registers an intersection filter callback function (that's the filter argument, bestie) for whichever geometry you point at (the geometry argument π―).
One (1) single callback per geometry, that's the rule β if you call it again it just overwrites the old one, no stacking, no collecting, it's giving "there can only be one" π. And if you pass NULL as the function pointer? Boom, the registered callback is disabled, gone, bye π.
Here's the tea: the intersection filter function you registered gets invoked for every hit that shows up during the rtcIntersect-type ray queries, and it gets to accept or reject that hit. It's literally main character energy for your primitives. What's it for? Think defining a silhouette for a primitive and rejecting hits that land outside that silhouette π¦. Like, imagine a tree leaf modeled with an alpha texture that decides whether hit points are inside or outside the leaf π. That's the vibe.
β οΈ Real talk, this next part matters: if theRTC_BUILD_QUALITY_HIGHmode is set, the filter functions may be called multiple times for the same primitive hit. And on top of that, rays hitting exactly the edge might also report two hits for the same surface. For certain use cases the application may have to work around this limitation by collecting already reported hits (thegeomID/primIDpairs, iykyk) and ignoring the duplicates π.
π The Callback Arguments π
The filter function callback, which is of type RTCFilterFunctionN, gets handed a bunch of arguments through the RTCFilterFunctionNArguments structure. Let's break it down, no gatekeeping:
- The
validparameter points to an integer valid mask β0means invalid and-1means valid β - The
geometryUserPtrmember is a user pointer that you can optionally set per geometry through thertcSetGeometryUserDatafunction π«Ά - The
contextmember points to the ray query context that got passed to the ray query function π - The
rayparameter points toNrays in SOA layout β - The
hitparameter points toNhits in SOA layout to test π― - The
Nparameter is the number of rays and hits insiderayandhitπ’ - The hit distance is provided as the
tfarvalue of the ray π - If the hit geometry is instanced, the
instIDmember of the ray is valid, and the ray and the potential hit are in object space πͺ
π What Your Filter Callback Actually Does π
The filter callback function has one job: for each valid ray, check whether it wants to accept or reject the corresponding hit.
- To reject a hit, the filter callback function just has to write
0to the integer valid mask of the corresponding ray β - To accept the hit, it just has to leave the valid mask set to
-1π
And here's a lil bonus when you accept: the filter function is further allowed to change the hit and decrease the tfar value of the ray β but bestie, it should not modify other ray data, nor any inactive components of the ray or hit. Stay in your lane, respectfully π.
π§ How To Write The Implementation π§
The implementation of the filter function has options, and honestly? Both are valid:
- You can choose to implement a single code path that uses the ray access helper functions
RTCRay_XXXand the hit access helper functionsRTCHit_XXXto access the ray and hit data π«§ - Or, alternatively, the code can branch to optimized implementations for specific sizes of
Nand cast the ray and hit inputs to the proper packet types π
Pick your fighter, both slay π₯
π EXIT STATUS π
On failure an error code is set that can be queried using rtcGetDeviceError. So like, if something goes sideways, that's where you go looking π
π SEE ALSO π
rtcSetGeometryOccludedFilterFunction
And that's the whole page, bestie! This was rtcSetGeometryIntersectFilterFunction(3) from the Embree Ray Tracing Kernels 4 manual β the footer's lil abbreviation is rtcSetGeo...erFunction(3), which is just the name getting squished to fit, no cap π. Go forth and filter those hits β¨ππ
π¦ 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