[ANN] opentrack 2.0 beta 1 released!
-
Thank you Stanislaw. I’ve already opened a bug on the linuxtrack github and I’m also in contact with the linuxtrack-wine author who told me it must be a bug on the linuxtrack side of things; sadly I haven’t heard back from uglydwarf since first mentioning the issue a few weeks ago:
He’ll get to it. He’s a really decent guy and was in fact instrumental in opentrack’s support for “trackir enhanced” titles.
currently I have the feeling I’m the sole Linux opentrack user on the planet
There are few users. Check the issue tracker for closed issues. I’m generally hostile given Linux users are an entitled bunch and can’t RTFM before claiming something’s broken. Use Windows if you can’t RTFM. So yes, I’ve been more patient given you’re from the BMS community and we’ve had a few interactions.
My position has been consistently that Linux is an OS for software developers and not regular users. The GUI’s don’t give enough control over the internals and are buggy. This has been true over a decade.
I personally use Linux support for Valgrind and clang sanitizers. Proper support for X11 keystrokes is something that took few hours to complete but years to even start.
And no, you can’t achieve the same level of compatibility, or the same performance for new game titles, whether with gallium-nine or any particular drivers. There’s also a good reason old games have comparable performance but new ones don’t.
I was thinking about including the build date in the directory name so we can keep several builds alongside each other.
I’d suggest including the date (in year-month-day format) along with the git commit. BUT the better solution is to finish the .deb generation scripts. See: https://github.com/opentrack/debian
As for the WINE version, I’d go with winehq stable which is where I get the development files from in the cloudinit script, so I hope the versions will match in a runtime environment that uses the binary build.
This is unlikely to be the same version as the distro’s version. Also note that distros provide separate “wine” and “wine-development”, or possibly even “wine-staging” packages. They’re all of different versions.
PS: If you could confirm z-axis FOV control works as advertised in BMS on Wine that would be great.
I did some years ago. It’s not likely to be any different, given the original trackir code was written by Retro quite a few years ago. You can check the leaked sources for the original SuperPak.
I’m not a TrackIR user, I’m using FaceTrackNoIR with the pointtracker plugin and the DelanClip.
opentrack supports IR tracking via libv4l. You’re unlikely to encounter problems. The unstable branch is quiet now and users confirm stuff works.
cheers,
sh -
Thanks for the input, Stanislaw.
I remembered this morning I have a spare laptop lying around that I already upgraded to 18.04 a few months ago, so I decided to give the binary build linked to above a try on this machine.
Yay!
I only needed to install two exta packages (libopencv_videoio and libtqserialport) and opentrack launched without any missing library errors. I think most folks actively using WINE on Linux will already have the winehq versions / repos installed (like it was the case on my forgotten notebook), so we could put this info into the install instructions in a ReadMe.Linux file or similar.
The sine wave sim works nicely and I even got some “octopus movement” by using the pointtracker plugin without a clip, just waving my hand in front of the camera, so that part seems to work, too. I’ll do some more testing with a proper clip & cam later.
As for linuxtrack, I was told by the developer of the linuxtrack-wine plugin that z-axis tracking used to work fine years ago when he was still actively developing the code, so he suspected something must have changed within linuxtrack itself about the handling of the input to the wine plugin; I’ll be monitoring the github issue for new comments on the problem.
I tried to compile linuxtrack myself from source at first, but ran into similar problems as with opentrack, so I decided to fix the opentrack build problems first as I hadn’t tried your tracker yet and its community seemed more active on github.
Yes, uglydwarf is a great guy, he helped me a lot getting up to speed w/r to x-plane on Linux and headtracking, so I’m hoping he’ll address the issue (or at least maybe give an idea what to look for) soon.
To send opentrack tracking data towards BMS all I need to do is to select “wine” as the output plugin, right? Do I need to copy your NPClient*dlls into the WINE_PREFIX I’m using? I think I checked this before and they’re exactly the same size as the ones I’m already using with linuxtrack and BMS, I might want to look at the md5 hash though.
If you’d rather like to keep Linux build / install specifics out of this announcement thread please let me know and I’ll open a separate one. (hopefully in soon-to-appear “Linux and other OSes” subsection of this forum that I’ve been dreaming about for a few years now :))
As for your views on Linux as an end user platform I think we discussed that before in the “Linux dedicated server” thread, so let’s just agree to disagree for now
Thanks again for your help & I’ll report back later about how the actual tracking goes.
All the best,
Uwe
-
Thanks for the input, Stanislaw.
I remembered this morning I have a spare laptop lying around that I already upgraded to 18.04 a few months ago, so I decided to give the binary build linked to above a try on this machine.
https://i.imgur.com/ttjuqxs.png?1
Yay!
I only needed to install two exta packages (libopencv_videoio and libtqserialport) and opentrack launched without any missing library errors. I think most folks actively using WINE on Linux will already have the winehq versions / repos installed (like it was the case on my forgotten notebook), so we could put this info into the install instructions in a ReadMe.Linux file or similar.
A few things:
- winehq .deb versions were missing winegcc or something crucial to it. I tried using them and it wasn’t too long ago.
- you don’t need dependencies like libqt5serialport{,-dev}. that one’s for the hatire tracker. you only need libopencv including videoio and Qt5 dev headers/tools (including lupdate and lrelease).
- opentrack will handle moving the installation directory around. you can move from /usr/local/opentrack to /opt/on-the-moon/foo and it’ll work just fine.
- just in case, don’t install stuff like Wine to /usr/local. use /opt/app-name with optional version. just get the habit right. you can symlink the executables to /usr/bin.
- don’t ever install anything to /usr/local.
You can put build information on the opentrack project’s wiki, and if you can confirm this information is complete, I’m going to link to it more officially. Please note, using “debootstrap” you can create a fully-working chroot environment for a particular distro in order to verify whether there’s something else needing to be installed.
As for linuxtrack, I was told by the developer of the linuxtrack-wine plugin that z-axis tracking used to work fine years ago when he was still actively developing the code, so he suspected something must have changed within linuxtrack itself about the handling of the input to the wine plugin; I’ll be monitoring the github issue for new comments on the problem.
I’d like to know whether X and Y scaling is fine and only Z scaling is broken. They’re probably multiplying by the wrong value when outputting position coordinates.
- If all position changes are wrong, you can present that as a solution to the developers. The scale should be 0->1000 and BMS needs 200-300 or so. Depends on a game.
- If X and Y works while Z remains broken, it’s a more involved issue.
To send opentrack tracking data towards BMS all I need to do is to select “wine” as the output plugin, right? Do I need to copy your NPClient*dlls into the WINE_PREFIX I’m using? I think I checked this before and they’re exactly the same size as the ones I’m already using with linuxtrack and BMS, I might want to look at the md5 hash though.
In order to use the Wine plugin you need to:
- Make sure any game is stopped.
- Start opentrack with Wine output once. If Wine initializes the WINEPREFIX, wait for it to complete. Otherwise just stop tracking after a second or two.
- Start a game.
- Start tracking when you need it.
You only need to perform this procedure once for the WINEPREFIX you’re using, unless something changes the NPClient64.dll path.
If you’d rather like to keep Linux build / install specifics out of this announcement thread please let me know and I’ll open a separate one. (hopefully in soon-to-appear “Linux and other OSes” subsection of this forum that I’ve been dreaming about for a few years now :))
As for your views on Linux as an end user platform I think we discussed that before in the “Linux dedicated server” thread, so let’s just agree to disagree for now
I’m happy you’re doing this, both personally and for the project’s sake. There’s indeed some Linux following and we might be able to contact many of the users, even if not on the BMS forum.
Is a Linux board going to open on this forum? I’d like that too. The chief issue is your opentrack binary version being intrinsically tied to the Wine version on your system. A script installing opentrack from the ground-up would be helpful to users as well. I’m going to work on the .deb package builder in the meantime.
Know that when Linux starts being a useful platform for end-users, I’m the first to say so. For now I’m tracking work on KDE Plasma, wined3d, Mesa, gallium-nine, DRI and so on. Even when not using Linux on my workstation. OSX has even worse GPU support so it’s out of the question as a Windows game box replacement.
-
Another small update:
I installed BMS on my lowly laptop (Ubuntu 18.04 LTS, M 540 i5@2,5GHz, 4GB RAM, gt220 mobile gpu){1} and connected a home built clip. Tracking works quite nicely using the “octopus” as an example, also the FOV range seems much bigger than in linuxtrack; I’m seeing z coordinates from 5 (far away) to -25 or so (near the screen). Mind you that’s using the unmodified laptop webcam so I’d expect better results when using a ps/eye cam or dimming down the webcam using some exposed film (I’ll try that later) to improve tracking quality.
I may also give linuxtrack a go on the laptop in order to compare its tracking values with what opentrack shows.
I had to start tracking in opentrack before launching BMS in WINE, otherwise it would not let me tick the relevant TIR boxes in the “view control” advanced setup screen.
During the next week I’ll hopefully get around to modifying my build scripts as we outlined above to include a proper path and a build date.
A Deb package would be great to have available, but I’m afraid my last attempts on package building management date back to the very early Red Hat / CentOS days and I’ve never fiddled with building debs yet.
Would a PPA be easier to use here?All the best, Uwe
1: I’m getting suprisingly good fps in “moving mud” over water in KTO after dialling down all the graphics
-
Mind you that’s using the unmodified laptop webcam so I’d expect better results when using a ps/eye cam or dimming down the webcam using some exposed film (I’ll try that later) to improve tracking quality.
There are two kinds of ps3 eye cameras. One can be modified only with losing the ability to set FOV anywhere else than 75. The other one allows for FOV of 56 and I’m happy to have one. Having fov 75 on the red dot will make your points occlude one another a lot.
I had to start tracking in opentrack before launching BMS in WINE, otherwise it would not let me tick the relevant TIR boxes in the “view control” advanced setup screen.
See my previous post.
1: I’m getting suprisingly good fps in “moving mud” over water in KTO after dialling down all the graphics
Over water is different.
-
I’m pleased to make available a new binary build for Ubuntu 18.04 based Linux systems to the BMS community:
https://zif.gplrank.info/hoover/opentrack/opentrack-git-20181113.tar.gz
The archive includes an “opt/”-Prefix so you can extract it to your root folder, but as shtalik mentioned above the binary is location agnostic so you should be able to extract it to whereever you like.
Please let me know if any shared libraries come up missing on your end and I’ll try to help track down the appropriate packages (or just use “apt-file search <library name=”“>”).
All the best, Uwe</library>
-
The binary works fine on Linux Mint 19 (based on Ubuntu 18.04), I just needed to install guvcview to turn down the camera gain (my ps/eye has the IR filter removed) and opentrack worked beautifully swivelling the “Octopus” around in the preview. Now on to BMS running on Linux / WINE, I’ll report my findings here if that’s ok.
I didn’t need to install any additional libraries except these:
apt install –install-recommends libopencv-videoio3.2
apt install --install-recommends libqt5serialport5All the best,
Uwe
EDIT: Works like a charm including FOV z-axis control, very nice
Falcon BMS in WINE running alongside YAME64 (the blank spot is where my A10 tablet usually sits on the 2nd monitor):
-
Good Job Sthalik !
-
Hi folks,
I’m happy to announce the availability of a new opentrack git build for Ubuntu 18.04 based 64bit systems. You can download it here:
https://zif.gplrank.info/hoover/opentrack/opentrack-git-20190118.tar.gz
MD5 checksum:
fdb2a6ae0d13750310c340ca62a4378d opentrack-git-20190118.tar.gz
The tar archive extracts to /opt/opentrack-git-20190118 as usual.
All the best & have a good weekend,
Uwe
-
Hey,
Please install libevdev-dev and libeigen3-dev before configuring with cmake. Otherwise you’re missing several modules.
I’m attaching an AppVeyor config for building on a clean Ubuntu 18.04 environment. It’s notably missing “software-properties-common” and “curl” since AppVeyor VMs have it in already. You should be able to automate the build based on that.
-
Thanks Stanislaw!
Both packages are installed automatically by my openstack user init script during spin-up of the VM before attempting the opentrack build:
ii libeigen3-dev 3.3.4-4 all lightweight C++ template library for linear algebra ii libevdev2:amd64 1.5.8+dfsg-1 amd64 wrapper library for evdev devices
I hope these are the correct versions.
All the best, Uwe
-
You specifically need libevdev-dev in order for the virtual joystick output module to be built.
-
Hi,
I added the package to the cloudinit script and rebuilt opentrack, should be in the download package now as well.
All the best,
Uwe
-
Sorry to necromance this thread, but has anyone built the current version of opentrack (git or 2.3.12) successfully on an Ubuntu 20.04 based platform?
TIA & all the best,
Uwe
-
Sorry to necromance this thread, but has anyone built the current version of opentrack (git or 2.3.12) successfully on an Ubuntu 20.04 based platform?
TIA & all the best,
Uwe
i built a deb package for my debian testing, you find it in the github page of the project.
-
Thanks for the info massima, however I seem to be too dumb to find it in the various subfolders… can you enlighten me to just where you uploaded it? Or should I be looking for a spec file that allows me to build the package from source on a debian based system like Ubuntu?
Thanks & all the best,
Uwe
-
Never mind, I managed (after lots of teeth gnashing and hair pulling) to re-compile the latest git sources on Linux (Mint 20) with the barest minimum of plugins, protocols and filters that I’m using (pointtracker, accelera, wine, xplane).
I’ll prepare a new Linux download over the next couple of weeks that’s compatible with Ubuntu 20.04, and I’m happy to report the xplane11 / Linux side of things is already working quite well.
All the best,
Uwe
PS: The worst issue was that I have apparently deleted my old cloudinit script for Ubuntu 18.04 which spun up a VM in an openstack cluster, installed all the needed packages, pulled the git source and xp11 sdk from the net and more or less automatically build the latest opentrack… I have no idea how this could have happened :uham:
-
Thanks for the info massima, however I seem to be too dumb to find it in the various subfolders… can you enlighten me to just where you uploaded it? Or should I be looking for a spec file that allows me to build the package from source on a debian based system like Ubuntu?
Thanks & all the best,
Uwe
I uploaded it in my gdrive space (here), it can be reached by a link in the wiki page of the project.
The deb package can be installed via “dpkg -i opentrack_2.3.12-1_amd64.deb”, via gdebi or other tools; if you use latest Ubuntu, you shouldn’t have dependency issues. I compiled the core code without Wine/aruco/etc. -
Hi folks,
here’s a current build of opentrack for Ubuntu 20.04 based Linux systems. It contains just the minimum stuff to get head-tracking working (I’m using the DelanClip with a ps/eye webcam, so nothing fancy), but I hope some folks may find it useful still:
o input plugins: pointracker, test, UDP over network
o output protocols: libevdev, udp, flightgear, wine,
o filters: Accelera
https://www.magentacloud.de/lnk/jwBpmS02 (26MB)
Installation: extract to your /opt/ directory as “root” (for write permissions):
sudo tar -C /opt -xvpf opentrack_ubuntu_20_04.tar.gz
Alternatively, use the archive manager of your choice to extract the contents.
All the best & happy holidays!
Uwe
-
Could anyone help me a litlle with opentrack build? I’m trying to make fedora package. So far I’ve made to a point where opentrack compiles and runs, but offers only pointtrack input and accela filter. No other inputs/filters and no output protocols are offered.
List of dependencies installed:
git-2.29.2
cmake-3.18.4
qt5-qttools-5.15.2
qt5-qttools-devel-5.15.2
qt5-qtbase-5.15.2
qt5-qtbase-devel-5.15.2
qt5-qtbase-private-devel-5.15.2-2
procps-ng-3.3.16
procps-ng-devel-3.3.16
opencv-4.3.0
opencv-devel-4.3.0
libevdev-1.11
libevdev-devel-1.11
wine-6.3
wine-devel-6.3