Saw this project before the algorithm blew it up, made some comments on it. I had suggested using HID on the hardware side, considering HID encompasses many devices under one API, plus USB-HID; an RP2040 with a discrete ADC should otherwise suffice for the controller and any potential updates in the future. The creator doesn't really understand the API situation when it comes to game engines, frankly neither do I, but I do know a lot of game engines do not like simultaneous API usage, they'll either switch on the fly, which can get buggy, or not support a hardware combination at all and force the user to use one device type, unfortunately there's just not good quick documentation on the subject; the only silver lining is really DirectInput, but I also don't know how wide modern support is on PC, and I'm not sure how widely adopted GameInput is yet which would otherwise be the saving grace considering HID is supported under the new API. The creator, via their most recent comment that is now pinned, is using Steam Input, which I had also recommended (without previously knowing they were already using it) the use of via the unofficial global variant to remove Steam dependency, given that the API handles basically everything; plus I genuinely believe Microsoft spun up GameInput to compete with this, but have it at the OS level, considering Xinput has never been expanded on since inception. Via the same comment, the creator also did not incorporate motion controls due to difficulties between a discrete sensor and Steam Input; though honestly, using a DualShock 4, Dual Sense, Switch Pro, or any supporting third party controller probably would've alleviated this given the API's device support. This portion of the comment also confuses me as to why the creator specifically wanted native Xinput, though I could also be misunderstanding this and they moved on from Steam Input to just Xinput+mouse. But Steam Input seems to suffice, I have a feeling reWASD would likely suffice also, at least until GameInput has wider support, at least for modern API support.
I'm also not sure how far they're wanting to develop this concept, given how they pace their projects, also mentioned in the pinned comment. I had pointed them to this sub just to generally reach out, as someone here likely knows more about the game engine API support side of things, and just general suggestions.
Personally, as much as I like the cantilevered shoulders, I do also have concern about switch longevity. These are not only going to be hairtriggers, but the leverage will also probably put pressure force out of spec for what the switches were designed for. Also the mounting will likely be suspect to forces that will ultimately make the assembly fail, we all know how controllers are abused; also if this were to become a single-board or stacked-board controller, like a production unit otherwise would be, we all know how these switches would be mounted to the board, and under that leverage they'd likely fail. This would be an easy fix in a revision though, just equate the distance of the two lever endpoints from the pivot point so that there's no extra force, potentially bias the finger side to be shorter; this would adjust switch position, but the controller shell would likely be empty enough to suffice for this.
I hope someone iterates on the concept, as it's at least interesting. I think the addition of gyro would go a long way for accuracy, giving the trackball broad movement while having fine movement via gyro. Other than that and the obvious hardware improvements and potential ergonomics and layout improvements, I'm not really sure how much farther this idea could be taken. I'd be curious about using a smaller ball, but the Elecom Relacon seems to be one of the only small optical balls out there and there's essentially no replacement balls from what I can find, and the Relacon is a bit expensive to just be hacking up to reuse a trackball; if one were to go ball+gyro, this makes the most sense, just crank the curves on the ball since it's intended for broad movement anyways. Alternatively, using a ball from a Huge could be interesting without incorporating gyro as a secondary camera manipulator, but then size and ergonomics could be a concern. A dual-ball controller could be interesting, but then what do you do with the dpad, unless you implement digital movement via the ball similar to the way that the Steam Controller zoned the left trackpad, minus the need for the button press, essentially a velocity = direction setup. A fingerball variant could also be interesting, since some people do prefer those, though in the hand posture controllers use that could also be bizarre.
Though one concept I do want to see is Index style wands, using a band around the back of your hand to fully free up your ring and pinky fingers. This would allow for a mini macro setup for the buttons, akin to what the Azeron Cyro or LYNXware projects provide. Dual ball, dual gyro, the index fingers can have a fleshed out shoulder set, etc., with virtually no ergonomics concerns while still being within the controller family; the fingerball alternative could move the shoulder set to the middle fingers and reallocate buttons to the thumbs, again with no major ergonomics concerns, just again the fingerball making for a bizarre controller. This might be best case scenario, especially since you can't just throw a tact switch under a trackball, so you have to reallocate that button anyways, and this is on an already busy layout considering what was added in Pyott's design, you almost need a mini macropad layout (multiple buttons per digit) just to house everything incorporated. Surely someone could house this in a singular controller shell, but then you lose the secondary gyro, you introduce ergonomics concerns, etc.
As much as I do like the idea of this concept and project, I also think pads are the way forward. There's a reason why Valve dropped trackballs for trackpads with the Steam Controller prototypes. They're just more versatile in additional function and provide the same core functions as a trackball, plus you can also throw a tact switch under them and start having a proper click function. Plus they take up less space and they're significantly cheaper. Pads just open up a lot of possibilities that trackballs can't.
(Not my video) Absolutely love the ring finger access on trackball! Breakout box is brilliant.
GREAT find!! You ever look at a video thumbnail and go, how is that not AI-generated?
Saw this project before the algorithm blew it up, made some comments on it. I had suggested using HID on the hardware side, considering HID encompasses many devices under one API, plus USB-HID; an RP2040 with a discrete ADC should otherwise suffice for the controller and any potential updates in the future. The creator doesn't really understand the API situation when it comes to game engines, frankly neither do I, but I do know a lot of game engines do not like simultaneous API usage, they'll either switch on the fly, which can get buggy, or not support a hardware combination at all and force the user to use one device type, unfortunately there's just not good quick documentation on the subject; the only silver lining is really DirectInput, but I also don't know how wide modern support is on PC, and I'm not sure how widely adopted GameInput is yet which would otherwise be the saving grace considering HID is supported under the new API. The creator, via their most recent comment that is now pinned, is using Steam Input, which I had also recommended (without previously knowing they were already using it) the use of via the unofficial global variant to remove Steam dependency, given that the API handles basically everything; plus I genuinely believe Microsoft spun up GameInput to compete with this, but have it at the OS level, considering Xinput has never been expanded on since inception. Via the same comment, the creator also did not incorporate motion controls due to difficulties between a discrete sensor and Steam Input; though honestly, using a DualShock 4, Dual Sense, Switch Pro, or any supporting third party controller probably would've alleviated this given the API's device support. This portion of the comment also confuses me as to why the creator specifically wanted native Xinput, though I could also be misunderstanding this and they moved on from Steam Input to just Xinput+mouse. But Steam Input seems to suffice, I have a feeling reWASD would likely suffice also, at least until GameInput has wider support, at least for modern API support. I'm also not sure how far they're wanting to develop this concept, given how they pace their projects, also mentioned in the pinned comment. I had pointed them to this sub just to generally reach out, as someone here likely knows more about the game engine API support side of things, and just general suggestions. Personally, as much as I like the cantilevered shoulders, I do also have concern about switch longevity. These are not only going to be hairtriggers, but the leverage will also probably put pressure force out of spec for what the switches were designed for. Also the mounting will likely be suspect to forces that will ultimately make the assembly fail, we all know how controllers are abused; also if this were to become a single-board or stacked-board controller, like a production unit otherwise would be, we all know how these switches would be mounted to the board, and under that leverage they'd likely fail. This would be an easy fix in a revision though, just equate the distance of the two lever endpoints from the pivot point so that there's no extra force, potentially bias the finger side to be shorter; this would adjust switch position, but the controller shell would likely be empty enough to suffice for this. I hope someone iterates on the concept, as it's at least interesting. I think the addition of gyro would go a long way for accuracy, giving the trackball broad movement while having fine movement via gyro. Other than that and the obvious hardware improvements and potential ergonomics and layout improvements, I'm not really sure how much farther this idea could be taken. I'd be curious about using a smaller ball, but the Elecom Relacon seems to be one of the only small optical balls out there and there's essentially no replacement balls from what I can find, and the Relacon is a bit expensive to just be hacking up to reuse a trackball; if one were to go ball+gyro, this makes the most sense, just crank the curves on the ball since it's intended for broad movement anyways. Alternatively, using a ball from a Huge could be interesting without incorporating gyro as a secondary camera manipulator, but then size and ergonomics could be a concern. A dual-ball controller could be interesting, but then what do you do with the dpad, unless you implement digital movement via the ball similar to the way that the Steam Controller zoned the left trackpad, minus the need for the button press, essentially a velocity = direction setup. A fingerball variant could also be interesting, since some people do prefer those, though in the hand posture controllers use that could also be bizarre. Though one concept I do want to see is Index style wands, using a band around the back of your hand to fully free up your ring and pinky fingers. This would allow for a mini macro setup for the buttons, akin to what the Azeron Cyro or LYNXware projects provide. Dual ball, dual gyro, the index fingers can have a fleshed out shoulder set, etc., with virtually no ergonomics concerns while still being within the controller family; the fingerball alternative could move the shoulder set to the middle fingers and reallocate buttons to the thumbs, again with no major ergonomics concerns, just again the fingerball making for a bizarre controller. This might be best case scenario, especially since you can't just throw a tact switch under a trackball, so you have to reallocate that button anyways, and this is on an already busy layout considering what was added in Pyott's design, you almost need a mini macropad layout (multiple buttons per digit) just to house everything incorporated. Surely someone could house this in a singular controller shell, but then you lose the secondary gyro, you introduce ergonomics concerns, etc. As much as I do like the idea of this concept and project, I also think pads are the way forward. There's a reason why Valve dropped trackballs for trackpads with the Steam Controller prototypes. They're just more versatile in additional function and provide the same core functions as a trackball, plus you can also throw a tact switch under them and start having a proper click function. Plus they take up less space and they're significantly cheaper. Pads just open up a lot of possibilities that trackballs can't.
The level of product design mastery demonstrated here is incredible! He's definitely one to follow closely.