search

LuisaGroup / LuisaCompute

High-Performance Rendering Framework on Stream Architectures
BSD 3-Clause "New" or "Revised" License
704 stars 62 forks source link

Should TLAS accept primitives only? #140

Closed tyanyuy3125 closed 4 months ago

tyanyuy3125 commented 5 months ago

I understand that the AS of LuisaCompute is designed as a two-layer AS, for optix::TRAVERSABLE_GRAPH_FLAG_ALLOW_SINGLE_LEVEL_INSTANCING is set in cuda_shader_optix.cpp; and the emplace_back member function of Accel in accel.h accepts mesh, curve and procedural only. Although uint64_t mesh_handle argument is also defined in a reload function, passing an Accel or other object that is not inherited from Primitive is not feasible (at least with CUDA backend), for the following implementation in cuda_accel.cpp:

auto prim = reinterpret_cast<const CUDAPrimitive *>(m.primitive);

The inability to implement multi-layer AS is not the only problem this implementation poses. In OptiX, some methods accept primitive's OptixTraversableHandle to generate new OptixTraversableHandle. For example, optix::api().convertPointerToTraversableHandle used to achieve motion blur. According to the current design, developers will have to inherit CUDAPrimitive to encapsulate this new OptixTraversableHandle, but this will bring design overhead, for this OptixTraversableHandle is just an instance, it does not have a BVH Buffer, and does not need (and cannot) to implement the update function. Is this good design?

Furthermore, is it necessary for LC to support a multi-layer AS?

tyanyuy3125 commented 4 months ago

In order to optimize performance, the multi-level AS will not be implemented in the short term. Motion blur on OptiX will be simply managed by Accel with an array of OptixTraversableHandle(s).