vga-group / tauray Goto Github PK

It should be possible to use Tauray as a USD Hydra backend. This would be a path to allow running Tauray within Blender, which could be nice to have.

In practice, needs #27 first.

Hi, thanks a lot for the wonderful project. I would like to explore the real-time path tracing part on a VR. I have currently a HTC Vive Pro Eye. Could you give some instructions about the openxr part? I had a brief look over your paper and the user manual. Unfortunately could not find clear instructions.

Following syncronization related issues can be seen with: VK_LAYER_ENABLES=VK_VALIDATION_FEATURE_ENABLE_SYNCHRONIZATION_VALIDATION_EXT

tauray_validation.log

With RADV, everything looks perfectly mirror-like by default:

Specifying --sampler=uniform-random seems to work around this this.

When running test.glb on Intel(R) Arc(tm) A770 Graphics I see multiple validation errors of following type:

Validation Error: [ VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03710 ] Object 0: handle = 0x55f2895b06e0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x63ff8904 | vkCmdBuildAccelerationStructuresKHR:For each element of pInfos, its scratchData.deviceAddress member must be a multiple of VkPhysicalDeviceAccelerationStructurePropertiesKHR::minAccelerationStructureScratchOffsetAlignment. The Vulkan spec states: For each element of pInfos, its scratchData.deviceAddress member must be a multiple of VkPhysicalDeviceAccelerationStructurePropertiesKHR::minAccelerationStructureScratchOffsetAlignment (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03710)
(minAccelerationStructureScratchOffsetAlignment for this device is 64)

Great Work!
Can you kindly share the scene files used for comparisons between ddgi and DDISH-GI?

Best Regards

It would be very useful to make the core of Tauray operate more like a library, where it could be integrated as a part of other projects.

One of the potential issues with this is that many parts of Tauray may currently assume that the number of objects or materials in the scene does not change while the program is running. Tauray also has this kind of odd architecture where it avoids re-recording command buffers like plague. This most likely won't work well if the scene composition constantly changes.

One thing I would link with this is that I really want to get rid of the object-oriented, inheritance-based node design and replace that stuff with an entity-component style approach. I've done this once in a non-public Vulkan renderer, and it seemed to make the scene handling much simpler in the end.

• Move from scene class hierarchy to ECS
• Ensure everything works when scene composition changes during runtime
• Specify a public API

Supporting ANARI would be really cool, but I have no use case in mind currently. Low priority due to that.

Requires #27 first.