Will this build for Hololens on 0.14393?

[utekai]

Having difficulty building and deploying successfully to Hololens on 0.14393.

Are there specific build commands needed? Or what is the secret sauce to get it to work?

Using ...

1. MakeWindows.bat x86 Debug 2017 DirectX/OpenGL (tried both, but think DirectX is correct)
2. MakeSharpReality.bat x86 Debug 2017

Then open in Visual Studio and modify ...

1. UrhoSharp.SharpReality c++ to use 0.14393
2. UrhoSharp.SharpReality c# to use 0.14393 and modify json file to correct the framework
3. Playgrounds.SharpReality to use 0.14393 and modify json file
4. Remove and add back into Playgrounds.SharpReality project the mono-holourho.dll generated when compiling the native c++ UrhoSharp.SharpReality project (as the default path is for the x64 version which is not generated)

All compiles and deploys, then upon starting up in Hololens an exception is thrown.

System.DllNotFoundException: 'Unable to load DLL 'mono-holourho': The specified module could not be found. (Exception from HRESULT: 0x8007007E)'

This in particular happens on the call in the UrhoAppView.cs file in UrhoSharp.SharpReality c# project ...

InitializeSpace();

Declared as [DllImport(Consts.NativeImport, CallingConvention = CallingConvention.Cdecl)] static extern void InitializeSpace();

And the Consts.NativeImport is a simple If on UWP_HOLO which specifies the mono-holourho dll.

[Noemata]

I had this same issue. I should have written down the steps I went through to resolve this. I vaguely remember adjusting the code that loads the DLL. Are you building from the latest branch? Perhaps we can help each other on this. I'm not having any luck with the current branch.

[utekai]

Yes, using latest branch. But it's been setup for x64 and a Win10 UWP framework not available yet on Hololens. the 15083 branch, and hololens is still on 14393.

Suspect or broken areas:

1. material.SetTechnique (memory access violation, but not sure if it's this call, or this just exposes another error, as memory access voilations start appearing on any SharpReality version higher than 1.5.22)
2. Sound playback via media player ...
3. Spatial Mapping
4. General instability, likely related to #1.

As for loading the DLL, in particular mono-holourho.dll, this is problematic. It seems to be a dll needed by this dll that is causing the issue though.

Currently trying to simplify the structure to figure it out.

Not sure what you mean by 'code that loads the dll'.

For instance, the call to 'InitializeSpace' is just declared as an extern and then called directly. From UrhoAppView.cs ... not sure what to adjust ...

[DllImport(Consts.NativeImport, CallingConvention = CallingConvention.Cdecl)] static extern void InitializeSpace();

Then in the c++ sharpreality project ...

extern "C" { __declspec(dllexport) void InitializeSpace() { SDL_SetMainReady(); auto obj = CoreWindow::GetForCurrentThread()->CustomProperties->Lookup("HolographicSpace"); holographicSpace = safe_cast<HolographicSpace^>(obj); } .... }

[utekai]

Alternatively, have also been just loading the previous SharpReality releases from nuget trying to narrow down particular changes that could be the cause, but not getting anywhere.

1.5.22 is stable, but not releasable. Anything above 1.5.22 starts throwing Memory Access Violations, in particular on the material.SetTechnique calls.

More recent versions work better when set to release mode. But still tend to get random MAVs.

[davejmurphy]

You need to compile the UrhoSharp.SharpReality as a 32 bit Release build, and add the mono-holourho.dll into the Playgrounds.SharpReality project as an existing item. Both Release and Debug versions of the Playgrounds.SharpReality project should use the Release version of mono-holourho.dll. As far as I can tell the HoloLens doesn't have the runtime to support the Debug version of mono-holourho.dll (can't find a source to confirm this right now though). Also, if you copy the mono-holourho.pdb file into the Playgrounds.SharpReality project you'll still hit breakpoints in the cpp code.

For your spatial mapping problem you can remove the bounds parameter from the call to CreateModelFromVertexData in StereoApplication for a temporary fix, it will use a default argument. I opened an issue for that here: #314.

For the SetTechnique issue make sure it's called on the main thread.

Hope this helps.

[utekai]

Thanks for these clues ... it's working now ... here's the algorithm followed:

1. using a GIT console window download the Urho project ... with this command ....

git clone https://github.com/xamarin/urho.git --recursive

2. using the Developer command prompt for VS2017, on a system with CMake installed ...

MakeSharpReality.bat x86 Release 2017

3. Open the UrhoSolution ... with visual studio 2017 ... and modify one project

Close the project for Playgrounds.SharpReality and view code to open the csproj file. Modify the link for mono-holourho.dll to use the Win32 folder instead of x64 folder

4. Modify the platform to 0.14399 on three projects in project settings

Playgrounds.SharpReality Urho.SharpReality UrhoSharp.SharpReality

5. Modify the project.json to use the .14393 framework on these two projects Urho.SharpReality Playgrounds.SharpReality

6. Set Playgrounds.SharpReality as the Startup project

7. Modify the VS setting on toolbar from AnyCPU to x86 for release and add a remote machine (to hololens)

8. Run without debugging

[davejmurphy]

Glad that's working.

Are you able to run the Playgrounds.SharpReality while VS toolbar is set to Debug, and then launch it with the debugger?

[utekai]

Regarding spatial mapping, the SpatialMappingTests file in Playgrounds.SharpReality overrides the call to adjust it as you mention, so it works in that file and shows a workaround for the existing bug.

[utekai]

@davejmurphy

Yes, Playgrounds.SharpReality will run in Debug both with and without debugger, but haven't tried to debug into the C++ code yet.

What I've noticed on other Hololens projects when setting to Debug is that at times the 'await' is ignored and near parallel execution occurs. At least for some calls, but haven't narrowed it down.

Also Urho.SharpReality is compiled against Any CPU setting and works.

[Noemata]

Clearly some folks have a different set of sources. To get this to build I had to muck around more as shown below. I have no clue how others were able to bypass this:

Modifications: D:\Build\urho\Urho3D\Source\Source\Urho3D\IO\Log.cpp Line 84:

if !defined(ANDROID) && !defined(IOS) && !defined(TVOS)) && !defined(UWP)

to

if !defined(ANDROID) && !defined(IOS) && !defined(TVOS) && !defined(UWP)

D:\Build\urho\Urho3D\Source\Source\Urho3D\IO\FileSystem.cpp Line 710: programDir_ = AddTrailingSlash(SDL_UWPGetResourceDir()); to String programDir = AddTrailingSlash(SDL_UWP_GetResourceDir());

D:\Build\urho\Urho3D\Source\Source\Urho3D\Core\ProcessUtils.cpp Line 391: //int flags = fcntl(STDIN_FILENO, F_GETFL); //fcntl(STDIN_FILENO, F_SETFL, flags | O_NONBLOCK); //for (;;) //{ // int ch = fgetc(stdin); // if (ch >= 0 && ch != '\n') // ret += (char)ch; // else // break; //}