Shared vertex buffers

[Patrick_S_4]

Hi all, 

I was just wondering what the status of geometries will be if there are unused vertices in the buffer. Will these be treated as primitives eligible for ray intersections?

My curiosity stems from the idea of using the same vertices (in memory) to define the boundaries between adjacent geometries in a scene, removing any possible overlaps due to numerical error. The idea would be to have one single vertex buffer for all geometries, each geometry having an index buffer using a subset of the vertex buffer it needs to define the mesh.

Patrick 

[SvenW_Intel]

Only vertices referenced by the index buffer are valid geometry and handled by Embree. All other vertices in the vertex array are just ignored. Thus there is no problem to have unused vertices in the vertex buffer.

[Patrick_S_4]

Thank you! This helped with a lot of problems I was having. 

[Patrick_S_4]

I'm running into problems when attempting to share the same vertex buffer between multiple scenes. It appears that I'm getting hits from other scenes (specifically the last scene I create) when firing on any given scene. Is it not possible to share a vertex buffer between multiple scenes successfully?

Cheers,

Patrick 

[SvenW_Intel]

You can share the same vertex buffer multiple times in different scenes. However, that the buffer is shared also means that you cannot modify it for only a single scene only. If you modify the buffer, you modify it for all scenes.

[Patrick_S_4]

I believe that I'm now using the shared vertex buffer as intended now, but I'm now getting some odd behavior.

Ray properties are coming back with invalid results such as intersection distances of inf and null triangle normals. 

I've traced this all the way back to the intersection functions in Embree. They seem to be getting the correct vertices for the intended triangle, but somewhere in the intersection process things go awry. 

The strangest part of this is that when run with valgrind the ray query returns the intended result. For a time this led me to believe that I wasn't using the shared buffers correctly, but after triple checking my code I believe I'm following the instructions in the Embree api documentation correctly.

Has anyone encountered something like this before?

[Patrick_S_4]

Figured this out. 

My XEON_ISA cmake variable was set to AVX2. After changing this to SSE2, the ray tracing application started working as expected. 

The reason why isn't entirely clear to me though... is it possible that my architecture doesn't fully support AVX2 instructions?

My machine uses an i7 core if that helps.

[SvenW_Intel]

I have not seen such behaviour. But it seems you free the buffer you share with Embree too early. You have to keep the buffer alive as long as the Embree mesh is still existing.

Could you initialize Embree through rtcInit("verbose=2") and send us the output when running your application. Are you using the single ray rtcIntersect function? Could you check if the code works with AVX ? Does everything work if you do not use the vertex buffer sharing?

Could you also try if one of these solves the issue:

rtcInit("accel=bvh4.triangle4")

rtcInit("accel=bvh4.triangle4i")

[Patrick_S_4]

Hi Sven, 

Using AVX for the XEON_ISA variable gets the program to work.

I've attached the verbose output from my program run with both AVX and AVX2 (labeled accordingly). 

Everything does work if I don't use vertex buffer sharing, though I think I'm using it correctly. The memory block containing the vertices shouldn't be released until the very end of my program, after all calls to the Embree kernel are done.

Using both of those flags in the rtcInit command fixes the problem as well. What do they indicate to the kernel?

Cheers, 

Patrick 

[BenthinC_Intel]

Hi Patrick,

it seems to be that some internal AVX2 optimizations are screwing up the intersection distance/normal. I'll have a look at this issue asap.

Two questions: Which embree version are you using and did you set the RTC_SCENE_ROBUST flag?

Carsten. 

[SvenW_Intel]

Hi Patrick, this issue is caused only when the code is compiled with GCC. You can work around the issue by using the precompiled binaries form the embree webpage which are compiled with ICC.

[BenthinC_Intel]

Hi Patrick,

we'll try to fix the GCC/AVX2 optimization issues in the next Embree release.

[Patrick_S_4]

Carsten and Sven, 

I'm using the master branch of Embree right now (hash -  c10f373c2e37ff37f17929c323a62f39e9a8a242) 

I am indeed using the RTC_SCENE_ROBUST flag. 

Thank you for your help! I'll likely continue using AVX for now and look to rebuild when the next version is released. 

Cheers, 

Patrick

[BenthinC_Intel]

Hi Parick,

does the latest Embree version (2.6.2) resolves this issue?

Thanks.