libfreespace integration into source engine

[adoral84]

I'm currently working on integrating my hillcrest labs tracker to give more accurate 3dof tracking for source games with my HMZ (I may add some translation mapping later). Once I get things sorted out I'll post the source and mods online.

Unforunately the libfreespace apis aren't documented all that well and I've run into a couple of suprises, and I'm hoping someone has already sorted out some of these issues. I have all of the pieces in place at this point but when I try to run the source mod with any call to the freespace apis I get the dreaded "Could not load library client". Any input would be much appreciated.

[zalo]

Thanks for doing this! I have no experience whatsoever with C++, but when I get errors like that, I make sure that the .dll is everywhere so that it has no problem finding it.

The libfreespace .dll is in your mod's bin folder, right?

[brantlew]

Glad you're going this. I was wondering when someone would plug into that awesome Source SDK. Please keep us informed with how it works and how much control you are able to achieve over the camera.

As far as your problem goes. I don't have many suggestions other than the obvious...make sure your dll is in the path (preferably the local run directory). Make sure you don't have a 32/64 bit incompatibility issue between your mod and libfreespace. Lastly, make sure ALL the dependencies are in your path. libfreespace may be trying and failing to load one of its dependencies. (As always... dumpbin.exe is your friend)

PS. If you don't mind, could you also test out if the Source SDK translation values work. Obviously you want have a sensor for that, but you can just simulate it with up/down keys or mouse or something like that. I am curious whether they actually allow you to have analog up/down, left/right or whether it's just an unimplemented feature of the API.

[adoral84]

Thanks both of your feedback, turns out visual studio wasn't copying the freespace dll like I expected and I was too busy looking for a bigger issue:) The basic 3dof headtracking was pretty simple, actually stumbled across one of your posts Brantlew that saved me some inevitable hair-pulling about the misleading examples around freespace_isNewDevice(..).

Glad you're going this. I was wondering when someone would plug into that awesome Source SDK. Please keep us informed with how it works and how much control you are able to achieve over the camera.

The source engine seems like such a great playground for all of the great new vr hardware that's been released or in the works recently (basically I'm killing time till my rift dev kit comes in ). Basic 3dof camera control in the source sdk is super straight forward, next on my list is playing with at least some simple translation models, not for major movement but ideally at least to capture some of the subtle parallax effects. If that doesn't work I'll at least follow Carmack's approach and add a basic head/neck tilt transform.

My ultimate goal is to have this accurate head tracking model with independent gun tracking via a wiimote + motionplus. I've done mouse emulated head-only or gun-only tracking and they both have their upsides, but I think this could be a big step toward a next level of immersion. I'm using the video below as a concept for how I'd like the gun tracking to work within the frame of a headtracked viewpoint. I just wish I could get a hold of this guy's source :/

http://www.youtube.com/watch?v=pFa-Dusew0U

[brantlew]

The source engine seems like such a great playground for all of the great new vr hardware that's been released or in the works recently (basically I'm killing time till my rift dev kit comes in ).

Agreed, and if I wasn't busy with another project I would have done it. So I've been shouting from the rooftops in several threads hoping that someone would pick this up and run with it. I would love to get a-hold of your mod once you're done to use as a VR motion test-bed.

[adoral84]

PS. If you don't mind, could you also test out if the Source SDK translation values work. Obviously you want have a sensor for that, but you can just simulate it with up/down keys or mouse or something like that. I am curious whether they actually allow you to have analog up/down, left/right or whether it's just an unimplemented feature of the API.

It's pretty straight forward to do things like analog crouching or accurate lean translation using Player.SetViewOffset assuming you had the sensors worked out. I was dabbling with the accelerometer values from the tracker but haven't been able to come up with anything usable yet. Having the roll and 1 to 1 head tracking is definitely nice though. I'll post a video later this week when I get my longer usb cable, it's a bit odd being tethered to the pc with a 3ft usb cable.

[brantlew]

Cool. Good to have confirmation that the API actually does what it's supposed to. I need to read through the SDK just to see how they handle things like character bounding box and/or skeleton when using the API in this way. Valve has thought about this kind of thing a lot more than other companies and it would be instructive to see their design choices. I'm actually hoping that the Valve SDK forms the basis of (or at least pollinates) the Oculus SDK. That would be MAJOR if game developers, by supporting an Oculus VR platform, not only starting handling absolute head orientation but head position, body orientation, and character motion as well. Forward compatibility with future VR input devices and techniques would be awesome.

[adoral84]

There's a solid implementation of applying head tracking via faceapi that handles a lot of the bounding checks etc if you're curious what it could look like. I just stumbled across it last night so I've yet to read through it all but it looks good from what I've seen so far. https://github.com/torbensko/HAL

After tinkering yesterday on using the accelerometer values for translation and getting nowhere beyond simulating epilepsy I'm going to go a different direction. I've got a trackir cam that I think I can get pretty good results from. My setup already involves running the wires down from a hook on the ceiling to allow more free rotation without getting tripped up, so it wouldn't be a stretch to put the trackir system up above the player facing down tracking the head translations.

[brantlew]

After tinkering yesterday on using the accelerometer values for translation and getting nowhere beyond simulating epilepsy I'm going to go a different direction.

Yeah, don't waste your time heading down the dead-end path of trying to get accurate translation values from accelerometers. Just save yourself the headache and go with optical.

Hey, just out of curiosity do you notice the Hillcrest sensor anomalies reported in this thread?
http://www.mtbs3d.com/phpBB/viewtopic.php?f=140&t=15282

[brantlew]

@adoral84: Have you considered using a Hydra for translation data? I don't have one but they are supposed to be pretty good 6DOF sensors. I think the angle gets off sometimes, but if so you could always use the Hillcrest for orientation and the Hydra for translation. The biggest problem is that they have cables so you are limited to facing forward.

[adoral84]

I've looked at the hydra briefly, definitely some cool tech (I'll probably end up buying it randomly) but my main focus is on a 360deg standing setup right now and from what I read it's not a great fit for that. I don't know much about the setup, but tracking relative controller positions to the player's body could also be useful if the base could be somehow fitted to them.

So I've got the head tracking all set up with some (subtle) head/neck translation modeling. I still need to smooth out the realignment jumps from the hillcrest tracker but aside from that I think it's all basically good enough for some initial play. I'd swear the tracker is jumping more today than it was a day ago, but it problem just seems worse because everything else is pretty spot on now. If you nail down something let me know, otherwise I'll dig in on that this weekend. I can also zip up the dlls needed to run hl2 with it later this week if you want.

[brantlew]

@adoral84: I posted some code that helps with the tracker jumps. It's not perfect but it does improve the experience a good bit. Yeah, I would like to check out the HL2 mod when you think it's ready. So are you just doing some gesture-triggered animations using the accelerometers? How did that work out?

[adoral84]

@adoral84: I posted some code that helps with the tracker jumps. It's not perfect but it does improve the experience a good bit. Yeah, I would like to check out the HL2 mod when you think it's ready. So are you just doing some gesture-triggered animations using the accelerometers? How did that work out?

Great, thanks! I'll see if I can get that integrated before I send anything out.

Right now the movement is just some subtle translation to take into account the path your eyes take when you tilt your head at the neck. I tried to keep it subtle for now, it's just a placeholder till I can work in the optical tracking anyhow. In the past my experiments triggering movements based on gestures tend to be more jarring than immersive because they never match up quite right. The head roll translations are the same way, if you bend at the waste they are too small but I think for now the amounts are decent for most cases.

[brantlew]

The head roll translations are the same way, if you bend at the waste they are too small but I think for now the amounts are decent for most cases.

The Carmack interpretation had it rotating around the nose which I found to be awkward. Rotation around the chin seems more natural. There might be some fruitful results in monitoring the ratio between the acceleration component and the rotational component. You "might" be able to distinguish between just a head roll and a bend at the waist - assuming that head rolls have a proportionally larger rotational value. Probably with some false positives, but it could be interesting still...

[adoral84]

Yeah I would think rotating around the nose wouldn't be ideal, did that include pivoting on yaw? I'm basically using a point at about collar bone height to make it a bit more exaggerated while I play, but it's adjustable via config/console.

[love2scoot]

Man, am I looking forward to progress here! Exciting stuff.

Do I have this right?:

The sensor reads that you are doing here and in the aforementioned Hillcrest/Rift tracker thread are being read directly from the tracker (requiring a manual switch in the driver) which is producing the raw positional data output through libfreespace. This data is then integrated into the source engine using the hooks provided in the SDK. This allows tracking using real positional data, and not just a move delta (like mouse tracking). The upside is that any samples that are skipped / missed / etc do not lead to drift for in-game views. The downside is that using this data in its current form causes visual jumps as the board self-calibrates to accommodate a better guess as to current position.

So while the mouse emulation option using FreePIE works for the mouse motion driver approach, this “raw data” approach will seamlessly integrate into the source engine itself. Is this correct?

One other item, Valve mentions here: https://developer.valvesoftware.com/wik ... Source_SDK that a few other games (including my target platform, Portal2) have their own Source SDK / Authoring Tools. Will the mod that you are working on be compatible with those SDKs as well?

[brantlew]

@love2scoot: You pretty much got the gist of it. A couple of details:

- Currently the FreePIE mouse emulator and the native tracker->Valve interface both use the same method of getting data from the tracker, so the calibration "jumps" will appear in both implementations.

- The current smooth code alleviates the worst of it however. I've used it myself in an HMD (via mouse emulation) and it's not so bad.

- One crucial thing you missed is that the tracker->Valve interface will allow for camera rolls as well which is something you cannot get with mouse emulation and adds an extra little bit of realism.

[adoral84]

I've got an initial build of the mod with all the half-life 2 levels. I played through about a 3rd of the game and so far haven't run into any breaking issues (a few oddities here and there).

http://dl.dropbox.com/u/2742162/Half-Li ... ife-vr.zip

You should be able to unzip that into your {steam-location}/steamapps/sourcemods folder, you might have to restart steam but then it should be available as "Half-Life VR" in your games list. So one caveat at this point, the expected orientation of the tracker on the mount is currently circuits on top with the usb connection to the left. I'll can drop some updated dlls that allow you to reconfigure that if anyone needs it pretty quickly.

I'm currently using a psmove sharpshooter with a combination of MotionInJoy with xbox360 controller emulation for the navigator and glovepie to run the ps move buttons. Having the analog movement support (and simplified weapons menus etc) really helped IMO, and this was pretty straight forward aside from finding a bluetooth adapter that worked with MiJ.

This allows tracking using real positional data, and not just a move delta (like mouse tracking). The upside is that any samples that are skipped / missed / etc do not lead to drift for in-game views. The downside is that using this data in its current form causes visual jumps as the board self-calibrates to accommodate a better guess as to current position.

Yep, looking in a particular direction in the real world will consistently look in the same direction in the game world on all 3 axes, and the rotations are absolute values, not deltas. I'm using the same smoothing code that brantlew is using in freepie (thanks again brantlew:) ), but to me it's a bit more jarring with the absolute headtracking, so that's definitely on top of my list of things that need to be improved. Just to be clear, this is angular position only at this point, I've not integrated any of the translation values from the tracker because of the inaccuracies in the readings. That said, I may revisit this once some of the more immediate improvements are in place.

One other item, Valve mentions here: https://developer.valvesoftware.com/wik ... Source_SDK that a few other games (including my target platform, Portal2) have their own Source SDK / Authoring Tools. Will the mod that you are working on be compatible with those SDKs as well?

Not exactly, I'll have to port the code over to the SDK specifically for Portal2 but I'm hoping it'll be relatively simple to plug the code in. I imagine Portal2 would be pretty awesome though.

Aside from tweaks and fixes here my next project will be independent weapon aiming, my brain is just too hard-wired to try to aim with the sharpshooter when I'm holding it. I'd rather use a wiimote since I already have one rather than buy another freespace, does anyone know of a solid wiimote driver library by chance?

[cybereality]

does anyone know of a solid wiimote driver library by chance?

I messed around with WiiYourself a bit, and I eventually got it somewhat working but it seemed unreliable.

[brantlew]

Excellent work adoral84! I'll definitely give it a spin sometime this weekend. What are you doing for yaw drift resets (or are you spinning 360 where it doesn't matter?) Also, my tracker auto-calibrates its orientation so if I flip it upside down or sideways, turning it to the right is always clockwise yaw. Does yours not do that?

Finally, you gave all the technicals, but what about the subjectives? What's it like? It is noticeably better than mouse emulation? Does the head roll add to the immersion? Oh and what HMD are you using?


PS. I've only used wiimotelib, but it's worked for me so far. You will need the latest beta release for gyro support (Wiimote+)

[adoral84]

What are you doing for yaw drift resets (or are you spinning 360 where it doesn't matter?) Also, my tracker auto-calibrates its orientation so if I flip it upside down or sideways, turning it to the right is always clockwise yaw. Does yours not do that?

No special calibration yet for inverting the tracker, and I'm currently not doing anything special for yaw offsets/recentering since I'm turning 360 degrees. I realize a lot of people can't or don't want to always turn all the way around so I'm definitely be adding that before long, let's call this an alpha . Unfortunately I spent most of my time on several variations of smoothing, none of which stuck.

Finally, you gave all the technicals, but what about the subjectives? What's it like? It is noticeably better than mouse emulation? Does the head roll add to the immersion? Oh and what HMD are you using?

Here are a couple of things that've jumped out so far while playing for a few hours.

- I don't get nearly as disoriented when rapidly turning about as I did with mouse emulation. This is especially noticeable when something like a headcrab or manhack gets up close and you have to quickly pivot, or when going through narrow twisty hallways. I think the absolute orientation that consistently maps your position without having to realign really helps.

- IMO the ability to tilt my head definitely adds to the immersion (more so when I'm not consciously thinking "I should tilt my head here" to test it ), but it's not super useful tactically without more translation associated with the lean. I can either exaggerate the horizontal translation associated with head roll for now or just wait until I work something out with optical trackers etc.

- The recalibrations are the one thing from what I've seen so far. I think this is definitely something that can improve, especially if we can get a hold of that faster firmware.

I think it's definitely more immersive than mouse emulation, and I think there's a lot more that can be done. Overall getting in and playing with it for a few hours has me even more excited about the potential. It's also a lot of fun to play a game that's nearly a decade old and feel like it's the more immersive than all the latest AAA standard games.

[brantlew]

Hey, I wanted to know if you would consider supporting this as a hookable and/or FreePIE-friendly mod?

When I first got in VR research, I looked around for a test platform that I could use for motion R&D. Something that I didn't have to put much effort into, but more fun that just walking around a boring infinite-grid that I could whip up in Unity or OpenGL. Something with some content that would make the experience fun and compelling. Well I came up empty handed. So when I saw the Valve SDK that was the first thing that popped in my head - this could be a VR test platform.

So the idea is that instead of just makeing a specific libfreespace HL2 mod. You would put some type of interface - whether it was a socket that pulled motion data off the network, or maybe you would load a swappable dll that had generic calls that a third party could implement, or whatever... But the result would be that you would query a generic interface for orientation, position, etc, and third party tools could be used to supply the data. So for example, FreePIE would implement your interface and then instantly people could plug in and control HL2 with SparkFun, a Hillcrest, an iPhone, etc... Or they could come up with their own custom solution and plug directly into your HL2 mod.

So in the end, if somebody is fooling around with the Kinect SDK or trying come up with some exotic acoustic 6DOF tracker they can just focus on that because there would already be an existing environmental platform to test with.

Consider it.

[adoral84]

Hey, I wanted to know if you would consider supporting this as a hookable and/or FreePIE-friendly mod?

Absolutely, what you just described is exactly the solution I want to build. I've already interfaced it out in the code with a swappable dll implementation in mind, I just wanted to get a baseline working before making it generic/pluggable. Right now the interface is basically

-Init
-Destroy
-GetOrientation(pitch,roll,yaw)
-GetTranslation(x,y,z)

I think working out a standard way to communicate with the component is also important so key bindings and console commands can integrate with the custom code. If you could describe a bit more how it would hook into FreePIE that would be helpful, I've only ever used it to translate various inputs into standard inputs (buttons, mouse moves etc), not write against a specific game api.

[brantlew]

If you could describe a bit more how it would hook into FreePIE that would be helpful

I would probably do it with the same swap dll that you use for the mod. So this FreePIE "bridge" dll would have both the
- Init
- GetOrientation()
..
..

calls that you import and also some calls that FreePIE would link
- SetOrientation()
etc...

The bridge would be loaded by both the mod and by FreePIE, but in separate process spaces so you would have to communicate across process boundaries. Pick your favorite IPC method, but I'm guessing a memory mapped file might be easy.

In FreePIE a C# "plug-in" would need to written that is compatible with FreePIE and links in the bridge dll. It's not that hard, but there is a strict syntax and procedure to follow so the FreePIE script engine will know how to recognize and call the plug in. Once everything links up you can write a script like this to drive Half-Life 2 or Portal with the Sparkfun IMU.

SourceSDK.Yaw = ahrsImu.Yaw;

Here is an old page on how plugins are structured. Possibly not 100% up to date, but there are numerous code samples. C# is not exactly the ideal language for dealing with hardware and most of the GUI and engine code is meta-coding gobbledy-gook, but the plugins themselves are usually pretty straight forward to write.

https://github.com/AndersMalmgren/FreeP ... evelopment

[brantlew]

Finally pulled the mod down. Works great but my tracker is mounted differently and I didn't want to reassemble my kit so I didn't get a chance to play with the HMD. The response is great! Way better than mouse emulation which always seems a bit jittery no matter what I do. And the smoothing seems to work even better on absolutes than it does with mouse emulation. I didn't really notice the jumps, but I didn't test very long and I wasn't wearing the head-mount. I'll let you know after more testing - but so far, I think it's really good.

[CyberVillain]

What "smoothing code" are you guys referring too? Is it the built in simple filter in FreePIE, if not and if it works better then the simple filter I would love if that code can be integrated into freepie the simple filter code looks like this

Code: Select all

        public double simple(double x, double smoothing, string indexer)
        {
            if(smoothing < 0 && smoothing > 1)
                throw new ArgumentException("Smoothing must be a value between 0 and 1");

            var lastSample = x;
            if (lastSamples.ContainsKey(indexer))
                lastSample = lastSamples[indexer];

            lastSample = (lastSample*smoothing) + (x*(1 - smoothing));
            lastSamples[indexer] = lastSample;

            return lastSample;
        }

And is used from script like this

Code: Select all

yaw = filters:simple(ahrsImu.Yaw, 0.8)

Value should be between 0.0 and 1.0

Its very simple but fast

Code: Select all

lastSample = (lastSample*smoothing) + (x*(1 - smoothing));

Is yours better than this one so please integrate it in the helper class brantlew

Here is an old page on how plugins are structured. Possibly not 100% up to date, but there are numerous code samples. C# is not exactly the ideal language for dealing with hardware and most of the GUI and engine code is meta-coding gobbledy-gook, but the plugins themselves are usually pretty straight forward to write.

https://github.com/AndersMalmgren/FreeP ... evelopment

It's up to date, I updated after we introduced Property support

meta-coding gobbledy-gook!?

[adoral84]

Finally pulled the mod down. Works great but my tracker is mounted differently and I didn't want to reassemble my kit so I didn't get a chance to play with the HMD. The response is great! Way better than mouse emulation which always seems a bit jittery no matter what I do. And the smoothing seems to work even better on absolutes than it does with mouse emulation. I didn't really notice the jumps, but I didn't test very long and I wasn't wearing the head-mount. I'll let you know after more testing - but so far, I think it's really good.

Glad to here it, I'd love to find out I just have a faulty tracker. The new dlls below add console vars head_pitchaxis etc where you can change them. I also added the ability to disable roll with head_rollenabled so you can try it out with only 2dof. I just realized though that I didn't add the ability to invert each axis, so it may not do you any good though.

http://dl.dropbox.com/u/2742162/Half-Li ... Client.dll
http://dl.dropbox.com/u/2742162/Half-Li ... Server.dll

What "smoothing code" are you guys referring too? Is it the built in simple filter in FreePIE, if not and if it works better then the simple filter I would love if that code can be integrated into freepie the simple filter code looks like this

None of this is integrated into FreePIE yet but I'll plug that in directly and see if it helps. I was able to detect the recalibrations with very few false positives last night but I haven't tried to write any smoothing against it.

[CyberVillain]

None of this is integrated into FreePIE yet but I'll plug that in directly and see if it helps. I was able to detect the recalibrations with very few false positives last night but I haven't tried to write any smoothing against it.

I was refering to these lines

I'm using the same smoothing code that brantlew is using in freepie (thanks again brantlew:) )

Didnt find the code you referred to, but My guess was thats its lua code right? Not a helper method in the FreePIE API. If it does things better than the simple filter i implemeted (Basicily it takes 0.X from last sample and 1 - 0.X from new sample)

[brantlew]

@CyberVillain: I haven't checked that code in yet to FreePIE. It's specific smoothing behavior for the Hillcrest tracker beyond just simple averaging. We're still working on a good solution and when it matures, I will check it in.

http://www.mtbs3d.com/phpBB/viewtopic.php?f=140&t=15282

[CyberVillain]

Aha, its that specific, then it might fit to have it on the plugin itself?

so that Yaw, Pitch, Roll are filtered correctly, and if you want unfiltered vlues you could add

RawYaw, RawPitch, RawRoll for those that want unfiltered data.

It feels wrong to pollute the generic helper classes with a specific plugins filter thats just all

[brantlew]

@adoral84: Another request. I was looking around the Source SDK and noticed that you could affect character movement as well. That would be another nice hook to support in your mod - the ability to drive the character with a custom controller/device instead of having to use the keyboard interface, plus support for continuously variable speed.

I am a bit confused however as to how head translation and character motion are related. Are the translations limited to a small radius around the character? Are head translations the same thing as walking and actually move the character? Are Y translations the same as ducking and shorten the bounding box?


Edit: Just realized how strange it would be if head translations and character position were connected. That means if you were standing at the edge of the cliff and you leaned your head over to look down, you would fall off the cliff. I hope the SDK can properly support this scenario.

[love2scoot]

UPS finally dropped off the tracker last Friday. I spent a few hours trying out different mounting scenarios on the ST1080, I ended up with the left side on top of the HMD with the USB facing the rear and the components facing down (I’ll try to post pictures when I get a chance). This orientation works for the simple mouse emulation that the board does out of the box. In my initial testing, the mouse emulation does (correctly) flip when the board is inverted. adoral84: I’m not really clear why you went with USB facing left, did it just work better for mounting? If you went back to mouse emulation mode then roll and pitch are swapped, correct?

I also tried the setup with a couple Steam titles. First was Portal2, this was much more difficult than I had expected. Tracking certainly works well for Portals created on planes with an identical y-axis, but things get disorienting when, say, you create a portal on a wall and one on a ceiling. You are (physically) facing dead ahead, you walk through the wall portal, and now you are facing the floor as you fall from the ceiling. To center the in game view you then need to physically look up or recenter using a secondary mouse controller (very disorienting). The question is, when using absolute values for tracking, I assume the in-game view would snap from looking down to looking dead center as soon as you step through from the wall portal to the ceiling portal. This would certainly be different than the standard in-game view, but may give a more realistic feeling based on gravitational reference. I’m certainly looking forward to getting this working.

Next I tried Left4Dead2. Now, I’ve played many hours of this game and even started with a campaign that I’ve played the most, No Mercy. It took me about 3 minutes to get used to using the head tracker for mouselook and limit my mouse movements. Then, all of a sudden, the game made a pronounced jump in realism. A level I knew by rote, was starting to freak me out; I was vested. This is what I was hoping for, and makes me really look forward to additional levels allowed by absolute tracking, 360 turning, and roll. Now if only my TriDef trial period hadn’t expired before I got the tracker…

I just finished grabbing the HL2 mod you posted. Since the standard orientation of the board would be USB rear facing and either components up or down, how much work would it be to make (2) dlls, one for each orientation?

[brantlew]

@love2scoot: So did you just use the default Hillcrest mouse emulation for Portal and L4D? I guess you must have to scale the mouse in-game to calibrate the turning speed.

I think adoral mentioned that he had command line variables to configure the tracker orientation. I wonder if we could get a couple sample command lines to show how that is accomplished? (Also is this compatible with TriDef since it runs the exe for you?)

[love2scoot]

Yes, I did use the default mouse emulation. I didn't actually change the scaling at all as my primary pointing device is a trackball so the mouse speed was pretty low to start with. Vertical movement tracked correctly, but horizontal tracking was still a bit fast. In this first version I'm sitting at a desk, this actually worked better for me as I was able to react quickly and use the HMD for mouselook and rely less on the mouse for turning around. Down the line when I have the backtop setup configured the absolute positioning should work great.

I hadn't gotten the command line switches, that's great news and quite flexible. As for TriDef, I'm not sure, because my trial expired. I thought that TriDef supported command line switches, but I'm not sure if that's enough to run the mod...

Speaking of which, I'm going to go install the mod now in preparation for those orientation switches...

[love2scoot]

Installed the mod last night. I unzipped into the target folder specified ({steam-location}/steamapps/sourcemods) and did indeed need to restart Steam for the mod to show up. Additionally, Steam seemed to require downloading of HL2 (duh), the 2007 SDK, and the 2006 SDK. After starting Half Life VR, the mouse emulation of the Hillcrest tracker stopped before the menu screen (the cursor stopped responding to my head movements). The game interface would not let me start a new game, but I was able to load a saved game. Once the in-game view came up, viola!, absolute tracking worked! (Mind you I was upside-down and looking slightly at the ground based on the way I mounted the tracker). After I left the game, mouse tracking was not resumed, but a simple unplug/plug of the tracker fixed this.

I was thinking, if configuring the attitude of the tracker is just a simple matrix addition on the backend, the ideal would be to have the tracker auto configure for gravity. This has two major advantages: 1) there would be no need to maintain different configurations for the physical attitude of the tracker 2) mounting the tracker to an HMD could be done in an arbitrary fashion. Some work would need to be done on configuring pitch vs roll, but this would lend flexibility and simplicity to mounting /configuring the tracker. This approach, however, is more like a stage 2; in the short term a configurable tracker attitude command line switch would be awesome.

[adoral84]

Wow, apologies guys, I never got any notifications that there were updates to this thread...

This last weekend I added support for multiple trackers, with one being for head and second controlling the weapon orientation. Initially the experience was disorienting at best because the origins for the view models are close to the center of the screen rather than the center of the weapon where the tracker is actually mounted. I haven't completely polished it up but I was able to correct this enough yesterday to convince myself that this will actually work really well after another round of tweaks. Some cool things that just fell into place, tilting your head to the right like your aiming down the sites actually aims down the sites which is pretty awesome. The pitch and roll between the two sensors stays locked in really well, but the yaw does tend to drift occasionally so I added a recenter weapon command that I bound to my gun which works well enough for now, later I'll probably try to make a more fancy auto recalibration.

Oh and the recalibration jolt issues I was having are much less severe on my new tracker, I'm going to see if I can get a replacement for my original tracker, hopefully HillCrest Labs is good about this sort of thing.

@adoral84: Another request. I was looking around the Source SDK and noticed that you could affect character movement as well. That would be another nice hook to support in your mod - the ability to drive the character with a custom controller/device instead of having to use the keyboard interface, plus support for continuously variable speed.

I am a bit confused however as to how head translation and character motion are related. Are the translations limited to a small radius around the character? Are head translations the same thing as walking and actually move the character? Are Y translations the same as ducking and shorten the bounding box?

Edit: Just realized how strange it would be if head translations and character position were connected. That means if you were standing at the edge of the cliff and you leaned your head over to look down, you would fall off the cliff. I hope the SDK can properly support this scenario.

@brantlew - So you can translate the view in two ways, by just moving the camera which doesn't actually "move" the player or actually registering player moves. For the basic neck modeling I'm doing I'm just using the first model because the movements are so subtle, but it doesn't update the bounding boxes for the head or anything. That said there is no reason not to also include hooks to send actual player movements. I haven't done analog ducking but my plan would be just moving the view up and down (which is what actual ducking does) and switching between the duck mode's bounding boxes at a certain threshold. This is mostly because I'm working on single player stuff for now, but once I get the core of this working, porting it to a competitive online game like CS:S would obviously require a lot more finesse.

...I hadn't gotten the command line switches, that's great news and quite flexible. As for TriDef, I'm not sure, because my trial expired. I thought that TriDef supported command line switches, but I'm not sure if that's enough to run the mod... Speaking of which, I'm going to go install the mod now in preparation for those orientation switches...

These are in game console variables (you can open it by pressing ~) so they shouldn't conflict with TriDef, and once you figure out your setup you can add the same entries you'd type into the console to the autoexe.cfg file in the mod's directory so they automatically set every time you launch the game. Check out the sections here on config files http://www.tweakguides.com/HL2_7.html I really like your solution of autodetecting at least up/down correctly, I'm just trying to take the shortest path to proving out the mechanisms and then I'll go back and add some polish.

The variables themselves are head_pitchaxis 0 (It's something like that, the console has autocomplete and I'm not at my computer with the code:) but the value needs to be between 0-2). And like love2scoot mentioned, currently the "New Game" option on the main menu doesn't work, but you can load the first level by opening the console and typing "map d1_train_01" (again, might not have that exact but hopefully that's close enough for typeahead).

[brantlew]

@adoral84: I found the performance of the Hillcrest package (calibrations & yaw drift) to be totally unacceptable. My guess is that since it's just a reference design the firmware is not very good. I would think that for weapon aiming in particular, it would become a problem. I have high hopes for the Sparkfun that I should be receiving today.

[love2scoot]

Re: Console Commands:
I remember doing something similar way back in the early Quake days. Thanks for the link, I'll fool around with it. To clarify, the head_pitchaxis variable will change which in game axis responds to a specific axis of the Hillcrest tracker? Will this also change the inversion (since I have the component side of the board face down on the tracker)?

[love2scoot]

Well the map command works, but I can't find anything like the head_pitchaxis command. After some digging I found the helpful "find" console command, and tried the following:

find angle
find pitch
find head
find track
find axis

None of the results look promising. Any suggestions?

[love2scoot]

Any chance you have the exact console command handy? I'd really like to get this working.