You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
which is more widely used but seems to be basically derived from the GLSL ones.
Questions:
Most pressing: Input: what is the best format to provide the parameters to the shaders, from an OSVR-Core point of view? A struct with matching fields as the uniforms?
Are these suitable to pull into core in some way or another? (I'm specifically thinking compatibility between OpenGL versions and profiles)
I don't fully grasp the different centers of projection being used and where they come from - how they are logically derived from the results of the Distortionizer run.
Performance: Looks like there's an unnecessary sqrt call (because the result is immediately squared) in the distort function: see glsl version, unity version - no idea if the shader compilers are smart enough to optimize that out or if it can't be removed for some other reason. That just jumped out at me on a skim - not enough shader experience to tell if the rest of htem is sufficiently optimal.
When I handed off the distortionizer, it had buttons that the user could use to adjust the centers of projection for the eyes, and I think it only allowed mirror symmetric solutions (left eye X = -right eye X, left eye Y = right eye Y).
OpenCV radial distortion parameters look consistent with the one the distortionizer originally used, which would match the k1 (quadratic) term in OpenCV. There are also 4th and 6th power coefficients available in the numerator and denominator. I was able to get pretty good results with just the quadratic term on the DK2 (with a different parameter for each color).
Good to reduce sqrt() in the shader. Yuval was thinking that should be possible to remove.
Currently in
vizard/ShaderTest.*
in GLSL versions:and the Unity ShaderLab/Cg/HLSL version:
which is more widely used but seems to be basically derived from the GLSL ones.
Questions:
sqrt
call (because the result is immediately squared) in thedistort
function: see glsl version, unity version - no idea if the shader compilers are smart enough to optimize that out or if it can't be removed for some other reason. That just jumped out at me on a skim - not enough shader experience to tell if the rest of htem is sufficiently optimal.cc @russell-taylor @DuFF14
The text was updated successfully, but these errors were encountered: