CreateDistortionMesh problems

Jan 31, 2015 at 1:11 PM
Edited Jan 31, 2015 at 1:11 PM
Hi, great wrapper! I only have a problem with the CreateDistortionMesh function. My goal is to get to all the Vertex informatons , lets say as an array of DistortionVertex[].

The function gives only one DistortionVertex. Question: is that a bug or why only one?

Also the length of pIndexData (inside DistortionMesh) is only one
IndexCount on the other other hand states a plausible value of 24576

Here my code, in case i missed something:
OVR.FovPort[] eyeFov = new OVR.FovPort[]
OVR.DistortionMesh dm = new OVR.DistortionMesh();
OVR.DistortionVertex dv = new OVR.DistortionVertex();
hmd.CreateDistortionMesh(OVR.EyeType.Left,eyeFov[0],OVR.DistortionCaps.ovrDistortionCap_Chromatic, out dv, out dm);
Great thanks in advance!
Regards Tomi
Jan 31, 2015 at 2:35 PM
You're right, that's an oversight on my part.

I didn't notice that the returned structure was variable in length and needs to be handled as such.

I'll have a look at it and let you know as soon as I've corrected the problem!
Jan 31, 2015 at 5:19 PM
I have made a new release, containing a new method signature for the CreateDistortionMesh method, which returns the full array of distortion vertex information.

The new release has the same name as the previous one, but now has version number
Feb 1, 2015 at 5:04 PM
wow, that fix was too fast i can't event test it. :) but looking at the code it seems exactly what was needed. thanks a lot.

There is just one more issue: when you load the DDLOvr.dll and create the path for x86 and x64 i think c# is looking in the path you would get from Directory.GetCurrentDirectory() , right? (not sure to be honest) and because in my case this isn't the path where DDLOvr.dll is located the program can't find it. Basically i had to put an absolute path to get it running. I assume the path should be the one where OculusWrap.dll lies. (inside x86 etc.)

Maybe it should look inside
I am no expert here just got it from here:

again, thanks in advance
Feb 1, 2015 at 5:27 PM
When the Wrap.Initialize or Wrap.InitializeRenderingShim is called (Which ever of the two are called first), the DllOVR.dll is loaded from the x86 or x64 subdirectory of the current directory. Usually this is the directory in which the OculusWrap.dll is found, but another directory would work too.

If your directory structure looks differently, you can change the directory to where you have the x86 and x64 sub folders, prior to calling the Wrap.Initialize or Wrap.InitializeRenderingShim methods. After the Wrap.Initialize or Wrap.InitializeRenderingShim has been called, you can change your current directory back to what it was, prior to that call.

It would look something like this:
string previousDirectory = Directory.GetCurrentDirectory()
I will consider using the location of the executing assembly, on the next release, it's not a bad idea.
Feb 2, 2015 at 2:10 PM
Hey, sorry for mixing up the issues in that one thread, but I figured the indexdata is only half filled. The second half is only containing zeros.

When i replace
System.Buffer.BlockCopy(indexDataSigned, 0, indexData, 0, indexDataSigned.Length);
System.Buffer.BlockCopy(indexDataSigned, 0, indexData, 0, indexDataSigned.Length*2);
I works, does that make sense? signed vs unsigned? (I'm really only quessing)
Feb 2, 2015 at 2:47 PM
Ok and again back to path issue :)

I think
handle the conversion to an absolute path differently

When I use:
string filename = Path.Combine(Directory.GetCurrentDirectory(), subfolder, OVR.DllOvrDll);
to make an absolute Path, then everything works.
Btw. yes i do:
in my code before initialisation
Feb 2, 2015 at 3:30 PM
Wow that was embarrassing. I assumed that the last argument, in the call to BlockCopy, was the number of elements to copy and not the number of bytes to copy.

I guess I was blinded by the identical argument to Marshal.Copy, which takes the number of elements to marshal and not the number of bytes to marshal.

Had I looked through the result myself, instead of only testing the result in a unit test, I probably would have spotted the long set of zeroes in the list of results...

The documentation for LoadLibrary, in the Platform SDK, states:
The first directory searched is the directory containing the image file used to create the calling process.
This means that changing the directory, as I suggested as a workaround, won't work after all.
I'll use the path of the executing assembly instead, like you suggested.

I will make a new build to solve these issue, I'll let you know when it's uploaded.
Feb 3, 2015 at 6:29 PM
I have made a new release, containing the correction of the number of filled out distortion indices for the CreateDistortionMesh method, as well as now loading the DllOvr.dll from the x86 or x64 subdirectory to the folder containing OculusWrap.dll.

The new release has the same name as the previous one, but now has version number
Marked as answer by MortInfinite on 2/5/2015 at 5:08 AM
Feb 4, 2015 at 8:10 PM
Nice, works as advertised. Thanks a lot.