Nice that it works better. Since you can set the pitch and yaw from code isnt there wanyway to pass the values from FreePIE to UDK? Maybe with the memory mapped file in windows?

You own a 3D printer? I envy you!

Most definitely and this can be done by binding a DLL file to UDK. But since time is of the essence and DLL coding is not my strong point I am forced to do it this way. I will however continue to work on this project once it's officially done. Simply because it would be an awesome (and relatively cheap) way for others to use the Razor and FreePIE as a headtracker in UDK. Perhaps if you're willing and have the time to spare, it might be interesting for you to integrate this with UDK and it's DLL binding functions?


I wish! I just have real easy access to one. Our school invested in one Won't be able to post any pictures today though as the guy who runs the shop and printer didn't have time this morning. Will keep you posted on this though.

By the way, did you know FreePIE and the Razor IMU plugin just saved me from redoing my semester? I put so much effort in DLL coding research, but almost gave up until I came across the Mean to be Seen forum, and specifically a couple of your threads. So again, THANK YOU.

Sorry, dont have the time to learn their engine, but if you can import any kind of dll you could use the Freetrack client dll and send Freetrack commands from FreePIE.

Glad I could help, where can I send the consultant invoice?

Haha, well, you can count on a donation when all this is over, that's for sure!

Wiimote Button Support

I added basic button support for multiple wiimotes. The wiimotes must be connected via blue-tooth before running a script. Blue-tooth connection is tricky. First you must click both 1 and 2 buttons on wiimote until the LED's blink. Then go through the Windows blue-tooth connection wizards (no pass-code) and wait until you see a taskbar popup that says the device has been successfully connected. Then you must quickly run your script the first time to connect the wiimotes. If you don't complete all this before the Wiimotes stop blinking, they will timeout and you will have to start over again. Often I would frustratingly just connect the wiimotes using GlovePIE first because it gracefully handles wiimote registration. Once the devices are registered properly however, you can start, stop, and restart FreePIE scripts without problems.


FreePIE will handle up to 4 wiimotes and light up the LEDs to indicate the numbering order. Within the script, you must indicate the wiimote index number (even if you are just using 1 wiimote). The syntax is wiimote[n]:getValue() (ie: wiimote[0].getUp() ) Currently only buttons are supported and here are the available functions.

getUp()
getDown()
getRight()
getLeft()
getA()
getB()
getMinus()
getHome()
getPlus()
getOne()
getTwo()

Here is a sample script for dual-hand Wiimote control of a FPS game

Nice work! I removed the reference to Wiimote from GUI and made a script that copies it to the correct folder. Is it a bug with the Wiimote lib or whats the problem with realease?

I'm not sure. It works in my Console release and debug fine, but it doesn't work in my GUI release. Maybe it's just a compilation error. I will retry it again later.

I can try it out later tonight, what I did when i tried out indexed plugins were to declare an indexer for the global plugin, dont think I tried it in release though. I will try to find some time later tonight to try it out

I have been putting together a script for dual-hand wiimote control of SkyRim. This is the first time I've really done any integration and real-world testing of the project, and I have uncovered a number of lingering bugs and usability issues. I uploaded fixes to several modules. The previous script can now be written simpler like this...



I'll publish the full SkyRim script in a few days designed for untethered back-top usage - complete with Vuzix head-tracking and dual wiimote control.

It worked in release for me, I removed all Wiimote code since I dont have a wii mote. But the indexer part of your code works.

Make sure to "Clean solution" every time when you build the GUI since it does not have direct references to project, I've noticed that VS does not allways copy the dll to the plugin folder.

ok thanks for checking it out

I'm thinking of moving the Code to Github, this way people can contribute code without being part of the team (With the pull request mechanism). We can keep the Project place at Source forge..

What do you say?

I've never used Git so I don't know much about the technical details, but I have heard it described by Linus Torvalds. Right now I think there are only two developers working on FreePIE so organizationally, I don't think it matters one way or the other. However there are some benefits to using Git's uncontrolled source model. For example, I would like to create a console-only version of FreePIE, but with the SourceForge model I was afraid that it would lead to developer conflict. With Git however, I would just be creating another branch.

If we moved to Git anyone can make a branch, I'm sure there are lurkers that would contribute if it was easy todo, its not currently easy with Sorceforge / SVN. I've also got requests in t he form of MTBS PMs to move the code to Git

We could ask Neil to set up a sub forum Dedicated to FreePIE and close down the Source forge site completely.

Project page moved to Github

https://github.com/AndersMalmgren/FreePIE

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.

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.

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.

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

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

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.