I recently implemented an environment map utilizing a half hemisphere mirrored about an X-Z plane. It seems that for random runs of OptiX, the texture sampler would produce QNAN values for azimuths slightly greater than 1. When changing the wrap mode to RT_WRAP_CLAMP_TO_EDGE and manually mirroring the texture with:
if ( v > 1.f ) v = 1.f - fmodf(v,1.f);
the NaN values disappear. I have spent about 4 days analyzing this and making sure my inputs are all proper. I believe the error lies inside how OptiX handles RT_WRAP_MIRROR wrapping. Has anyone else come across something like this?
The texture is definition is as such:
rtTextureSampler<float4, 3> spectral_background_texture;
You’re using a 3D texture for the hemispherical environment map?
Could you please provide the usual system details required for problem reports:
OS version, OS bitness, installed GPU(s), display driver version, OptiX version, CUDA version.
Texture dimension, size, and internal format?
Are you saying this is happening randomly for the same input or are you able to pin down the exact texture coordinates which produce this error?
To be sure this can be analyzed, it would be necessary to have a minimal reproducer in failing state, the smaller the better.
Please have a look at this thread [url]https://devtalk.nvidia.com/default/topic/803116/optix/error-with-rtpmodelupdate/[/url] which describes how to generate a reproducer OAC for the OptiX team without the need to provide the whole program.
Yes I am using a 3D texture for a hemisphere environment map. The dimensions are as follows: Zenith, Azimuth, Wavelength/Wave-number of float4. In other words the environment is a x,y coordinate with spectral depth of z. Each slice is essentially a 2D x,y texture of float4 however I am storing the multiple slices in the z direction.
The error would occur intermittently for any input given. So if I kept the input constant and then just opened and closed the program numerous times it would sometimes occur and sometimes not. When the error did occur it would happen immediately or not at all no matter how long the program ran. This would occur on azimuth values that were basically at the edge of the texture (a value slightly greater than 1; around 1.05) for any zenith or wavelength coordinate. So it would occur as you passed 180 degrees (hence the half hemisphere) but not as you crossed from 360 to 0. This would occur if you were staring at that location in the render or if you had an object reflecting to that location as well.
The most recent texture I used was of size 90,90, 8. So 8 groups of float4. The error occurred with basically any input size, but I would have to generate a few more test cases to demonstrate that.
If I can allocate some time this week to write up a small demonstration case I will. It might have to wait until next week though. When I do I will try and include example inputs as well.
Here are the configurations of the machines which I am developing on. However this bug/issue cropped up with earlier version of OptiX, CUDA, and display drivers.
System 1
OS: Windows 7 x64
GPUs: Quadro K4000 & GTX 680
Driver: 347.25
Optix: 3.7.0 beta 3
CUDA: 6.5
System 2
OS: Windows 7 x64
GPUs: K3000m
Driver: 347.25
Optix: 3.7.0 beta 3
CUDA: 6.5
System 3
OS: Windows 7 x64
GPUs: Quadro K4000
Driver: 347.25
Optix: 3.7.0 beta 3
CUDA: 6.5