topic Hi Sven, in Intel® Embree Ray Tracing Kernels

Problems with RTC_GEOMETRY_TYPE_FLAT_LINEAR_CURVE (3.5.0)

AndrewC — Thu, 21 Feb 2019 02:50:18 GMT

I am having some very odd issues with RTC_GEOMETRY_TYPE_FLAT_LINEAR_CURVE.

I am intersecting rays with a mixture of lines and triangle geometry.

embree 3.5.0 is returning the correct line primitive in the ID of the ray hit for the line p0->p1

I then compute the intersection location on the line in two ways as a sanity check

using p0+(p1-p0)*ray.u
using ray.org+ray.dir*ray.tnear ( should be close within radius of line)

Both computed locations are on very close to the line from p0->p1, but on many occasions they are significantly different. It appears ray.u is in error.

The radius of the line is much smaller than the problematic errors.

This should not happen, the

SvenW_Intel — Thu, 21 Feb 2019 07:18:23 GMT

This should not happen, the distance from the hit point calculated using tfar should be at most line radius away of the hit point calculated using u. Could you please create a reproducer with one line segment and one ray?

Also you write that you use ray.tnear to calculate the hit point. This is wrong it should be ray.tfar.

Hi Sven,

AndrewC — Thu, 21 Feb 2019 17:08:00 GMT

Hi Sven,

Sorry,typo, I meant ( and what I actually use) is of course

ray.org+ray.dir*ray.tfar

I have attached some images of the problem. The small pink spheres are the points as calculated using p0+(p1-p0)*ray.u

The side view just shows the ray source location. The top view illustrates the issue.

There are only 4 edges , each edge is length 10 - radius 0.001

The lines are the rays that are recorded as hits. You can see how some ray end points are way off the location computed from ray.u, while some are as expected.

I wonder if no-one has seen this issue as embree always "hits" the correct edge, it just seems that sometimes ray.u is wrong. For rendering hair or similar this might not be ever noticed.

I tried this problem with 128 edges on the same square geometry, and the behaviour was the same. embree always hits the right edge, but in some cases the ray.u seems "wrong".

I will try for a reproducer.

I have convinced myself

AndrewC — Thu, 21 Feb 2019 18:59:15 GMT

I have convinced myself Embree has a bug in the computation of ray.u for this geometry type. After Embree finds an intersection, I compute my own "u" using the ray and line geometry. The "u" I compute is correct ( and in some cases quite different to the embree ray.u).

I have resolved the issue -

AndrewC — Wed, 27 Feb 2019 21:20:14 GMT

I have resolved the issue - and it's not a bug in embree. It was my mistake.

My mistake was in the intersectionFilter routine

To get the value of "u" you MUST use

float u=RTCHitN_u(hits,N,rayID);

NOT

float u=ray.u;