Nontrivial Acceleration is applied to scenes consisting of triangles only?

Gaming and Visualization Technologies Visualization OptiX
1

Take the sample transparency as a reference. I created a scene = 27 cubes + 1 parallelogram (square). I expected that OptiX can help me to speedup a program.
1 version:
As in transparency, without sphere, 27 boxes instead of 9, floor.
Thus I created 28 (27 + 1) geometries and 28 geometryinstaces. Then 1 geometrygroup GG including those. I tried several variants, e.g.

GG->setAcceleration( m_context->createAcceleration("Lbvh","Bvh") );
  GG->setAcceleration( m_context->createAcceleration("Trbvh","Bvh") );
  GG->setAcceleration( m_context->createAcceleration("NoAccel","NoAccel") );

All variants demonstrate almost the same time.
2 version - Another scene graph:

boxes = new BOX [27];
  Geometry box = m_context->createGeometry();
      box->setPrimitiveCount( 27u );
      box->setBoundingBoxProgram( box_bounds );
      box->setIntersectionProgram( box_intersect );
  Material box_matl = m_context->createMaterial();
      box_matl->setClosestHitProgram( CRL_DIRECT_RAY_TYPE, transparent_ch );
      box_matl["refraction_index"]->setFloat( 1.2f );
...
  // Floor
  Geometry parallelogram = m_context->createGeometry();
  parallelogram->setPrimitiveCount( 1u );
...
  GeometryInstance gi = m_context->createGeometryInstance(); 
  gi->setGeometry( box );
  gi->setMaterialCount( 1 );
  gi->setMaterial( 0, box_matl );

  GeometryInstance gf = m_context->createGeometryInstance(); 
  gf->setGeometry( parallelogram );
  gf->setMaterialCount( 1 );
  gf->setMaterial( 0, floor_matl );

  GeometryGroup geometrygroupbox = m_context->createGeometryGroup();
  // beneath: several attempts with accels. All 
  //geometrygroupbox->setAcceleration( m_context->createAcceleration("Lbvh","Bvh") );
  geometrygroupbox->setAcceleration( m_context->createAcceleration("Trbvh","Bvh") );
  //geometrygroupbox->setAcceleration( m_context->createAcceleration("NoAccel","NoAccel") );
  geometrygroupbox->setChildCount( 1u );
  geometrygroupbox->setChild( 0, gi );

  GeometryGroup geometrygroupflo = m_context->createGeometryGroup();
  //geometrygroupflo->setAcceleration( m_context->createAcceleration("Lbvh","Bvh") );
  geometrygroupflo->setAcceleration( m_context->createAcceleration("NoAccel","NoAccel") );
  geometrygroupflo->setChildCount( 1u );
  geometrygroupflo->setChild( 0, gf );

  Group gr = m_context->createGroup();
  gr->setChildCount(2);
  gr->setChild(0, geometrygroupbox);
  gr->setChild(1, geometrygroupflo);
  gr->setAcceleration( m_context->createAcceleration("NoAccel","NoAccel") );

  m_context["top_object"]->set( gr );

All variants of accel demonstrate almost the same time too.
Does it mean that from acceleration point of view the word “primitive” means “triangle”? I.e., an acceleration of other primitive types are not supported.

2

Sorry, I forgot my environment:
Win 8.1, x64, VS2010, OptiX 3.5.1, CUDA 5.5, GeForce GTX 650 ti.
Also notebook
Win 8.1, x64, VS2010, OptiX 3.5.1, CUDA 5.5, GeForce GT 650M.

3

The same time of what? Building the acceleration structure?

These three acceleration structure builders are the fastest you can have.
They might take only a few milliseconds to build the hierarchy over your very few objects.

Rendering performance will differ though. Especially NoAccel would need to test every geometric primitive in one GeometryInstance for intersection. That would be horribly slow with a huge number of triangles for example.

In OptiX a “primitive” is user defined! You implement what it means with the bounding box and intersection programs you provide.
A bounding volume hierarchy can be built around anything for which you implement these.

4

Sorry,
“The same time of what? Building the acceleration structure?”
means the same time of a program execution ~ 118 to 122 secs.
I know theory of acceleration structures. But in my experiments {(“NoAccel”,“NoAccel”)} and {“Lbvh”,“Bvh”} show similar computational time.
Probably I did some mistake, I’ll re-examine the code.

When I represented a set of 27 cubes as a mesh of triangles {“Lbvh”,“Bvh”} has became too faster than {(“NoAccel”,“NoAccel”)} as I expect.

5

As said Lbvh and Trvbh are super fast and even suitable for dynamic geometry. Full program execution time is not a feasible measurement to analyze acceleration structure building times with your very small scene size or ray tracing rendering times in general.

Please have a look into this post for more fine grained measurement options: