Yes, you’ve got the right idea about accessing the data. Note you can still use optixGetCubicBSplineVertexData() for the current frame’s data (i.e. the data used to build your BVH), and only refer to your own vertex buffer for the previous frame’s data, if you want. The advantage of doing that is a memory savings, at the cost of having to access the data two different ways. By memory savings, I’m referring to whether you choose to delete your current frame’s vertex buffer after building the BVH, and then in that case you will need to use the OptiX vertex data function.
There is no function optixGetCubicBSpline Index Data or is it? Or is there a way to access that index buffer in current GAS? Cause if it is, then I would not need to keep it additionally in memory.
This is a good question. We don’t currently have such a function, so you’re right you’ll need to keep your index buffer around for any data that you want to access directly. I’m going to put this on our list of functions to consider adding to OptiX.
Here’s a dumb idea that might make sense in some scenarios, perhaps if you are rendering multiple frames in sequence with a single run of your render process. You could load the data for frames 1 & 2, and build the BVH for both frames. This would allow you to use optixGetCubicBSplineVertexData() for both frames to compute the flow vectors for frame 2. Then you can delete the data for frame 1, and load/build the data for frame 3 in order to render frame 3, reusing the existing data for frame 2. This probably isn’t a memory savings compared to storing your index buffer, but might make things simpler or allow you to amortize some costs. If you render frames in separate processes, then this probably isn’t a great idea.
–
David.