Shadows! builders! problems!

i am confused about my shadows.

i use bvh/bvh as builder/traverser, cause this is the only builder making use of the boundingbox program and not building the bounding box over the triangle data its self. it seems that other builders arent able to use the boundingbox program. trbvh is ‘strongly considered for all dataset’, only for triangles?

my primitives have 3 vertices and 3 normals and a biquadratic surface.
with these primitives i made a icosahedron, looking like a sphere.
i have one light in front of the object. if i put shadows on, i ll get a shadow on the the front of the object faceing the light. i dont like that.
but when i take only the primitives setting up the front of the icosahedron (looking like a half of a sphere), i ll get no shadows on these primitives. so this shadow is no self shadow.
i am confused of the behaviour of any hit. my material is the obj_material.cu (with phong.h) from the samples.
if i take a epsilon bigger than twice the radius of the icosahedron, there is no shadow at the front.

if i take trbvh i have no shadows at the front, but ill get some holes concerning the wrong boundingboxes.
if i take noAccel i have the wrong shadow.

tried some changes at the anyhit ray creating, but all seems to be set up right. first i thought the any hit ray are maybe sended into the wrong direction, but they arent.
where could be a mistake? are there known bugs?

my fault. during some test i was sending the any hit rays in the wrong direction and forgot to undo this, thats why other tests have not been working.

the code i ll get the wrong shadows.

static __device__ void phongShadowed()
{
  prd_shadow.attenuation = optix::make_float3(0);
  rtTerminateRay();
}

i have to check the any hit ray if they are in the tmin and tmax

static __device__ void phongShadowed()
{
  if(ray.tmin>t_hit&&ray.tmax<t_hit){
    prd_shadow.attenuation = optix::make_float3(0);
    rtTerminateRay();
  }
}

or

static __device__ void phongShadowed()
{
  if(ray.tmin<t_hit||ray.tmax<t_hit){
    rtIgnoreIntersection();
  }else{
    prd_shadow.attenuation = optix::make_float3(0);
    rtTerminateRay();
  }
}

which way is better or are they the same?

the bvh/bvh and the NoAccel builder need these checks. Trbvh/bvh dont. maybe these differences would be interesting in the Programming guide.

**edit
the any hit program calls phongShadowed.
RT_PROGRAM void any_hit_shadow()
would look better in the code line 1.

forget my last post. it kills all shadows. i better should delete it.

i have managed to get the trbvh running with different boundingboxes. there seems to be a bug mentioned already here [url]Crash while validating a context - OptiX - NVIDIA Developer Forums
i use OptiX 3.6.3
i have changed the buffers name from vertex_buffer to vvertex_buffer and vindex_buffer to vvindex_buffer and suddenly trbvh works (without setting the triangle acceleration properties). my project based on Sample6. maybe there are some deeper dependencies, i didnt see. but for me its a bug.

but i am disappointed that it didnt fix my shadow problems, which realy look like a bug aswell.
the trbvh brings some more speed.

shadowBugLightFromTop.PNG1290×999 42.6 KB

shadowBugLightFromTop.PNG1290×999 42.6 KB

does anyone have an idea how to fix that shadow seen in PNG attached in the last post?
this behaviour is acceleration independent.

Thanks for your solution. It bothers me couple of days, until I see your post. When I changed the vertex_buffer to vvertex_buffer and vindex_buffer to vvindex_buffer, Trbvh works…
But I’m still not clear why this happens. Its a bug for Optix?

Check out OptiX 3.8. We’ve fixed bugs with Trbvh and have also cleaned up stuff in our sample infrastructure related to the named vertex and index buffers. Note that the API has default values for the “vertex_buffer_name” and “index_buffer_name” properties of AS builders. So if your buffers have those defaults as names, or if you set those properties to your buffers’ names it will treat your buffers as triangles and build the BVH in a more optimal way for triangles. This is almost always what you want. But if you don’t want it you can always suppress it and build your BVH over AABBs using the bounding box program.

I can’t see your shadow picture, but it could be that what’s going on here is due to splitting in the BVH build. Sometimes we can get much tighter bounds on a primitive by bounding it with two or more small boxes than one larger box. In this case the primitive is a child of all of the split boxes. Thus, the same ray can be intersected against the same triangle multiple times. If you’re doing cumulative things in your any hit program the splitting can affect your results. You may see a darker shadow on one side of the bounding box than the other.

Your epsilon should be small, nowhere near the size of your scene.