FreePIE official thread

Post by **mxxmmxxm** » Sun Jun 10, 2012 8:42 pm

Has anyone tested the Wiimote button driver with a Wiimote Plus yet (The one that calls itself RVL-CNT-01-TR, that started coming out last winter)?

GlovePIE has recently decided to stop working entirely on my system, and given the.... difficulties of its creator and Vuzix hardware, I'd love to switch over if it's worth setting up a build environment locally.

Post by **brantlew** » Sun Jun 10, 2012 10:05 pm

I have some old Wiimotes from the first run of the Wii and also some Wiimote Pluses that I bought about 6 months ago, and they both work fine. Only button support right now though. No IR camera or motion. FreePIE pretty much came abouty as a response to GlovePIE incompatibility with Vuzix, and that is one of the best uses for it. Let me know if you need scripts for Vuzix and Wiimote integration.

Post by **CyberVillain** » Mon Jun 11, 2012 12:39 am

You do not need dev env if you just want to use FreePIE normally, the current binary that can be downloaded does not have WiiMote support though, I was hoping to have time to add the Intellisense feature before next binary release, but maybe I have to release a new binary before that.

Post by **CyberVillain** » Mon Jun 11, 2012 12:46 am

btw Brantlew, let me know if you have any problems getting Git to work. I'm also using MSBuild for the new build process (To extract Git revisionnumber into the assembly info etc) it looks like MSBuild should work with express, let me know if it doesnt

Post by **Neil** » Mon Jun 11, 2012 3:25 pm

Just wanted to add that now you have a dedicated forum, there is no need to have a run-on thread. You can break things up now!

Regards,
Neil

Post by **profvr** » Mon Jul 02, 2012 5:12 pm

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).

Post by **brantlew** » Mon Jul 02, 2012 6:34 pm

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.

Post by **CyberVillain** » Tue Jul 03, 2012 2:00 am

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

Post by **profvr** » Tue Jul 03, 2012 2:09 pm

brantlew wrote: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.

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.

Post by **CyberVillain** » Thu Jul 12, 2012 6:07 pm

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

Post by **brantlew** » Thu Jul 12, 2012 7:08 pm

Excellent. A new binary was definitely needed.

Post by **CyberVillain** » Sat Jul 14, 2012 10:03 am

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

Post by **CyberVillain** » Mon Jul 30, 2012 9:08 am

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.

Post by **brantlew** » Mon Jul 30, 2012 9:16 am

Cool, thanks CV.

Post by **CyberVillain** » Mon Jul 30, 2012 9:45 am

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

Post by **Fayt3X** » Mon Jul 30, 2012 9:54 am

CyberVillain wrote:

Ooo, I like this one.

Post by **brantlew** » Mon Jul 30, 2012 10:13 am

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)

Post by **CyberVillain** » Mon Jul 30, 2012 11:18 am

brantlew wrote: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

Post by **brantlew** » Mon Jul 30, 2012 11:52 am

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.

Post by **CyberVillain** » Tue Jul 31, 2012 11:27 am

What do you guys think?

Post by **brantlew** » Tue Jul 31, 2012 11:42 am

I like.

Post by **cybereality** » Tue Jul 31, 2012 7:20 pm

Cool.

Post by **MSat** » Thu Sep 13, 2012 6:27 pm

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.

Post by **brantlew** » Thu Sep 13, 2012 8:27 pm

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.

Post by **cybereality** » Thu Sep 13, 2012 8:31 pm

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.

Post by **MSat** » Thu Sep 13, 2012 10:12 pm

brantlew wrote: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.

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.

brantlew wrote: 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.

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!

Post by **brantlew** » Thu Sep 13, 2012 11:00 pm

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.

Post by **MSat** » Fri Sep 14, 2012 7:02 pm

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?

Post by **brantlew** » Fri Sep 14, 2012 7:10 pm

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

Post by **CyberVillain** » Sat Sep 15, 2012 8:12 am

MSat wrote: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?

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

Post by **MSat** » Sat Sep 15, 2012 6:37 pm

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?

Post by **brantlew** » Sun Sep 16, 2012 11:23 am

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.

Post by **CyberVillain** » Mon Sep 17, 2012 1:19 am

brantlew wrote: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

Post by **MSat** » Mon Sep 17, 2012 3:08 pm

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?

Post by **brantlew** » Mon Sep 17, 2012 3:12 pm

@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

Post by **MSat** » Mon Sep 17, 2012 3:43 pm

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.

Post by **brantlew** » Mon Sep 17, 2012 3:54 pm

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.

Post by **MSat** » Mon Sep 17, 2012 5:53 pm

brantlew wrote: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

Post by **CyberVillain** » Tue Sep 18, 2012 1:29 am

MSat wrote:
brantlew wrote: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

Post by **space123321** » Tue Sep 18, 2012 2:18 pm

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?