how to make sure PrimID is ok ?

[kuranes__tuan]

Hi,

Using Embree 3.6.1 (github tab) is very nice and I get nice intersection, but as soon as I want to use PrimID, It seems I hit a wall.

There's not much documentation 

I'm using it with a triangle mesh, feeded with srcIndices and srcVertices, just vertex and index. 

When I get a hit, I can see it looks good (if I draw white dot for each hit I get mesh shapre) but as soon as
I use prim ID to get back to my data, I get very strange results

const unsigned int triSrcPos = ray.hit.primID* 3;

const Vertex &v0Src = srcVertices[srcIndices[triSrcPos + 0]];

const Vertex &v1Src = srcVertices[srcIndices[triSrcPos + 1]];

 const Vertex &v2Src = srcVertices[srcIndices[triSrcPos + 2]];

... then I use it for getting texture of that triangle

v0Src.texID <= not good results

Same for texcoord, doesn't seem to be the good ones

Perhaps I misunderstood PrimID, it not a value of  "index of triangles" in this case ?

If there's anything I missed that makes PrimID relevant, it would help a lot, thanks!

btw, Embree is great work.

[SvenW_Intel]

Your code looks correct. The primID is the index of the n'th triangle of a mesh. Thus 3 consecutive indices in the index array match to one triangle. Which rtcIntersect function are you using? I suppose you have a bug somewhere in your code, try debugging with just two triangles, from which you know which one you hit.

[kuranes__tuan]

Using rtcIntersect1, so standard stuff for now.

Thanks a lot for the confirmation, wasn't sure I was using the primID right, seem it's indeed, looks like my code might be the culprit. 

Will try with 2 triangles, should makes it clearer indeed, thanks for the hint.

If I can go OT, I do have another question, this time about filter: 

I'd like to get the "closest to a point in space" instead of "closest to ray origin", not sure the intersectFilter might make it ?

like 

// /!\ need closest to Point Target Distance to Origin, not closest to ray origin

if (fabsf(targetDistance - rayHit.tfar) >= fabsf(targetDistance - context.previousClosestRayTFar){

valid[0] = 1;

context.previousClosestRayTFar = rayHit.tfar;

}

else{

valid[0] = -1:

}

I have doubt because of the multithreaded nature of intersection, as it would need to store the "new closest point" while *inside* the intersection filter.

[SvenW_Intel]

Could you explain more what you mean with "closest to a point in space". Is the point you are looking for still on the ray?

[kuranes__tuan]

yes, it's on the ray

Here's a drawing

If Origin is ray origin, and each "x" a hit along the ray, and "X"  a static position on the ray (not a hit)

Origin-------x----x------------X----x---------x----->

I want the closest x to X. (here the one just after X)

Sort of High Res Mesh to Low res mesh baking problem, where I trace to get the nearest "high res triangle intersection" (submitted to embree) to the "low res triangle" (not submitted to embree)

Thanks again, sorry for being unclear

[SvenW_Intel]

This will work with the intersection filters. The intersection filter function will have to check whether the potentialHit is closer to X than the current best hit. If so you store the new best hit in a special location of your intersect context (just add more data to the end of the context). The intersection filter will reject each hit that is farther to X than the current best hit. When the filter found a hit that is closer to X than the best hit, it will reject the hit if it is to the left of X, and accept it when it is to the right of X. That acceptance will shrink the tfar distance and speed up calculations. There is no way of shrinking the tnear distance.

A second approach to try is just tracing two rays from X, once towards the right and once towards the left. This could even be faster.

[kuranes__tuan]

Thanks a lot for the answer.

>  store the new best hit in a special location of your intersect context

Ok, so you confirm we can store data and reuse in the context for the same ray, thanks !

>accept it when it is to the right of X 

Indeed nice optimisation, thanks!

> A second approach to try is just tracing two rays from X, once towards the right and once towards the left. This could even be faster.

I'm doing the two ray thing for now, I was afraid of two things

- missing the case where the high res mesh triangle and low res mesh triangle are exactly the same (triangle not decimated). Meaning I was afraid intersection precision where the intersection is exactly at ray origin could be problematic ?

- Was afraid it would be too slow compared to using one ray + filter. but if it might be even faster it's good then.

Thanks again for the all the great answer