Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Intel Community
- Visual Computing (Graphics and Gaming)
- Intel® Embree Ray Tracing Kernels
- Problems with RTC_GEOMETRY_TYPE_FLAT_LINEAR_CURVE (3.5.0)

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Highlighted

AndrewC

New Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-20-2019
06:50 PM

89 Views

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.

Accepted Solutions

Highlighted

AndrewC

New Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-27-2019
01:20 PM

89 Views

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;

4 Replies

Highlighted

SvennW_Intel

Moderator

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-20-2019
11:18 PM

89 Views

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.

Highlighted

AndrewC

New Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-21-2019
09:08 AM

89 Views

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.

Highlighted
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).

AndrewC

New Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-21-2019
10:59 AM

89 Views

Highlighted

AndrewC

New Contributor I

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-27-2019
01:20 PM

90 Views

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;

For more complete information about compiler optimizations, see our Optimization Notice.