Showing posts with label software. Show all posts
Showing posts with label software. Show all posts

Wednesday, June 10, 2015

Head Tracking with FaceTrackNoIR

I've been aware of head tracking solutions since I started playing Arma 2; the game (and it's sequel, Arma 3) has the ability to "freelook", meaning you can continue to walk or point your weapon in a certain direction, while you scan your surrounding environment. This is extremely useful from a tactical standpoint, but it's also particularly helpful when piloting vehicles (especially helicopters). Probably the most well-known commercial solution is TrackIR; this kit comes with everything you need to start using head tracking in games that support it, but it's a little on the expensive side (around £175). Despite some serious consideration, I never actually bought the kit myself; I didn't think it was worth it considering the relatively small number of games I play that would benefit from it, especially when consumer versions of both the Oculus Rift and HTC Vive are not far off. So I was extremely excited when I happened across a post discussing head tracking on the Elite: Dangerous subreddit that mentioned a free alternative: FaceTrackNoIR. As it's name suggests, this little bit of software can use a webcam attached to your machine to track your actual face; when you hit "start", it identifies the basic shape of your face, then translates your movements into the desired protocol for the game to understand.
Tracking my FACE!

The application has quite a few configuration options and it took me a fair amount of time tinkering with them to achieve the desired results, but to say I was impressed is an understatement: being able to simply move my head and look down at the spot where I was trying to land my heli was not only super cool, but useful too! Once I started using it, I didn't want to stop, however it does have a couple of drawbacks:
  • It's sensitive to poor lighting - I actually found if it was particularly bright outside, the software would often lose or simply not be able to recognise my face.
  • The CPU usage is fairly high - it seemed to fluctuate between roughly 5-10% when in use; that's a fair amount of precious CPU cycles that could be put to use by a game engine (Arma 3 being particularly CPU hungry)!
After having a play around with the different settings in the application and reading the FaceTrackNoIR wiki, I discovered that there are a few different tracking sources available, one of which works in a similar fashion to TrackIR. This helps to improve accuracy and/or reduce the CPU load, but unfortunately is still susceptible to poor lighting and also requires an IR clip providing three points to track. However, on the same Reddit post I mentioned earlier, somebody commented that they had bought a "relatively cheap" IR clip to use with this particular mode of operation: the DelanClip. Given the low cost, I thought I'd give it a go myself. The kit I bought is the most basic model and comes with a USB powered IR clip, two cable ties and a couple of sections of coloured film that can be used to create a light filter for your webcam:
Attached DelanClip

Webcam with filters attached.

After I'd finished setting up, I downloaded the latest version of the PointTracker plugin (overwriting the version that ships with FaceTrackNoIR), tweaked my config and fired it up. I found that I only really had to tweak the curves that define the translation between your actual head and your in-game character to my liking (here's my config file if you're interested) and make sure there were no direct light sources in the webcam's field of view.
3x IR point tracking

I've definitely had more luck using the PointTrack plugin than the FaceAPI; there has been much fewer incidents of the software "losing" me. If there's anybody reading this wondering just how beneficial free-look in games can be, let me just show off a couple of Elite: Dangerous screen caps I took while using FaceTrackNoIR:
Checking my flight path is clear before leaving the landing pad.

Tracking an enemy ship that would have otherwise flown out of my line of sight.

Of course, these actions could be achieve using regular input (mouse, keyboard or even a hat-switch on a joystick), but I honestly feel that head tracking provides a more natural and (sigh) immersive experience. The only thing that will surpass this (in my opinion) will be a full VR headset, which I'll definitely be wanting to get my hands on once consumer devices are available!

Sunday, June 20, 2010

Adobe Flash Plugin on Fedora 13 x86_64

I upgraded my work laptop to Fedora 13 over the weekend. As always, I was impressed with the new features and desktop theme! In order to extend the core system's functionality, I used the Personal Fedora 13 Install Guide. There has been a version of these guides produced for each release of Fedora as far as I'm aware and they're a great resource for adding all the additional apps and utilities you might need to a fresh install of Fedora.

When I tried to install the Adobe Flash Plugin, I followed the guide as usual (in fact, I've performed the installation of the plugin on Red Hat systems so many times, it has become second nature). However, I was greeted by an error message:


Transaction Check Error:
package nss-softokn-3.12.4-19.fc13.x86_64 (which is newer than nss-softokn-3.12.4-17.fc13.i686) is already installed


There appeared to be a clash between the 64bit (x86_64) and 32bit (i686) versions of the nss-softokn package. When installing 32bit software on a 64bit distro release, you often have to install some additional 32bit libraries to support the application in question. In this case The 32bit version of the nss-softokn package was required in order for the 32bit Flash plugin to be installed.

A bit of searching online revealed that the workaround was to simply downgrade the 64bit nss-softokn package to the same version as the 32bit package that yum was attempting to install:


[root@redpill ~]# yum downgrade nss-softokn-3.12.4-17.fc13
Loaded plugins: presto, priorities, refresh-packagekit
Setting up Downgrade Process
4 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package nss-softokn.x86_64 0:3.12.4-17.fc13 set to be updated
---> Package nss-softokn.x86_64 0:3.12.4-19.fc13 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

=====================================================================================================================
Package Arch Version Repository Size
=====================================================================================================================
Downgrading:
nss-softokn x86_64 3.12.4-17.fc13 fedora 168 k

Transaction Summary
=====================================================================================================================
Remove 0 Package(s)
Reinstall 0 Package(s)
Downgrade 1 Package(s)

Total download size: 168 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 168 k
nss-softokn-3.12.4-17.fc13.x86_64.rpm | 168 kB 00:02
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : nss-softokn-3.12.4-17.fc13.x86_64 1/2
Cleanup : nss-softokn-3.12.4-19.fc13.x86_64 2/2

Removed:
nss-softokn.x86_64 0:3.12.4-19.fc13

Installed:
nss-softokn.x86_64 0:3.12.4-17.fc13

Complete!


--------------------------------------------------

[root@redpill ~]# yum install flash-plugin
Loaded plugins: presto, priorities, refresh-packagekit
4 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package flash-plugin.i386 0:10.1.53.64-release set to be updated
--> Processing Dependency: libsmime3.so for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libsmime3.so(NSS_3.4) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libssl3.so for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libsmime3.so(NSS_3.2) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libnss3.so(NSS_3.11) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libnss3.so(NSS_3.9.2) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libnspr4.so for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libnss3.so(NSS_3.2) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libssl3.so(NSS_3.2) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libnss3.so(NSS_3.6) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libplc4.so for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libnss3.so for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libplds4.so for package: flash-plugin-10.1.53.64-release.i386
--> Running transaction check
---> Package nspr.i686 0:4.8.4-2.fc13 set to be updated
---> Package nss.i686 0:3.12.6-4.fc13 set to be updated
--> Processing Dependency: nss-softokn(x86-32) = 3.12.4 for package: nss-3.12.6-4.fc13.i686
--> Processing Dependency: libnssutil3.so(NSSUTIL_3.12.3) for package: nss-3.12.6-4.fc13.i686
--> Processing Dependency: libnssutil3.so for package: nss-3.12.6-4.fc13.i686
--> Processing Dependency: libnssutil3.so(NSSUTIL_3.12.5) for package: nss-3.12.6-4.fc13.i686
--> Processing Dependency: libnssutil3.so(NSSUTIL_3.12) for package: nss-3.12.6-4.fc13.i686
--> Running transaction check
---> Package nss-softokn.i686 0:3.12.4-17.fc13 set to be updated
---> Package nss-softokn.x86_64 0:3.12.4-19.fc13 set to be updated
---> Package nss-util.i686 0:3.12.6-1.fc13 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=====================================================================================================================
Package Arch Version Repository Size
=====================================================================================================================
Installing:
flash-plugin i386 10.1.53.64-release adobe-linux-i386 4.5 M
Installing for dependencies:
nspr i686 4.8.4-2.fc13 fedora 112 k
nss i686 3.12.6-4.fc13 fedora 741 k
nss-softokn i686 3.12.4-17.fc13 fedora 169 k
nss-util i686 3.12.6-1.fc13 fedora 45 k
Updating for dependencies:
nss-softokn x86_64 3.12.4-19.fc13 updates 168 k

Transaction Summary
======================================================================================================================
Install 5 Package(s)
Upgrade 1 Package(s)

Total size: 5.7 M
Total download size: 168 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 168 k
nss-softokn-3.12.4-19.fc13.x86_64.rpm | 168 kB 00:01
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : nspr-4.8.4-2.fc13.i686 1/7
Installing : nss-util-3.12.6-1.fc13.i686 2/7
Updating : nss-softokn-3.12.4-19.fc13.x86_64 3/7
Installing : nss-softokn-3.12.4-17.fc13.i686 4/7
Installing : nss-3.12.6-4.fc13.i686 5/7
Installing : flash-plugin-10.1.53.64-release.i386 6/7
Cleanup : nss-softokn-3.12.4-17.fc13.x86_64 7/7

Installed:
flash-plugin.i386 0:10.1.53.64-release

Dependency Installed:
nspr.i686 0:4.8.4-2.fc13 nss.i686 0:3.12.6-4.fc13 nss-softokn.i686 0:3.12.4-17.fc13 nss-util.i686 0:3.12.6-1.fc13

Dependency Updated:
nss-softokn.x86_64 0:3.12.4-19.fc13

Complete!
[root@redpill ~]#



After restarting my browser, I was able to access Flash content online. The package manager even prompted me afterwards to upgrade the 64bit version of the nss-softokn back to version 3.12.4-19 and doing so seemed to have no impact on my ability to view Flash content.

Sunday, December 27, 2009

Jive SBS Employee on RHEL - Logrotate Warnings

While working with the social platform Jive SBS (in particular, the Employee Community) on Red Hat Enterprise Linux 5.4 x86_64 I came across an issue with the system's logrotate configuration.

The issue only became noticeable when I configured the host system to redirect all email destined for the root user to my own email account. I started to receive the following messages hourly:

/etc/cron.hourly/jive-logrotate:

error: /usr/local/jive/etc/conf/logrotate.conf:54 duplicate log entry for /usr/local/jive/var/logs/joosd.out

This error is thrown by the logrotate process if a log file is defined more than once in it's configuration. The problem appears to be caused by the following two definitions in the file: /usr/local/jive/etc/conf/logrotate.conf

/usr/local/jive/var/logs/*.out {
daily
rotate 10
delaycompress
notifempty
size 1024M
copytruncate
}

/usr/local/jive/var/logs/joosd* {
daily
rotate 10
delaycompress
notifempty
size 1024M
copytruncate
}


So, the problem is caused by the two definitions that both match the file that logrotate is complaining about: /usr/local/jive/var/logs/joosd.out

In order to fix the issue, I opened the file /usr/local/jive/etc/conf/logrotate.conf and simply changed the second definition mentioned above to the following:

/usr/local/jive/var/logs/joosd.log {
daily
rotate 10
delaycompress
notifempty
size 1024M
copytruncate
}


After the next run of logrotate, I no longer recieved complains about the log file joosd.out, however, I now received a similar warning for the file jdcd.out instead! Reading the error messages, the offending logrotate definitions were now:

/usr/local/jive/var/logs/*.out {
daily
rotate 10
delaycompress
notifempty
size 1024M
copytruncate
}

/usr/local/jive/var/logs/jdcd* {
daily
rotate 10
delaycompress
notifempty
size 1024M
copytruncate
}


While investigating in the Jive log directory (/usr/local/jive/var/logs) which log file(s) the second definition matched, I discovered there are no other files that would match this definition, apart from jdcd.out. As this file is picked up by the first definition above (/usr/local/jive/var/logs/*.out), this would suggest that this particular logrotate definition is completely redundant.

I commented out the entire second definition (/usr/local/jive/var/logs/jdcd*) and manually ran the logrotate process again. Sure enough, no errors were output by the task and it completed successfully.

While working through this issue, I noticed that there's a bunch of other log files that are not being rotated:


  • dbanalyze.log

  • dbbackup.log

  • dbinit.log

  • dbmaint.log

  • sbs.log

  • sbs-container.log

  • sbs-docverse.log

  • sbs-latency.log

  • sbs-pageview.log

  • sbs-profiling.log

  • sbs-session.log



They don't appear to have much data in them to start with, but I wonder if they have the capacity to grow quite large during the normal use of the system? To try and get some clarification on these issues, I've created a post on the Jive community forums:

http://www.jivesoftware.com/jivespace/message/317110

Currently, I've had no replies (apart from myself, once I had confirmed that the issue is also present on the i386 build of the software), but once I do get a response, I'll update this post.

Update: One of the guys at Jive responded to my post saying that the latest release of the software (4.0.2) no longer has this issue.