macOS Support

[wgiesel]

Hello,
I wonder if it is possible to use this plugin on macOS Catalina. I tried with engine 4.23.1.
Plugin shows up in the plugin menu but does not work.

Thanks a lot.

[gaborpapp]

Have you tried adding Mac to the WhitelistPlatforms in
https://github.com/microdee/UE4-SpaceMouse/blob/master/Plugins/SpaceMouse/SpaceMouse.uplugin

[microdee]

@gaborpapp sorry I didn't notice your comment for long, unfortunately that wouldn't be enough, I'd need to compile and test it in a macOS environment

[microdee]

note to self, plugin compiles properly on my new Mac mini with an M1 processor in there. Unfortunately tho, running unreal requires the "root" user on MacOS Big Sur 11.2 as it wants to write a shader transfer file to a location which it cannot access by itself (/Users/m/Projects/personal/SpaceMouseUE4/Intermediate/Shaders/tmp/E0F7FECE56451F72B8CCB3B095A5CE39/03942E9F0924A69AB665CD58F430E0156'.) I will try moving my project outside of the user home folder. It didn't have permission to save that file inside the shared folder either.

It opens with the "root" user fine. Apparently MacOS doesn't recognise space mice out of the box like Windows does. For Mac the user might need to install 3DxWare, which would be a shame.

full crash report:

Fatal error: [File:/Users/build/Build/++UE4/Sync/Engine/Source/Runtime/Engine/Private/ShaderCompiler/ShaderCompiler.cpp] [Line: 1394] Could not create the shader compiler transfer file '/Users/m/Projects/personal/SpaceMouseUE4/Intermediate/Shaders/tmp/E0F7FECE56451F72B8CCB3B095A5CE39/03942E9F0924A69AB665CD58F430E0156'.

FGenericPlatformMisc::RaiseException(unsigned int) Address = 0x109640857 (filename not found) [in UE4Editor-Core.dylib]
FMacErrorOutputDevice::Serialize(char16_t const*, ELogVerbosity::Type, FName const&) Address = 0x1097d4813 (filename not found) [in UE4Editor-Core.dylib]
FOutputDevice::LogfImpl(char16_t const*, ...) Address = 0x1098e27c9 (filename not found) [in UE4Editor-Core.dylib]
auto FShaderCompileThreadRunnable::WriteNewTasks()::$_116::operator()<FLogCategoryLogShaderCompilers, char16_t [57], char16_t const*>(FLogCategoryLogShaderCompilers const&, char16_t const (&) [57], char16_t const* const&) const Address = 0x10ea46836 (filename not found) [in UE4Editor-Engine.dylib]
FShaderCompileThreadRunnable::WriteNewTasks() Address = 0x10ea461fd (filename not found) [in UE4Editor-Engine.dylib]
FShaderCompileThreadRunnable::CompilingLoop() Address = 0x10ea4a045 (filename not found) [in UE4Editor-Engine.dylib]
FShaderCompileThreadRunnableBase::Run() Address = 0x10ea44d59 (filename not found) [in UE4Editor-Engine.dylib]
FRunnableThreadPThread::Run() Address = 0x1096e0508 (filename not found) [in UE4Editor-Core.dylib]
FRunnableThreadPThread::_ThreadProc(void*) Address = 0x10966cac4 (filename not found) [in UE4Editor-Core.dylib]
_pthread_start Address = 0x7fff2038a950 (filename not found) [in libsystem_pthread.dylib]
thread_start Address = 0x7fff2038647b (filename not found) [in libsystem_pthread.dylib]

[microdee]

The plot thickens.

So without the device drivers space mice are not recognized at all, or recognized as regular mouse, which then the OS prevents direct access to fight keyloggers. After I've installed the drivers 3DConnexion takes exclusive access for the space mice as well so no other application can read its HID data directly (unlike on Windows where applications can still access HID data).

As a solution I can either use 3DxWare SDK on MacOS (you need to install drivers there anyway), or copy whatever blender is doing (source | header) instead of using the hidapi wrapper. That will require another refactoring again unfortunately, because current code somewhat assumes that the device is opened with hidapi, so I'll need to introduce a proper abstraction interface for data acquiring as well.

[microdee]

Progress:

I've copied what Blender is doing and it registers the functions correctly and the driver returns a client ID and also calls the Device connected callback. But it doesn't send any further messages to UE4. The documentation says nothing about the need for triggering a "message loop" from the app, or the need for any sort of polling. Registering the callbacks are all successful, or in worst case scenario it just fails silently. Even more worst case scenario, it might do some voodoo magic under the hood with Cocoa and expects the thread it's registered from to be the same as the one responsible for the event loop of the window. I really hope that's not the case. I already have limited debugging capabilities because macOS just refuses to cooperate on anything, so debugging such cases will be just extremely frustrating.

My suspicion atm is that during registering, 3DxWare SDK needs the CFBundleSignature and an "Application’s executable name". The latter is no problem to get of course, but the CFBundleSignature for the unreal editor at least is ???? according to its Info.plist and I'm not sure if the 3DConnexion drivers tolerate that.

The meat of the macOS implementation is in here https://github.com/microdee/UE4-SpaceMouse/blob/topic/mac-support/Source/SpaceMouseReader/Private/Mac/TDxWareReadingMethod.cpp

Side note: the 3DxWare SDK documentation mentions this:

Which is bamboozling me because Hidapi also uses HID Manager and it doesn't let me open the device, complaining about the fact that another program already has exclusive access to the device (the 3DConnexion drivers I presume). And this whole ordeal with the official drivers are done because of that.

rant:

For the love of god 3DConnexion why a dumb C header/source file pair wasn't enough to access space mice with HID, and then let the applications decide what to do with that data and how?

[MatusGasparik]

Hi @microdee. Any progress on this issue?

[microdee]

Nope and there never will be, I've tried this a year ago but I've hit a brick wall with how space mice are handled on macOS. 3DConnexion doesn't support getting raw device data anymore either. The Blender method didn't work out either for Unreal engine for some cursed frustrating reason I don't remember anymore. On top of that, I have an intensive hatred towards everything what Apple does, including their software, Unreal development is crippling to say the least on macOS (maybe it's better now that Rider supports macOS tho). So I will not attempt it again. I leave this issue open and "help wanted" in the hopes of someone working with Unreal owning a SpaceMouse and has a solid know-how in macOS low level programming can help with this.

[microdee]

I've just got the news that 3DConnexion is ready with their plugin for Mac, and they will release it very soon. They also told me that in that version they have implemented support for multiple viewports, which was the greater selling point for my stuff, so if they do that and on Mac, I can chicken out of implementing my own. In my original efforts I would have ended up using their navigation library anyway.
In light of that I will close this issue, and tag it as 'won't fix'.

[AndrewCapon]

@microdee

Sorry to resurrect this but as far as I can see there is still no plugin available from 3DConnexion for Macs.

Can anyone help me out?

Cheers

Andy

[microdee]

there is still no plugin available from 3DConnexion for Macs

damn my contact at 3DConnexion told me "Yes, we have a working solution for the Mac but it is not published yet" exactly a year ago. so they don't?

[AndrewCapon]

Well, not that I can find :)

There was a recent post in October from someone on their forum saying it was still not available.

https://forum.3dconnexion.com/viewtopic.php?p=118077&hilit=unreal#p118077

[tietoafinlandoy]

+1

It's a shame that such a great piece of hardware has pending software support (for MacOS / UE5). Perhaps we are too few for the priority. Just bought 4 Enterprise versions... perhaps we figure out a way to use the application specific mapping (3D Connexion Home/ prpoerties/... ) to manually map the buttons and movements to final game? Not yet tested and slightly afraid that the movement won't still work at all or as expected.

[microdee]

Well, not that I can find :)

There was a recent post in October from someone on their forum saying it was still not available.

https://forum.3dconnexion.com/viewtopic.php?p=118077&hilit=unreal#p118077

oh well, then either I've been lied to, which I doubt, or they're still working on it / being blocked

+1

It's a shame that such a great piece of hardware has pending software support (for MacOS / UE5). Perhaps we are too few for the priority. Just bought 4 Enterprise versions... perhaps we figure out a way to use the application specific mapping (3D Connexion Home/ prpoerties/... ) to manually map the buttons and movements to final game? Not yet tested and slightly afraid that the movement won't still work at all or as expected.

Unfortunately the problem is not with demand, the demand is there, I spent the better part of a year to try to make it work on MacOS but I had to fight against the OS every step on my way. I'm sure 3DConnexion have their own blocking issues with this. You can read my frustration in this issue especially #4 (comment) . Since that I've improved a lot as a developer and probably I'd have a calmer approach to it. On top of that these days I cannot put so much effort into this plugin as I have different projects with much less 3D in them.

[AndrewCapon]

Hi David,

I can have a look at getting it going if you would like?

I’m an ageing developer with quite a bit of Mac and IOS development experience.

I’ll make a fork and have a look…

cheers

Andy

[tietoafinlandoy]

Hi @AndrewCapon,

let us know if you need a device for testing.

[AndrewCapon]

Thanks, I have a SpaceMouse here though.

I'll see if I can get some time over Christmas to have a look...

[tietoafinlandoy]

While working on the project, one feature wish pops up: inertia effect for the camera control on UE editor viewport. Why? Because we also use direct screen video recording while flying inside the models. With inertia effect the movements can be made less jerky and more soft, floaty, dream like movement.

Maybe some parameters to simulate the mass and friction so that when user moves the camera, it starts to accelerate and when user stops to give input, the camera still flies (decelerates) for a set moment? And for a complex fly path, instead of 1:1 replicated (jittery hand) input movements, we would see softened fly path due to simulated mass and friction compensating the sensitivity (regardless the existing speed settings) of SpaceMouse .

I recall there was a SpaceMouse application where this was simulated but cannot remember anymore what it was. Just that it worked very well after setting up the parameters to match ones preferences. It took a moment to learn how to predictively fly "the heavy ship" but was actually really easy to master.

[microdee]

Hi David,

I can have a look at getting it going if you would like?

Wooow that would be the best! I cannot thank enough. If you manage to do this we should arrange a share from the epic games store, although it's like 200 bucks a month so not much.

Also sorry about my coding decisions at some places, I'd do them differently these days probably

While working on the project, one feature wish pops up: inertia effect ...

That's a feature request tho and off-topic. TBH I'm not too sure about this feature, this works in games where you pretend to drive around a space ship or so (I hooked up my space mice to space-sims and it's quite good there), but for editors you need precision and response without latency. If you want such a feature, I'd recommend tweaking the pawn actor from the SpaceMouse test-project and then program to record its motion, if you want to make a fly-around of your scene.

[tietoafinlandoy]

@AndrewCapon how is your time? Would you be available and willing to negotiate a small project to try to make the Mac-version functional? @microdee are you motivated to follow-up/ join if we try to support a small project to help to bring on the Mac support?

[AndrewCapon]

I did have a look over the break, got the HID stuff logging but as @microdee found out when the drivers are installed the HID no longer works.

So the only reliable solution is to use the driver.

Unfortunately the driver did not work correctly on the MacBook M1 I was using, even though it had grabbed the SpaceMouse it didn't seem to recognise it!

So at that point I gave up :)

My main Mac does have the driver installed, if I do get some time I will have a play with the stuff @microdee has already done: https://github.com/microdee/UE4-SpaceMouse/blob/topic/mac-support/Source/SpaceMouseReader/Private/Mac/TDxWareReadingMethod.cpp

I did have a quick look at the code and I'm also guessing it is an event loop issue, need to get it built and test what thread is being used, probably not the main event loop thread.

Not promising anything though so don't hold your breath...

[AndrewCapon]

@microdee

I'm trying to set up UE5/Xcode/UE4-Spacemouse, I have added the plugin to the project from my fork on git.

What is "HIDUE":

		{
			"Name": "HIDUE",
			"Type": "Runtime",
			"LoadingPhase": "PreDefault",
			"WhitelistPlatforms": [
				"Linux",
				"Win64",
                               "Mac"
			]
		},

When building I get:

Could not find definition for module 'HIDUE', (referenced via MyProject.uproject -> SpaceMouse.uplugin)

[AndrewCapon]

Ok, don't worry got it: https://github.com/microdee/HIDUE

[microdee]

yep HIDUE is a submodule git submodule --update, I used it once in two other site-specific projects but it might as well be part of SpaceMouse for UE now.

[microdee]

are you motivated to follow-up/ join if we try to support a small project to help to bring on the Mac support?

I have enough things in my life and in my work which refuses to cooperate despite meeting all their requirements on paper so I kindly refuse yet another one with a deadline added. (referring to MacOS development here)

[tietoafinlandoy]

@microdee true, previous deadline passed already. Now there is no particular known deadline to us at the moment. Yet, we know that functional Mac support - when ever available - would be implemented on the current product. But, rarity of Mac UE5 in general, including our thin foreseeable horizon leaves us with little to none reasoning power for the priorities.

[AndrewCapon]

@microdee

This is a little weird but I have the SpaceMouse working here.

With it using the drivers it was not working, some jerky movement but not much sense.

So I hacked it to use HID instead on the Mac and here on Ventura with Unreal 5.3.2-29314046+++UE5+Release-5.3 it all seems to work!

I have not really changed any code, just some renames as things have changed since you did the Mac code.

You can see what I have done here: https://github.com/AndrewCapon/UE4-SpaceMouse/tree/arc_mac_changes

So very weird!

[tietoafinlandoy]

Ok! That's interesting. We will have a look on it.

[microdee]

so that means basically the HID reading would have worked the whole time on MacOS Ventura + UE 5.3? hmm either Unreal or MacOS got updated in our favor apparently.

[AndrewCapon]

I'm wondering if it is a maybe a Sandbox Entitlement setting in Unreal Engine that may have been added.

[microdee]

It looks like I can borrow a friend's macbook to test this, if it works I can make a release probably

[AndrewCapon]

Fingers crossed :)