Hey,
I have been using the point Struct that is in the advanced samples but I now need to have vertex normals and UVs.
I was thinking to use separate buffers but I am concerned about using a float3 due to a lack of 16 byte allignment.
Will the TRBVH work with a float4 if I set a 16 byte stride?e
Thanks,
I’m looking at the same thing with RGB textures as well.
The docs specifically mention INPUT OUTPUT buffers when mentioning the 16 byte alignment, which is going to be something that is synced back and forth from the device to the host hopefully 10-30 times a second, and so must experience the fastest read and write possible.
However would we see a big loss during the first sync while we transfer all of these INPUT only buffers of points and textures? I tested with a 1 million triangle mesh and the first sync didn’t seem to take much longer overall.
It seems that if possible a 25% less data ( float3 vs float4 ) would be worth it for memory usage with the potential for longer times before fist pixel and during sync.
If you looked at the OptiX Advanced Samples, the OptiX Introduction ones are using an interleaved vertex attribute structure.
Link to presentation video and source code here:
[url]https://devtalk.nvidia.com/default/topic/998546/optix/optix-advanced-samples-on-github/[/url]
For memory reasons, I’m using float3 for the attributes, but I also have a version of my renderer with all float4 attributes. The performance difference with float4 was not worth the memory waste.
[url]https://github.com/nvpro-samples/optix_advanced_samples/blob/master/src/optixIntroduction/optixIntro_07/shaders/vertex_attributes.h[/url]
Means, yes, if the position x,y,z values are the first attribute in your data, the acceleration properties can also handle the necessary strides. See this thread: [url]https://devtalk.nvidia.com/default/topic/1035612/?comment=5261327[/url]
and this code
[url]optix_advanced_samples/Application.cpp at master · nvpro-samples/optix_advanced_samples · GitHub
For the RGB texture question, that’s easy, there are no three component texture formats on the device, only 1-, 2-, and 4-component textures.
See some elaborate code to convert input file formats to the necessary texture internal format here:
[url]https://github.com/nvpro-samples/optix_advanced_samples/blob/master/src/optixIntroduction/optixIntro_07/src/Texture.cpp#L327[/url]
Read the comments there, It’s currently always building 4-component textures, but 1- and 2-component encodings are prepared in the code.