osvr / distortionizer Goto Github PK

in AngleToConfig.md file :

-verify_angles xx xy yx yy max_degrees tests each mesh point to ensure that the change between the vectors point to each of its neighbors in angle space, when transformed into screen space, does not differ by more than max_degrees. The transformation is specified: The vector (xx, xy) points in screen space in the direction of +longitude (left). The vector (yx, yy) points in screen space in the direction of +latitude (up).

"direction of +longitude (left)" may be is "direction of +longitude (right)" ?

Says 117 commits since latest release binary. Time for an update smart folks!

Currently in vizard/ShaderTest.* in GLSL versions:

• https://github.com/OSVR/distortionizer/blob/master/vizard/ShaderTest.frag
• https://github.com/OSVR/distortionizer/blob/master/vizard/ShaderTest.vert

and the Unity ShaderLab/Cg/HLSL version:

• https://github.com/OSVR/OSVR-Unity/blob/master/OSVR-Unity/Assets/OSVRUnity/Shaders/OsvrDistortion.shader

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.

cc @russell-taylor @DuFF14

Compile the project, generate the application "distortionizer-calibration.exe".
using Keyboard controls to adjust the screen display,But how to judge the best results?

This Application work fine in my monitor(1366x768) which is in landscape mode.
But My HMD devices is 1440x2560 which is in portrait mode, I need to rotate the View .
I want to find some api to do this under Class QMainWindow & QWidget ,But I don't find ,give me a hand,thanks.

I think the only one using it was Russ - I've got a good CMake-based build system, tested with at least VS. (Haven't tried Qt creator) If this fits all our build system needs, we should get rid of https://github.com/sensics/distortionizer/blob/master/calibration/calibration.pro

For one display, these values seem to be inverted around 0.5. The original had 0.6 for left eye and 0.4 for right, but the inverse worked. Not sure if this was a sign convention error, an eye-order error; not certain if it is only for that display or for all of them.

• Needs copyright notice/headers in files - could look at OSVR-Core for samples.
  could look at OSVR-Core for samples.
• Needs copyright notice + license info in readme

The shaders directory seems to be missing the quadratic_tri_color_vert.glsl and quadratic_tri_color_frag.glsl files.

Looks like fprintf is being used now. Since we already depend on Qt, we should check in there, I bet they have a json facility. If not, jsoncpp will do the trick just as it does for the OSVR Core.

We need a .glsl file for the vertex and fragment shader for the Undistort_Shader class to read.

We need to finish the parameters for the shader.

We need to set the parameters and test all this.

We need to hook the shader into the calibration program, so that you can toggle to a view that renders using that shader with the current parameters.

We might want a simple sample application that renders a scene using the shader.

When I try with CMake, it can't find Qt5Widgets. I can fix this by adding:
list(APPEND CMAKE_PREFIX_PATH "C:\Qt\5.4\msvc2013_64_opengl")
to the CMakeLists.txt file. This seems a bit inelegant, since it presumably needs to change on every machine, but I guess somewhere there needs to be a list of potential places to look and maybe this is as good as any.

Once over that hurdle, I have to tell it where to look for glew.h and glew32; it doesn't look in C:/usr/local by default. Again, this depends on where the user happens to put it and is a bit unique so that may not be a huge issue.

Should I go ahead and add specific cases for my setup (which will work for me and provide an example for others?)

https://github.com/sensics/distortionizer/blob/master/shaders/undistort_shader.cpp#L94

I will refrain from passing judgement, recognizing that people are familiar with different things 😄 , just acknowledge that the code there can be made better or at least more idiomatic.

I can do it pretty quickly, if I get a chance (it's a handful of lines tops), though I'm not sure when that gets invoked so I'm not sure I'd be able to confidently say I didn't break it.

cc @russell-taylor

• Needs info in README file (and github repo description) about what it actually is/does)
• Might want to split the compilation docs into a separate file? (That or the operation docs - since we're building HTML files of the README right now to include in the distributed builds, which doesn't really make sense to have build instructions in)