DLL location; e.g. Virtual Stereo Camera Setup wiki?

[m-7761]

How does PSVRTracker locate its DLL dependencies? The following wiki explains to work out of dist/Win64:

https://github.com/HipsterSloth/PSVRTracker/wiki/Virtual-Stereo-Camera-Setup

None of the projects/subprojects are installing their DLL files to this bin folder and the pre-built binaries don't come with any of the prerequisite DLL files. What is recommended?

SDL2 installs to C:\Program Files\SDL2\bin for example. It also has DLL files in the linker path, but those are not found at run-time.

Is anyone home? I did receive some replies a while back (months) but have the impression I'm not being replied to now on purpose. If so I apologize if I said the wrong words. Or if I'm not cool enough. I want to help with PSVR support nevertheless, and I think it would be good to make this project accessible if possible. Thanks.

[HipsterSloth]

Apologies for not being responsive. Definitely not on purpose. Very sorry if I made you feel badly for that.

All my free time has been dedicated recently to trying to get PSMoveSteamVRBridge in a better place. Between that and work there hasn't been anytime left for this project. But I do really want to get back to this.

The intention for the build process and installation is that PSVR tracker builds all of it's own DLL dependencies and then installs them in the "dist" folder (or static links against them). So the build process is as follows:

1. git.exe clone --progress --recursive -v "https://github.com/HipsterSloth/PSVRTracker.git" ""
2. Run \InitialSetup_X64.bat -- This will compile libusb, and SDL2 in the the \thirdparty folder -- This also runs cmake on CMakeLists.txt which will generate the PSVRTracker.sln file
3. Open \build\PSVRTracker.sln and build the solution -- You may have to do the initial build twice since the initial OpenCV build will occasionally trip over iteself
4. After the build completes, build the "INSTALL" project in the solution. This just copies all the needed DLLs and build executable into the dist folder. If everything built correctly you should see the following output from the "INSTALL project":

2>------ Build started: Project: INSTALL, Configuration: Debug x64 ------
2>  -- Install configuration: "Debug"
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/lib/PSVRService.lib
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/PSVRService.dll
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/include/ClientConstants.h
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/include/ClientColor_CAPI.h
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/include/ClientGeometry_CAPI.h
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/include/PSVRClient_CAPI.h
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/include/PSVRClient_export.h
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/calibration
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/calibration/pattern-a0.pdf
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/calibration/pattern-a1.pdf
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/calibration/pattern-a2.pdf
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/calibration/pattern-a3.pdf
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/calibration/pattern-a4.pdf
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/calibration/pattern-letter.pdf
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/firmware
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/firmware/ps4camera_firmware.bin
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/supported_trackers
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/supported_trackers/ELP_960P_StereoCamera.json
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/supported_trackers/Logitech_C920_MonoCamera.json
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/supported_trackers/Sony_PS3EYE_MonoCamera.json
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/resources/supported_trackers/Sony_PS4_StereoCamera.json
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/PSVRConfigTool.exe
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/assets
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/assets/fonts
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/assets/fonts/OpenSans-Regular.ttf
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/assets/textures
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/assets/textures/MorpheusDiffuse.jpg
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/assets/textures/PS3EyeDiffuse.jpg
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/assets/textures/PSDS4Diffuse.jpg
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/assets/textures/PSMoveDiffuse.jpg
2>  -- Up-to-date: F:/PSVRTracker/dist/Win64/Debug/bin
2>  -- Up-to-date: F:/PSVRTracker/dist/Win64/Debug/bin/assets
2>  -- Up-to-date: F:/PSVRTracker/dist/Win64/Debug/bin/assets/fonts
2>  -- Up-to-date: F:/PSVRTracker/dist/Win64/Debug/bin/assets/textures
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/source_assets
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/source_assets/DS4
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/source_assets/Morpheus
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/test_camera.exe
2>  -- Installing: F:/PSVRTracker/dist/Win64/Debug/bin/unit_test_suite.exe
2>  -- Installing: F:/PSVRTracker/dist/Win64/Release/bin/unit_test_suite.exe

[m-7761]

I've completed these steps (with some problems: https://github.com/HipsterSloth/PSVRTracker/issues/13) however, I only have PSVRService.dll in the dist bin folder.

Is there a post-build step that copies DLL's? I know how this can be a PITA. I don't do Git checkouts often, but am responsible for some CMake scripts myself. Which DLLs should be copied? Can you say what part of the CMake script does the copy if so?

I think maybe the problem is spaces in my path. That's a common problem. I recommend maintainers to always set up their projects with spaces in paths, so they can discover these CMake mistakes for themself. But it's just a hunch. Still I haven't seen any error output.

[m-7761]

P.S. Sorry, just want to repeat that the Release files here (https://github.com/HipsterSloth/PSVRTracker/releases) don't have DLL files. I feel like probably your system has the necessary DLL files already installed. Like by PSMoveService?

When I woke up this morning I thought maybe somehow the project used static libraries (no DLL files) but I can't see any way to do that really. There is a PSVRService_static project. I think it is built by ALL_BUILD but am uncertain. Anyway, the other projects don't appear to have static variations.

This is kind of the reply I expected to write. But I want to take your words (builds all of it's own DLL dependencies and then installs them in the "dist" folder) at face value too. I'm covering both bases while I'm here. I know I can forge ahead by hunting down the various DLL files and copy them, but that is not a good practice or long term solution.

[HipsterSloth]

Ah sorry. It's been a while since I looked at the details of how this project was configured. The only DLL that get's copied in PSVRService.dll. That copy is setup here in the cmake scripts:

https://github.com/HipsterSloth/PSVRTracker/blob/master/src/psvrservice/CMakeLists.txt#L255-L266

I am statically linking against SDL2, LIBUSB, and HIDAPI (just including hid.c in that case).

I set SDL2 to be statically compiled in InitialSeup.bat here: https://github.com/HipsterSloth/PSVRTracker/blob/master/InitialSetup_X64.bat#L46 See "-DSDL_STATIC=ON" build flag

I'm really confused by all of the errors you are seeing in issue #13. I've done a fresh sync and built successfully twice. The missing "ServerLog.h" is particularly weird because in the latest fresh sync there is no reference to that filename in any of the cmake scripts.

Have you done a fresh sync of the repo? Do you have visual studio 2017 installed or just visual studio 2015? I ask because I recall (maybe incorrectly) having issues previously with the 2017 install causing issues with 2015's ability to compile when I both installed at the same time.

[m-7761]

The "ServerLog.h" reference is in PSVRTracker\src\tests\CMakeLists.txt.

I do have 2017 installed. I don't see anything that suggests it's a problem.

Since I had to build thirdparty\SDL2 manually I'm not sure it's identical, however I think I have a lot more DLL failures than it (likely) but won't know until I cross that bridge. I used the flags from https://github.com/HipsterSloth/PSVRTracker/wiki/Building-from-source that include -DSDL_STATIC=ON. However, the generated project has both a static target and a regular target. It builds both.

PSVRConfigTool has the following in its linker inputs:

..\..\..\thirdparty\SDL2\build\Release\SDL2main.lib
..\..\..\thirdparty\SDL2\build\Release\SDL2.lib

My SDL folder has SDL2-static.lib in addition to SDL2.lib. Do you think the CMake scripts should have changed that to SDL2-static.lib? I think possibly I ran GenerateProjectFiles_X64.bat before noticing InitialSetup_X64.bat. It's possible it succeeded in initializing (configuring) the cache if so.

I can be a real klutz. At first I started working with the source-code in the release section, before realizing I should do a recursive clone instead. I wasn't planning on contributing code, so I didn't think to fuss with Git, because I wasn't thinking in terms of external projects...

Then I think maybe I didn't read the instructions carefully enough, and because the wiki has the Generate script highlighted, but the InitialSetup script is written in plain text, I glossed over it at first.

I can't remember the sequence of events, and I think I did consider it, but assumed that InitialSetup will clean the slate (which I actually think it does) but now I don't know, since I don't have a better explanation. We will figure it out.

I'm hoping I can go in with the 2 camera approach, since I have that hardware on hand. I understand that is a bit up in the air. I hope that I can get tracking working reasonably well, but if I end up empty handed then it will just be a chance to do more low-level work with VR. Part of the fun of using the PSVR is I think that you feel like you're really experiencing VR hacking as opposed to just having a convenient out-of-the-box experience. People in the future won't get to have that kind of intimate experience. So I think it's interesting, and insightful, and unique.

What I'm most concerned about is whether or not it will be user-friendly for end-users. I think if they have to mess with a clumsy/trying calibration process it will be impractical, and that's what I'm most concerned about. For not using tracking I disabled the calibration code from the PSVRToolbox code. I couldn't see how it could be correct after giving it some thought, but it was easy to see how it could be very bad, and the wait for the calibration phase to complete is obviously inconvenient. It might have been ill-advised. I don't know if there is an offline calibration approach that can do more good than harm. I hope that camera calibration is not more involved or hard to pull off.

[m-7761]

I think the flaw is InitialSetup_X64.bat doesn't run GenerateProjectFiles_X64.bat if builds fail. That keeps it from configuring CMake's cache.

I think it's pretty optimistic to assume builds will not fail. The BAT script should run GenerateProjectFiles_X64.bat failure or no I think. But to be honest, I can't tell if InitialSetup_X64.bat configures CMake to use static SDL or not. Nothing in GenerateProjectFiles_X64 sets the SDL2_INCLUDE_DIR to use the static library. I don't see anything obvious in the internal CMake scripts either.

Off-topic: psvrconfigtool/CMakeLists.txt has some fishy OpenVR lines:

    install(DIRECTORY ${OPENVR_BINARIES_DIR}/ 
            CONFIGURATIONS Release
            DESTINATION ${PSVR_RELEASE_INSTALL_PATH}/bin
            FILES_MATCHING PATTERN "*.dll" PATTERN "*.pdb") 

I think this copies from OpenVR (SteamVR?) to the tool's home folder. I feel like I've seen no mention of OPENVR_BINARIES_DIR elsewhere.

[m-7761]

More info:

To get PSVRConfigTool to work with static libraries is not so easy. It seems to need to define PSVRService_STATIC that its CMakeLists.txt file does not do for it. Then it can link against PSVRService_static but that only gets it so far, since it needs all of its static-dependencies too.

It seems like its CMake definition is incomplete. I don't see how this works any way except to hand copy the DLL files. If not, this needs attention.

[HipsterSloth]

The "ServerLog.h" reference is in PSVRTracker\src\tests\CMakeLists.txt.

Ah! Ok that is definitely wrong. That should point to "src\psvrservice\Utils\Logger.h". I did rename that file at one point. That said it's bizarre to me why cmake would be failing for you (which would be expected for a missing file) but working for me. I tried updating my version of cmake to the latest version, but that didn't repro the failure you are seeing.

I do have 2017 installed. I don't see anything that suggests it's a problem.

I've been building with 2015. I don't know if there are other project file issues with 2017 because I haven't been building using that newer version. The fact that the InitialSetup batch script works for me on a fresh sync and doesn't for you suggest I should at least eliminate that as a possibility. I'm going to upgrade to 2017 and see if that repros the build issues you are seeing.

Since I had to build thirdparty\SDL2 manually I'm not sure it's identical...

You can keep going down the manual compilation steps if you want to get something working, but at the end of the day the InitialSetup batch script is intended to take care of everything. I'm going to focus on trying to get that working with 2017

I'm hoping I can go in with the 2 camera approach, since I have that hardware on hand.

There's a small bit of work needed to get the multi-PS3EyeCamera case working again. Originally I was using two ps3 eye camera's side-by-side as fake stereo camera (poor man's PS4 camera). Then I got proper stereo camera support hooked up (ELP 960P StereoCamera and PS4 Camera). Then I worked on getting multiple mono cameras supported. However part of getting multiple independent cameras working requires a calibration step where you determine where the cameras are relative to each other. The way I did this in PSMoveService is to have the user place a PSMoveController in 5 spots on a standard calibration mat. This calibration tool has been ported over but still has bugs (I think it was computing the wrong camera position and orientation for each camera).

See https://github.com/HipsterSloth/PSVRTracker/blob/master/src/psvrconfigtool/AppStage_ComputeTrackerPoses.cpp

What I'm most concerned about is whether or not it will be user-friendly for end-users. I think if they have to mess with a clumsy/trying calibration process it will be impractical, and that's what I'm most concerned about.

There will likely always be some sort of calibration step for the cameras if you are using more than one camera. It's possible that given enough samples of the PSVR headset's LEDS + IMU derived orientation you can figure out where the cameras are relative to each other (since the PSVR headset is a rigid body). However my bet is this approach will always result in a worse alignment then just going the calibration mat route with a static controller.

There is also the issue of color filter calibration which is a function of LED brightness variation and room lighting. This could be more automatic than it is now, but even PSVR has a user LED calibration tool.

I don't know if there is an offline calibration approach that can do more good than harm. I hope that camera calibration is not more involved or hard to pull off.

If I recall correctly I think the PSVR headset uses the Bosch BMI-055 IMU, which I think is the same as the DualShock 4 controller. For that IMU you don't need to calibration the accelerometer or gyro gains (i.e. the constants you use to convert the raw sensor bytes into g/s and deg/s respectively). You can just use the appropriate gain based on the sensitivity setting.

See https://github.com/HipsterSloth/PSVRTracker/blob/master/src/psvrservice/MorpheusHMD/MorpheusHMD.h#L27-L48

That said, I think gyro drift calibration (how fase the gyro readings drift away from 0 when the headset is sitting still) is still value that varies from headset to headset and is not calibrated. To my knowledge there is no calibration HID report you can fetch with this info like there was with the PSMove controller. Though, there may be. In the mean time calibrating gyro drift is a one time calibration thing that can be computed and saved if need be.

I think the flaw is InitialSetup_X64.bat doesn't run GenerateProjectFiles_X64.bat if builds fail. That keeps it from configuring CMake's cache.

This is by design. There is no point in generating the PSVRTracker solution if the dependent libraries don't build.

I can't tell if InitialSetup_X64.bat configures CMake to use static SDL or not

I set SDL2 to be statically compiled in InitialSeup.bat here: https://github.com/HipsterSloth/PSVRTracker/blob/master/InitialSetup_X64.bat#L46 See "-DSDL_STATIC=ON" build flag

This cmake helper script finds the path to the static lib here and sets the SDL2_LIBRARY variable: https://github.com/HipsterSloth/PSVRTracker/blob/master/cmake/FindSDL2.cmake#L86-L92

Another cmake helper script combied SDL2_LIBRARY and other platform libs into SDL_GL_LIBS: https://github.com/HipsterSloth/PSVRTracker/blob/master/cmake/ThirdParty.cmake#L149-L157

The config tool then uses SDL_GL_LIBS variable here: https://github.com/HipsterSloth/PSVRTracker/blob/master/src/psvrconfigtool/CMakeLists.txt#L20-L22

Off-topic: psvrconfigtool/CMakeLists.txt has some fishy OpenVR lines:

Whoops! That is a copy and paste typo from another project. Good catch!

[m-7761]

Just for the record, I'm building with 2015. I've several versions installed. I usually prefer 2010. They all have pros and cons and different software is tailored to different versions. Since yours is expressly 2015 it's no-brainer to use that. There can be subtle interplay because I'm pretty sure they share system headers.

[m-7761]

I'm going to upgrade to 2017 and see if that repros the build issues you are seeing.

Just to repeat myself, I actually don't prefer 2017. I only use it for some C# projects. I'm using 2015 with this project, but simply having both installed can cause issues I think, but I don't see anything that looks that way here. I don't see a need to change..

This is by design. There is no point in generating the PSVRTracker solution if the dependent libraries don't build.

Sure there is. They don't depend on one another at all. If you have a project you can use its output to help figure out what parts are not working. I can tell you from experience it's not fun. You shouldn't have to have all of the external dependencies working before you can open a main project into Visual Studio for example. It's clear from output that errors happened. I can't remember details, but I know I've had CMake scripts that configure external dependencies in the same CMake "cache" inheriting variables. (I can't recall if they appear in generated Visual Studio projects if so or not though.)

This cmake helper script finds the path to the static lib here and sets the SDL2_LIBRARY variable: https://github.com/HipsterSloth/PSVRTracker/blob/master/cmake/FindSDL2.cmake#L86-L92

I think maybe you are relying on it to default to the static library. I think it defaults to the DLL. But it might not if you change the order to be "NAMES SDL2-static SDL2". That may solve the problem here.

Also, I don't think I mentioned that PSVRConfigTool isn't finding PSVRService.dll either. But I think that was it. Just two DLLs. (Not 20. Thankfully.)

I plan to look at the cameras. I think people discount what can be accomplished in software. I've been able to work wonders with the PSVR, without tracking, so far. Mainly just by tweaking the way the data is interpreted. It's analogous to programming motion in games. Maybe there's no hope, but you don't know until you try. As long as it's stable and not jittery a solution is a solution is a solution :)

[m-7761]

P.S. Off-topic: I prefer the twin (or even single) PS3Eye approach. I think there are many ways, but as long as these cameras are available, I think they offer the best purchase to end-users. The PS4 camera is only for people who buy a bundle. I'm not in that category. I don't even own a PS4. And may never.

I think today I'm going to take some time to look at Trinus PSVR's code that was given to me. I want to compare it to my own PSVR code. They asked me to implement my tracker-free logic for Trinus. I turned them down initially (since it's quite simple to implement) but took them back up on their offer when I realized their code is not open-source. I wanted to look at their code. So I promised I would do this for them some months ago. Right now I'm trying to catch up on things I set aside when some work I did last went 1.5 months over the time I planned for it.

I happened to stumble across a Reddit announcement for Trinus PSVR adding support for this (https://www.nolovr.com/hardwareDevice) product, that looks interesting to me. It's another way to do tracking with PSVR it would seem. I like that it has a straightforward (Windows) SDK. I don't think any of the big company VR products offer anything like that. As near as I can tell they all require Steam to be installed. Which is something I've avoided. I might (reluctantly) install it to mess with Trinus PSVR as some stage.

[HipsterSloth]

If you have a project you can use its output to help figure out what parts are not working.

I mean, that's certainly one place to debug the external lib compile failure. I'd personally rather see the failure reported immediately in the batch script. That's why I have all the early out failure goto. It pauses the batch script so that you can look at the last failure. If I blast through the failures I'm left wondering if the failure in the project is because there some broken code in the dependent library or there is a bug in the batch script. I'm updating the scripts to try it your way, but frankly I have mixed feelings about the change.

Just to repeat myself, I actually don't prefer 2017. I only use it for some C# projects.

Ah gotcha. I went ahead and added support for 2015 or 2017 solution generation anyway. I'm going to be moving PSMoveService to 2017 development as my preferred IDE soon and this seemed like a good testbed. The build batch files are in scripts\vc2015 and scripts\vc2017.

I think maybe you are relying on it to default to the static library. I think it defaults to the DLL. But it might not if you change the order to be "NAMES SDL2-static SDL2". That may solve the problem here.

Hmm. Looking in thirdparty\SDL2\build\Release I only see "SDL2main.lib" "SDL2-static.lib". I did notice that I was missing SDL_SHARED=OFF in the args passed to cmake in the initial setup batch. I'm wondering if you ended up having SDL dlls compiled in addition to the static libs on your machine and then "NAMES SDL2-static SDL2" order issue you mentioned came into play. I don't know why DLLs are building for you and not for me, but I hope that SDL_SHARED=OFF flag is the thing needed to fix it.

Also, I don't think I mentioned that PSVRConfigTool isn't finding PSVRService.dll either. But I think that was it. Just two DLLs. (Not 20. Thankfully.)

Is this while debugging in visual studio or when running PSVRConfigTool.exe in the dist\Win64\Debug\bin folder? The INSTALL project in the solution should copy PSVRService.dll into dist\Win64\Debug\bin. This is what my bin folder looks like after running the INSTALL project:

I'm adding the following line to the cmake script that should fix the debugging working directory issue: set_property(TARGET PSVRConfigTool PROPERTY VS_DEBUGGER_WORKING_DIRECTORY "${PSVR_DEBUG_INSTALL_PATH}/bin")

I just checked all of this in, plus some in progress work for the mat calibration I still had locally. While I know it's a hassle (sorry about the opencv rebuilding), I'd love to see if the 2015 initial setup script works for for you or not now.

[HipsterSloth]

I happened to stumble across a Reddit announcement for Trinus PSVR adding support for this (https://www.nolovr.com/hardwareDevice) product, that looks interesting to me. It's another way to do tracking with PSVR it would seem. I like that it has a straightforward (Windows) SDK.

I've actually tested the Nolo on the GearVR and OculusGo. It's interesting. When it works well it offers tracking similar in quality to PSVRs on the PS4 (as far as stability, range and "camera" fov). It is another $150 you have to spend, but it is nice having a someting VR hardware that just works. I'm personally not much of a fan of the controllers (I find them a bit small and I don't like trackpads) but they do get the job done.

[m-7761]

If I blast through the failures I'm left wondering if the failure in the project is because there some broken code in the dependent library or there is a bug in the batch script. I'm updating the scripts to try it your way, but frankly I have mixed feelings about the change.

I would refactor it to store the build results in variables, and print those out at the bottom of the script. Best of both worlds.

I'm wondering if you ended up having SDL dlls compiled in addition to the static libs on your machine and then "NAMES SDL2-static SDL2" order issue you mentioned came into play. I don't know why DLLs are building for you and not for me, but I hope that SDL_SHARED=OFF flag is the thing needed to fix it.

Yes, precisely. The script shouldn't depend on the DLL import library not being built. Users might build it themselves. In my case it looked as if SDL could not build (probably) because Libusb is blocking it. Because of the BAT file's setup. So I build it myself with ALL_BUILD. That produced the import library.

Is this while debugging in visual studio or when running PSVRConfigTool.exe in the dist\Win64\Debug\bin folder?

It's when using the build/src output. Excuse me, I was thinking yesterday that the working-folder would source the EXE too. I know better, just a brain glitch. I think changing the working directory should be good. I should've done that. I just copied everything for my tests yesterday. I will switch over now. (Post-build steps might still be good for keeping the various executables in-sync, so it's unnecessary to run the INSTALL target.)

Just as reminder the build/src folder has an assets folder. Something must be copying that from somewhere. It probably needs to be removed from the CMake scripts if so.

I'd love to see if the 2015 initial setup script works for for you or not now.

There's definitely a problem with LibUSB. I want to figure it out, but I've never seen anything like it, and can't reproduce it from inside Visual Studio. I will definitely try to remember to give a look. You might add a Delete deps folder? prompt to the script, just to be nice. It will serve as a reminder.

I'm definitely going to try Nolo out at some point. Already the PSVR is more than I can generally make time to drag out and wear. I appreciate your comment on it. It's encouraging that it won't just be a hassle purchase. It seems to serve a niche. I can't tell if it is camera based or uses some other kind of triangulation technology. Something I like about the PSVR is it has its own box that can take a big load off the PC, but it doesn't really use it for pass-through VR. I would love the PSVR maybe if the color was a little better. I wonder if we might ever be able to figure out its sound hardware? Or if that's worth bothering with. The headphones sound horrible. I don't know if that's the box or phones or what. Maybe the sound hardware is not worthwhile if that's what the PS4 sounds like!

(Edited: I meant to say the cameras drain the host PC. I think it's better if VR gear does not leach your CPU. It makes it so it's more likely to work with everyone's computers whether they buy one from a grocery store or some high-end electronics store.)

[m-7761]

Closing since all of this is obsolete by removing the CMake scripts.