Hi, this is an interesting project but have you looked at existing tracker drivers libraries that are out there? Whilst it doesn't deal with the output emulation, I would look at Virtual Reality Peripheral Network (VRPN) from University North Carolina Chapel-Hill for the input side. Its public domain and supports practically every tracker out there including Freespace, Wiimote, etc.; most companies developing trackers release software for it or someone has added it at some point (VRPN has a very long history!). Another nice feature is you can run your tracker over the network (something we do a lot of in our lab at least for testing; the trackers are plugged in to well-known machines where the drivers run very reliably, and client software connects over the network ).

Whilst adding specific driver support to FreePIE is probably quite easy, and dealing with VRPN initially would be tougher, you would get access to a lot of devices and a lot of configuration options for them.

There would still be lots to do in FreePIE, such as calibrating coordinate systems, filtering, range detection, etc.

I am looking to see if we can release some of our locally tracker filtering code, it will deal well with the head-tracked scenario. We do have a freespace tracker already and have used it in HMD demos, butwe have lots of trackers in our lab so we tend to use trackers with absolute position tracking for HMD demos, so haven't focused on tracker filtering specifically for the freespace (until now).

We talked a bit about implementing this as a VRPN node in the beginning. I remember thinking that the VRPN interface seemed to have a lot of extra baggage, I was concerned about the network overhead, and frankly - the code looked a bit too academic. But there were no real plans made or design spec'd out. It just sort of took off and evolved on its own as open source projects do. There are still long range plans to implement a VRPN interface into the utility. There is nothing stopping it from acting as a VRPN node. Personally I think it should preserve its kernel as a tight local interface. Actually even tighter than it is now - ideally as a linkable C dll that would allow third party apps to link directly to it without compilation or network connections.

Hi. profvr
We decided that we could create a VRPN plugin down the road and jack that into FreePIE like any other I/O plugin since we still needed emulation.
If you would like to do it I would gladly pull that into the Master branch on Github

Regards, Anders

edit: That filtering stuff sounds neat, we really need better filters ,I just did a quick and dirty one to have something

No argument about it not having some complexity as it does a lot of different things beyond just reading devices (logging and replay is one I've used a lot to debug). However there are good features in there which are valuable downstream. E.G. I think I recall you can run client and server in one process, which has the effect of just cleanly separating off the device thread and should have no latency overhead on a single machine.

Uploaded new binary, lots of changes, code completion, Hillcrest Freespace support, Property syntax now supported etc!

Excellent. A new binary was definitely needed.

Found a bug causing a problem were you couldnt open scripts from disk, fixed and new binary uploaded

Just uploaded a new binary, nothing major just some small changes to the Code completion code, the biggest change is that we now have a installer. It should take care of VC++ Runtime dependencies etc.

Cool, thanks CV.

Thanks Brantlew,

We need a app icon boys, Neil, you talked about you could whip something up?

We can also use ree ones at the icon finder website, like these

Ooo, I like this one.

I kinda like this one. Simple and generic. Joysticks are sort of universally understood as a control mechanism.




(either that or some sort of stylized pie)

More of a cake though

Maybe if the cherry on top was a joystick - that would be sort of cute. But I'm no graphic artist. I think the plain joystick works better.

What do you guys think?

I like.

Cool.

Thanks for mentioning FreePIE in the nthusim hmd thread, brantlew - I had been completely overlooking it.

I'm not much of a programmer, but I think I might have some insight in avoiding some of the obstacles that FreePIE is running into. Hopefully you'll be willing to implement a fix

I don't think the sensors are the only ones causing drift. In fact, I wouldn't be surprised if their effects were just a small fraction of the issue. You can't emulate a mouse by just piping the tracker's delta values into the mouse emulator. Consider this case: In a FPS, the vertical viewing limit is +/-90 degrees from center. If you take your mouse and point the player's view at the limit looking up, all further mouse delta values are null. You can keep adding delta values, but the view won't change, yet as soon as you move the mouse to look down, the view changes - you don't have to make up for all the wasted positive delta values. So if you don't account for this, you will have immediately introduced drift. This perfectly explains why CyberVillain didn't have this issue when he disabled the vertical limiting in UDK. What you have to do is have a profile for the game that decalres minimum/maximum vertical viewing limits. So you have to be tracking some of your own delta values in FreePIE to account for for movements that extend outside of the game's limits.

As I've mentioned in the nthusim hmd thread, it might be nice to emulate a joystick so that you can have pretty stable tracking in games that have a "look spring" option - at least for vertical tracking (not good for horizontal tracking because it continually moves player orientation until the joystick is centered.

I'm sure there are still some other issues, but I really think this is the biggie.

Well that's true, and it can get even more complicated than that because tracker angles naturally hit a discontinuity at that high angle and then "flip" orientations so that the yaw spins 180 and the pitch starts moving back down towards 0. But the angles are all pretty crazy at the top and can create havok on the player view - even in an absolute coordinates system. But I think generally this is something you can handle heuristically in the script instead of the tracker interface.

But when we are talking about drift we are generally talking about the sensor angles becoming offset from their starting orientation over time. This is truly at the sensor and has to be fixed with some type of calibration. Another kind of drift is specific to mouse emulation and has to do with the game poller de-synchronizing with the mouse delta stream. If the poller misses a mouse update or two, then that also creates drift.

The drift isn't so much of an issue if you are using a gun controller, or mouse or whatever. Something else to control the view in addition to the head-tracker. Then its easy to re-adjust to the proper angle.

Maybe you can avoid issues at that the extreme ends of sensor input, by placing sensor angle limits a bit lower than the game's limits. I totally agree that it should be programmable via script (cool!) than somehow hard-coded in the program.




At least drift at the sensor level can be corrected fairly quickly in-game. But if you haven't been calculating the estimated vertical angle in the game, it would be somewhat more tedious to recalibrate (at least if you don't have a joystick). I haven't paid any attention to see if games still have re-centering as a hot key option - would be very useful.

I was thinking about potential polling issues. I'm assuming there's a buffer on the emulator side, so I don't know how the poller would miss an update (unless windows is doing some funny business in-between). Unless the buffer overflows, I can't see that there would be anything except some jitter. But again, if most games still feature re-centering, it's not as big a deal.


Having headtracking on my mind when I came across this thread, I walked in with tunnel vision - totally neglecting the big picture and spirit of FreePIE. I appreciate the work and effort that has been put into it, and am looking forward to trying it out with my Rift

Cheers!

Thanks. I've been neglecting the project, but I'm going to put some effort into it in November in preparation for all the custom support that people will want for the Rift. In particular I think Wiimote IR, Hydra, and Oculus SDK are all must-haves for the Rift release.

I think I might try poking and prodding in the code myself. And hopefully I might even be a little useful

Quick question - do you know if I can compile the code with the free version of VS?

Yes, I use VC# Express 2010. It complains when you load it, but it compiles fine.

the test projects will be excluded so just make sure you do not include the .sln in the pull request if you make one

I now realize everything I mentioned could indeed be done in script, I'll try tackling it there. That still leaves me wondering about mouse polling misses. Is there a buffer between the emulator and windows api mouse calls? Is there any reason to worry about mouse updates from the emulator being dropped?

The behavior would be different on different games and different computers. There is a small system buffer available but it's up to the developer to utilize it properly. Ideally the game engine would have a dedicated polling thread that was given high priority and managed buffered mouse input. Under these circumstances it's hard to miss a mouse update.

Most games I've seen the source for, poll the input before each render though. Meaning you get the same input poll frequency as the screen sync

Hmm,.. So it sounds like if you're updating the mouse deltas substantially faster than the rate the game polls at, you would eventually overflow any buffer. Is there any way of detecting when a game polls for the mouse data, and not send off the values until then, or right after?

@MSat: Not that I am aware of. But it's a good argument for having a configurable update rate in FreePIE.

http://www.mtbs3d.com/phpBB/viewtopic.php?f=139&t=15354

Interesting thread! I'm always late to the party


I was thinking something like this could work:


mouse.DeltaX = mouse.GetDeltaX + Xvar

Of course, the GetDeltaX function is made up. The thinking is FreePIE makes a call to the OS API to get the mouse values and clears the buffer. It then updates the deltas and sends it back to mouse.DeltaX.

I don't think it's a global shared buffer. I think each mouse signal broadcasts a mouse message to separate queues for each listening process.

I wish you weren't right, but I did some reading and I see what you mean. Having multiple separate mouse instances is an unfortunate feature. One thing I can't find out is if the DirectInput buffer accumulates all the deltas in one value - if so, that could alleviate the issue. I wonder if there's an easy way to get the frame rate from the GPU? Setting a maximum update rate works, but it would be nice if it could do it automagically

Its not that easy actually, you need to access the real time clock, and I'm pretty sure the game wont like that... But I havent had time to test this out

Is there step by step instructions on how to get freepie running? I have downloaded the official version, however I do not have any lua scripts present?

FRAPS (http://www.fraps.com/) is a benchmark tool that you run on DX or OpenGL games. One of the main features is that it can display the FPS. So it's definitely possible, but I admit that I have no idea how difficult it is.

While I have no conclusive proof, I get the impression that deltas do indeed get accumulated in the various windows API's mouse delta variables, and then cleared on read (unless the application requested absolute position). The only buffers - in DierctInput at least - appear to be for events such as keyboard/mouse button presses. So I would have to imagine Windows isn't just dumping mouse deltas. So, "assumptive" tracking is preserved.

One of the problems I can see with emulating the mouse without feedback from the game is the possible discontinuousness of tracking when switching from say first-person action view, to something like an in-game menu. One solution might be to intercept the keyboard/game pad's menu buttons, so that you can save the current tracking state, and start a new one. Then when it's closed, load the previous state and correct the tracking if necessary. Though this might be difficult if not impossible with games utilizing complex in-game menus.

There are none included, look here for some example ones

viewtopic.php?f=139&t=15052

just to test it out you could just do


its should print the mouse delta in teh watch window

Perfect - was able to get the mouse delta in the watch window

It was mentioned that the Iphone code was implemented into the build... do I still download the lua files seperately.

Thanks again!

@space123321: I don't currently have any example scripts up for the iPhone, but I will post one this evening. Please note that you must also purchase the Sensor Data app for iPhone to get this working. Also note that the iPhone has a significant stutter in it's tracking feed and may not be to your liking.

http://itunes.apple.com/us/app/sensor-data/id397619802?mt=8

Thanks again all!