The C API documentation inside the OptiX API Reference can be found when combining the names of the C++ wrapper objects and function names:
GeometryTriangles::setVertices maps to rtGeometryTrianglesSetVertices which is this:
[url]https://raytracing-docs.nvidia.com/optix6/api_6_5/html/group___geometry_triangles.html#ga565d463a96fb69617e6d284ab4536792[/url]
(If you exchange the 6_5 against 6_0 in these links you get the old docs.)
The C++ wrapper defines some overloads for the standard cases which calculate the remaining arguments not shown in the above setVertices() call.
That makes the buffer and vertex data layout in that known to the GeometryTriangles node. (It’s similar to a vertex array setup in OpenGL, if that helps.)
Similar for all other of the C++ wrapper calls which map directly to a C API.
(I seriously recommend to not use any of the C++ wrapper functions which have been added for convenience, like removeChild() with an object as argument because there is no C API for that. Instead track the child index as well and use the version with the child index argument, much faster!)
The geom_tri[“vertex_buffer”]->setBuffer( vertex_buffer ); is aconvenience functionality of the C++ wrapper which implements the operator[] with a string argument to handle RTvariable construction and lookup.
It first queries if an RTvariable of that name has been declared at this scope, and if it doesn’t exist, creates it at that object’s scope (here at the GeometryTriangles node). The member function setBuffer() assigns a buffer to that variable.
That buffer in the argument can then be accessed by the attribute program assigned to the GeometryTriangles node under the name “vertex_buffer”. To be able to access that in device code, you need a matching rtBuffer declaration with the same name and format or validation fails.
All of the above can be seen inside the OptiX SDK 6.0.0\include\optixu\optixpp_namespace.h header which implements that and calls the underlying C API. You can single-step debug through that with the OptiX API Reference open to lookup what the called C functions do.
Sidenote on the OptiX C++ wrapper: Note that it’s not ref-counting the underlying OptiX objects! You must keep track of the C++ objects and call destroy() explicitly to avoid memory leaks. (One of my pet peeves with all OptiX SDKs < 7.)
Now when you want to update the vertex data inside that buffer for an animation you would just update that vertex buffer data (map, write, unmap the buffer) and if the topology doesn’t change (amount of vertices and, if indexed, the connectivity information stays the same => morphing) neither of the two calls above are required again. Just all acceleration structures on the way to that leaf GeometryTriangles node need to be marked dirty to rebuild or refit the affected acceleration structures during the next launch.