latest version does not compile

[Hurleyworks]

Hi again :)

The latest GitHub version does not compile because of an error on line 785 of optix_util.cpp. Looks like getName() returns a const char* instead of a std::string;

I see you have a new RTX 3080 now. I am jealous. :)

I also had a question about object replacement. I'm trying to do a fluid simulation where a new fluid mesh is constantly generated. Right now I am just creating new vertex buffers and triangle buffers and rebuilding the GAS, the hitgroupSBT and the top level IAS. Can you tell me if that's the best way to do object replacement? I am getting okay results but I'm wondering if performance can be improved. https://www.youtube.com/watch?v=dXsj5O6w0no&ab_channel=HurleyworksInc

  OptixVertices newVertices;
    uint32_t vertexCount = addVertices (newMesh, newVertices);

    OptixTriangles newTriangles;
    uint32_t triangleCount = addAllTriangles (newMesh, newTriangles);

    uint32_t geoGroupID = node->getClientID();
    GeometryGroupRef& geomGroup = state->geomGroups.at (geoGroupID);

    VertexBufferRef vertexBuffer = make_shared_with_deleter<cudau::TypedBuffer<Shared::Vertex>> (
        [] (cudau::TypedBuffer<Shared::Vertex>* p) {
            p->finalize();
        });
    vertexBuffer->initialize (state->cuContext, g_bufferType, newVertices);

    GeometryInstanceRef& geoInst = geomGroup->geomInsts[0];
    geoInst->vertexBuffer->finalize();
    geoInst->vertexBuffer = vertexBuffer;

    geoInst->triangleBuffer.finalize();
    geoInst->triangleBuffer.initialize (state->cuContext, g_bufferType, newTriangles, state->cuStream);

    geoInst->optixGeomInst.setVertexBuffer (*vertexBuffer);
    geoInst->optixGeomInst.setTriangleBuffer (geoInst->triangleBuffer);

    Shared::GeometryData geomData = {};
    geomData.vertexBuffer = vertexBuffer->getDevicePointer();
    geomData.triangleBuffer = geoInst->triangleBuffer.getDevicePointer();
    geoInst->optixGeomInst.setUserData (geomData);

    geomGroup->optixGAS.markDirty();

[shocker-0x15]

Oh, thanks for the report! It failed in asserts which are removed in Release build. Maybe it's time to write a test for this library.

RTX 3080 also helps to warm my room :D

I'll check your question later.

[shocker-0x15]

• Calling cudu::Buffer::initialize/finalize() every frame is not recommended because it involves GPU memory allocation and I think it is heavy operation. So it seems better to allocate conservative size of vertex buffer and triangle buffer in advance and reuse them every frame.
• Are these vertex/triangle data generated on CPU? If so you may need to prepare these buffers with double-buffering to avoid CPU/GPU synchronization.
• Is topology of fluid always changed? If not, you don't need to update triangle buffer and only need to update vertex buffer's content. In that case sometimes you don't need to call GAS::markDirty() then rebuild the GAS, instead only updating GAS/IAS. Updating GAS doesn't invalidate SBT layout, meaning you don't need update SBT. Of course GAS's structural quality becomes worse (== slow ray trace perf) than rebuild while update itself is quite faster than rebuild.
  • I think but not entirely sure that rebuild as high-quality update (== not changing the number of children, topology of each child, build flags, buffer for AS) doesn't change GAS's resulting OptixTraversableHandle from rebuild. This means that calling markDirty() of an IAS to which the GAS belongs to is not required (only updating is required) therefore it doesn't require SBT rebuild. I'm not entirely sure though. Related forum thread: https://forums.developer.nvidia.com/t/updating-as-guarantees-optixtraversablehandle-unchanged/149366/5
• And this is a topic orthogonal to OptiX utility. When you need a lot of transfer from CPU to GPU, it is maybe better to use pinned-host memory. (See CUDA's documentation. I'm not so familiar with this :)

[shocker-0x15]

Hit group SBT layout/size is determined by

• User data size of Material/GeometryInstance/GAS
• The number of materials of each child of a GAS
• The number of ray types of a GAS
• How GASs are instantiated with material set indices

So SBT layout invalidation is not required in theory even in the case where you change both vertex/triangle buffer and need to call markDirty() to rebuild a GAS. However the current implementation of the utility always invalidates SBT layout when markDirty() is called for simplicity. It is maybe worth exposing a variant of markDirty() without invalidating the SBT layout.

But if rebuilding SBT is not a heavy task, this is not a problem in the first place.

[Hurleyworks]

Thanks for the help! The vertex/triangle data is generated on the CPU using OpenVDB. I'm emitting fluids so the vertex and triangle counts are usually different in each incoming mesh.

I tried pre-allocating vertex and triangle buffers and the updating them with the new data when a new fluid mesh arrives but I am getting rendering errors. Do you know what might cause this.? I have tried updating the fluid buffers only after rendering and cuStreamSynchronize () but still get the rendering artefacts..

const uint32_t DEFAULT_FLUID_VERTICES = 60000;
const uint32_t DEFAULT_FLUID_TRIANGLES = 120000;

//------------- create fluid mesh
    VertexBufferRef vertexBuffer = make_shared_with_deleter<cudau::TypedBuffer<Shared::Vertex>> (
        [] (cudau::TypedBuffer<Shared::Vertex>* p) {
            p->finalize();
        });

    OptixVertices maxVertices (DEFAULT_FLUID_VERTICES, Shared::Vertex{});
    std::memcpy (maxVertices.data(), vertices.data(), vertices.size() * sizeof (Shared::Vertex));

    vertexBuffer->initialize (state->cuContext, cudau::BufferType::Device, maxVertices);

    OptixTriangles maxTriangle (DEFAULT_FLUID_TRIANGLES, Shared::Triangle{});
    std::memcpy (maxTriangle.data(), triangles.data(), triangles.size() * sizeof (Shared::Triangle));

    GeometryInstanceRef geomInst = make_shared_with_deleter<GeometryInstance> (GeometryInstance::finalize);
    geomInst->vertexBuffer = vertexBuffer;

    geomInst->triangleBuffer.initialize (state->cuContext, cudau::BufferType::Device, maxTriangle, state->cuStream);
    geomInst->optixGeomInst.setVertexBuffer (*vertexBuffer);
    geomInst->optixGeomInst.setTriangleBuffer (geomInst->triangleBuffer);

    Shared::GeometryData geomData = {};
    geomData.vertexBuffer = vertexBuffer->getDevicePointer();
    geomData.triangleBuffer = geomInst->triangleBuffer.getDevicePointer();
    geomInst->optixGeomInst.setUserData (geomData);

// -----------update fluid mesh
    GeometryInstanceRef& geoInst = geomGroup->geomInsts[0];

    Shared::Vertex* const verts = geoInst->vertexBuffer->map();
    std::memcpy (verts, newVertices.data(), newVertices.size() * sizeof (Shared::Vertex));
    geoInst->vertexBuffer->unmap();

    Shared::Triangle* const tris = geoInst->triangleBuffer.map();
    std::memcpy (tris, newTriangles.data(), newTriangles.size() * sizeof (Shared::Triangle));
    geoInst->triangleBuffer.unmap();

    geomGroup->optixGAS.markDirty();

[shocker-0x15]

GeometryInstance takes BufferView, not cudau::Buffer (There is implicit conversion defined in optixu_on_cudau you might be using). When updating vertices/indices, you need to update the number of vertices/indices as well. In this case, you need to set vertex/index buffer again with the current number of vertices/indices.

[Hurleyworks]

Excellent. That fixed the rendering errors. Thanks very much for the help!