Meant to be Seen

Posted: **Tue Jun 04, 2013 4:15 am**

CyberVillain wrote:Well you are buffering the delta which does slow down the output from FreePIE, but maybe thats the only way, I will see if the lower level apis used can use doubles or if buffering is the only way.

I had a quick play this morning. It is possible to alter the mouse plugin script so that deltaX and deltaY values are floats. I then only commit full pixel movements and save the remainder. This is a lot cleaner than doing it in python admittedly. Let me know your thoughts
https://github.com/baggyg/FreePIE/commi ... 730b261e6c

I believe this to be the only way to do it. Ultimately a call the user32.dll must give a mouse change in pixels

Code: Select all

[StructLayout(LayoutKind.Sequential)]
      public struct MOUSEINPUT
      {
         public int dx;
         public int dy;
         public uint mouseData;
         public uint dwFlags;
         public uint time;
         public IntPtr dwExtraInfo;
      }

Posted: **Tue Jun 04, 2013 5:06 am**

I can fix so that the mouse plugin buffers the delta until its bigger than 1.0.
That's what you want right?

Posted: **Tue Jun 04, 2013 6:03 am**

Updated both master and yei branch with a mouse plugin that buffers output until its >= 1.0

Posted: **Tue Jun 04, 2013 7:25 am**

Hi Cyber,

I had a look at what you committed and although it is close to what mine is, its not quite the same and I believe to be missing something important.

If you look at my commit you will see that mine actually keeps an accurate count on deltas and doesn't reset them to 0 but instead retains the remainder.
https://github.com/baggyg/FreePIE/commi ... 730b261e6c

Code: Select all

// Reset the mouse values
                if ((int)DeltaXOut != 0)
                {
                    DeltaXOut = DeltaXOut - (int)DeltaXOut;
                }
                if ((int)DeltaYOut != 0)
                {
                    DeltaYOut = DeltaYOut - (int)DeltaYOut;
                }

It also does not nullify yaw if pitch was moved and vice versa. This is very important. I tried out yours and it leads to jerky smaller movements where deltas have been cleared. Using my code from the above, small movements were very smooth.

The changes I did were less about "buffering" and more about knowing the precise position the mouse pointer should be

Posted: **Tue Jun 04, 2013 1:50 pm**

hm ok. will have to look into it, that code looks a bit strange.

basically what you do is

if deltax > 0.5 then substract it with closest integer of deltax

Posted: **Wed Jun 05, 2013 3:08 am**

CyberVillain wrote:hm ok. will have to look into it, that code looks a bit strange.

basically what you do is

if deltax > 0.5 then substract it with closest integer of deltax

Yes there are two things to consider here that need to change in your code:

1) Resetting pitch when only yaw moved (and vice versa)
Imagine you are moving the sensor from left to right but also slightly downward. If the sensor refresh rate is fast enough and the movement slow the vertical movement will be ignored since you are zeroing this everytime you adjust the yaw.
I.e.
1st Cycle
yaw = 1.2
pitch = -0.4
2nd cycle
yaw = 0.9
pitch = -0.35
3rd cycle
yaw= 1.3
pitch = 0.49

In this situation you would "lose" the pitch movement since you are resetting it in your code however it should have moved 1 pixel down.

2) You need to keep the remainder delta to the next cycle. Imagine the following situation:
100 cycles of yaw = 0.6
then
100 cycles of yaw = -1
What would actually happen here is that you would move your sensor the equivalent of 60 pixels to the right. You would then move it the equivalent of 100 pixels to the left. However the mouse would have moved the the exact same amount of pixels on both directions, again leading to "lost" movement. You can see this is clearly not right.

Whereas by keeping the remainder it works like this:
1st cycle
0.6 (mouse moves 1 pixel right)
remainder = 0.6 - 1 (Integer Value) = -0.4
2nd cycle
0.6 + -0.4 = 0.2 (mouse does not move)
0.2 - 0 (integer value) = 0.2
3rd cycle
0.6 = 0.2 = 0.8 (mouse moves 1 pixel)

You actually dont need to check if it is > 0.5 as this will round down (like in the 2nd cycle) whereby no change is made to the delta.

Therefore the only change to your code to solve both problems is

Code: Select all

deltaXOut = deltaXOut - (int)deltaXOut;
deltaYOut = deltaYOut - (int)deltaYOut;

on line 110 of FreePIE.Core.Plugins/MousePlugin.cs

instead of

deltaXOut = 0;
deltaYOut = 0;

I appreciate this is hard to test if you don't have the right hardware. I believe the reason I experience it with the YEI is because the refresh rate is very high and the change in delta is very precise.

However having played with this for quite a few hours I can assure you my method has been tested correct.

Posted: **Thu Jun 06, 2013 11:20 am**

Added a simple tare function to the script, that tares based upon current orientation. This would be better with the offset as seen in the UDK integration but I will leave that for when RoadKillGrill picks up the project again.

https://github.com/baggyg/FreePIE/commits/YEI3-Space

This is another function that should be put in the plugin menu popup. For the moment it is there just in python script:

Code: Select all

yei[0].tareSensor()

RoadKillGrill:
In the current state, things are working quite nicely. The two issues that need looking at are:
1) A better tare with offset quat (for when not properly level).
2) To figure out why the streaming function is crashing when built (it works when debugging).

CyberVillian:
Did you have a look at my notes on the mouse plugin?

Posted: **Thu Jun 06, 2013 12:28 pm**

Yes, but I havent add time to play around with it, sorry

Cant the streaming functions be hidden and called from the plugin when starting and stopping?

Are there scenarios when you do not want to stream?

Posted: **Thu Jun 06, 2013 12:38 pm**

CyberVillain wrote:Yes, but I havent add time to play around with it, sorry

Cant the streaming functions be hidden and called from the plugin when starting and stopping?

Are there scenarios when you do not want to stream?

Absolutely, they are currently not called that way simply because I know they crash the program. I did have it so that they started automatically and then was planning to add to the plugin menu but took it out when I knew we had a problem. Once we figure out the problem I agree this is the best way to go.

Regarding stopping streaming it may be useful for comparison purposes (performance / latency etc).

Posted: **Thu Jun 06, 2013 1:41 pm**

Really strange. Tried different array marshaling on the byte array?

You can also try to ask a question on stackoverflow

Posted: **Fri Jun 07, 2013 5:15 am**

CyberVillain wrote:Really strange. Tried different array marshaling on the byte array?

You can also try to ask a question on stackoverflow

Had another crack this morning. Just trying to get an alternative marshalling working is a challenge. Interestingly when I try to directly marshal it to a float array (rather than the Struct) it seems to block the CPU. The system continues at a crawl, never getting passed the getLastStreamData() DLL call but the orientation / mouse values get updated.

I have created a ticket on stackoverflow and also asked at the YEI technical forums. Hopefully this will lead to an answer.

Posted: **Fri Jun 07, 2013 6:00 am**

Lets hope we get some answers then

Posted: **Fri Jun 14, 2013 4:38 am**

CyberVillain wrote:Lets hope we get some answers then

They have come back to me on the official forum and now I have streaming working!!!!

I need to set it to start automatically and a couple of small things and then ill update my branch.

Reminder: You still need to adjust you mouse plugin. What you currently have does not work for yei sensor (juddery movement). See my previous post.

Posted: **Fri Jun 14, 2013 5:48 am**

OK all done. I have set the streaming to start automatically as discussed.

I had to add some error trapping on the quaternion as in the first few seconds the streaming does not provide a number which then caused issues. However all tested working perfectly through a built binary in streaming mode.

https://github.com/baggyg/FreePIE/commits/YEI3-Space

Posted: **Sat Jun 15, 2013 4:53 am**

Nice, will merge it into master when I get the time. Good work!

Posted: **Sun Jun 16, 2013 6:26 am**

Hi.
I've been testing your changes to the mouse plugin.
A problem with it is that it will make the cursor move slighly even if the device is not moving, if I revert to the old mouse plugin this is not the case.

Posted: **Sun Jun 16, 2013 12:22 pm**

CyberVillain wrote:Hi.
I've been testing your changes to the mouse plugin.
A problem with it is that it will make the cursor move slighly even if the device is not moving, if I revert to the old mouse plugin this is not the case.

I don't see how that can be the case.

If there is no movement than deltaX/y will be 0 and the calculation will be deltaX = 0 - 0 (passed parameter and held value).

Perhaps if you could provide some more detail I can check.

What you may be seeing with whatever device you are testing is that it is actually slightly moving (drift perhaps). On the old one because this movement was very slight it was being zeroed every cycle. With the changes it remembers these small changes.

However this is occurring because the is a movement. If you are passing no change in delta at all then the cursor wont move.

Posted: **Sun Jun 16, 2013 2:24 pm**

One error I see is that you compare a float vale to != 0 that will never return false because you will always have some noise from the device. Better to do Math.Abs(deltaX) >= epsilon

Posted: **Mon Jun 17, 2013 2:33 am**

CyberVillain wrote:One error I see is that you compare a float vale to != 0 that will never return false because you will always have some noise from the device. Better to do Math.Abs(deltaX) >= epsilon

I left that in since I am not familiar with all devices and didn't know if some would actually pass exactly 0 and therefore the calculation doesn't need to run. However I agree, there is always some movement so it needs to do the remainder calculation every time even if there is no movement in the mouse (I.e. -0.5 < delta < 0.5).

Thinking about this "dead zone" for the mouse. I can understand if some devices cause issues with this level of accuracy. The YEI sensor definitely needs this. Perhaps you could add some branch in the code to only do this with certain inputs or add a python command for people to add to their scripts to enable it. Alternatively you could change the other plugins that cause issues so that you round to an integer before passing to the mouse plugin.

Posted: **Mon Jun 17, 2013 6:01 am**

I can pull the other stuff first, we will release soon. Is the YEi stuff working?

Posted: **Mon Jun 17, 2013 6:42 am**

CyberVillain wrote:I can pull the other stuff first, we will release soon. Is the YEi stuff working?

Yep, streaming etc all working fine on my latest commit. Been playing last week or so in Bioshock and really responsive so ready to go.

The only thing that really needs doing is perhaps a plugin window with commands to stop / start streaming and also a link to the tare function (for non programmers) but none of these are actually required, just 'nice to have'.

Posted: **Mon Jun 17, 2013 6:45 am**

FreePIE does not support plugins to pull up UI's
But, shouldnt this be handled by the plugin automatic under the hood?

Cant you from the plugin determine when to start stop streaming and tare?

edit: Btw, alot of Console.WriteLine's those will end up in the debug window of freepie, ok to remove them?

Posted: **Mon Jun 17, 2013 7:06 am**

CyberVillain wrote:FreePIE does not support plugins to pull up UI's
But, shouldnt this be handled by the plugin automatic under the hood?

Cant you from the plugin determine when to start stop streaming and tare?

edit: Btw, alot of Console.WriteLine's those will end up in the debug window of freepie, ok to remove them?

Hi,
I meant we could create a popup window from the plugin option on the menubar for YEI similar to how TrackIR has (that asks the user to enable logging).
As I said its only a 'nice to have'. The user can use:
yei[0].tareSensor()
yei[0].startStreaming()
yei[0].stopStreaming()
in their python scripts if they choose. You can also remove these if you want.

To be clear these aren't needed at all. By default the sensor will start streaming itself and take the tare set through the yei suite so these never need to be called unless you want to experiment or tare on the fly.

Yeah you can remove the Console.writelns - they were mostly for my debugging.

Posted: **Mon Jun 17, 2013 7:56 am**

baggyg wrote:
CyberVillain wrote:FreePIE does not support plugins to pull up UI's
But, shouldnt this be handled by the plugin automatic under the hood?

Cant you from the plugin determine when to start stop streaming and tare?

edit: Btw, alot of Console.WriteLine's those will end up in the debug window of freepie, ok to remove them?
Hi,
I meant we could create a popup window from the plugin option on the menubar for YEI similar to how TrackIR has (that asks the user to enable logging).
As I said its only a 'nice to have'. The user can use:
yei[0].tareSensor()
yei[0].startStreaming()
yei[0].stopStreaming()
in their python scripts if they choose. You can also remove these if you want.

To be clear these aren't needed at all. By default the sensor will start streaming itself and take the tare set through the yei suite so these never need to be called unless you want to experiment or tare on the fly.

Yeah you can remove the Console.writelns - they were mostly for my debugging.

So basicly it will work the same without them?

Posted: **Mon Jun 17, 2013 8:03 am**

CyberVillain wrote:
baggyg wrote:
CyberVillain wrote:FreePIE does not support plugins to pull up UI's
But, shouldnt this be handled by the plugin automatic under the hood?

Cant you from the plugin determine when to start stop streaming and tare?

edit: Btw, alot of Console.WriteLine's those will end up in the debug window of freepie, ok to remove them?
Hi,
I meant we could create a popup window from the plugin option on the menubar for YEI similar to how TrackIR has (that asks the user to enable logging).
As I said its only a 'nice to have'. The user can use:
yei[0].tareSensor()
yei[0].startStreaming()
yei[0].stopStreaming()
in their python scripts if they choose. You can also remove these if you want.

To be clear these aren't needed at all. By default the sensor will start streaming itself and take the tare set through the yei suite so these never need to be called unless you want to experiment or tare on the fly.

Yeah you can remove the Console.writelns - they were mostly for my debugging.
So basicly it will work the same without them?

Yep.
They were only there so you could switch between streaming and non-streaming data polling and to tare the sensor in the direction you were facing (like a trackIR center function)
or did you mean without the Console.writelns ? In which case also yes

Posted: **Sat Jun 22, 2013 6:48 am**

baggyg I merged my master with your Yei branch.
I had to remove the mouse stuff for now until I can test it more with more plugins. The code is however in the Git log so its easy to bring back if needed.

Please test that it works with my version since I removed some code etc

Posted: **Sun Jun 23, 2013 3:54 am**

CyberVillain wrote:baggyg I merged my master with your Yei branch.
I had to remove the mouse stuff for now until I can test it more with more plugins. The code is however in the Git log so its easy to bring back if needed.

Please test that it works with my version since I removed some code etc

Hi Cyber,

All tested here and working as expected

.
I see you have taken the tare function out, which is fine but I think users will want a solution for this in the long run as unlike trackIR you cant have the YEI space sensor suite open (and connected) at the same time as the running freePIE script so is definitely useful. Otherwise one must stop the script, connect via the suite, tare, close then run the script again. Maybe something for the future.

Regarding the mouse plugin I completely understand the need for more testing. However I think it vital you at least add an exception so that my changes are active for YEI sensors but disabled for all others plugins. I gave your version a go in-game (bioshock) for mouse head tracking and it simply isn't accurate enough and leads to lost movements and therefore not usable in the current state. I will continue to use my binary version of the code as for my purposes (head tracking) it works better. I suspect when people try their own YEI trackers they will get the same issue.

Thanks for the help getting the sensor supported. Its a great addition to freePUIE as I am not aware of another piece of software that supports it.

Posted: **Mon Jun 24, 2013 3:10 pm**

Ok, i get add back tare

https://github.com/AndersMalmgren/FreeP ... ePlugin.cs

I started a branch for the mouse plugin, sadly i cant get it to work.

Only way to get it to stop move when still is to take back the old code that sets sets valus to 0.

Posted: **Mon Jun 24, 2013 4:06 pm**

CyberVillain wrote:Ok, i get add back tare

https://github.com/AndersMalmgren/FreeP ... ePlugin.cs

I started a branch for the mouse plugin, sadly i cant get it to work.

Only way to get it to stop move when still is to take back the old code that sets sets valus to 0.

How are you testing it? If you watch the diagnostics of the plugin you are using's yaw / pitch is the sensor movement matching the movements of the mouse? Is it in one direction or backwards / forwards?

From all the tests I have done here the mouse movement matches the data. This may not be ideal if a plugin is providing "inaccurate" readings when perfectly still (I.e. actually reporting false movement). However If this is the case I perhaps the better answer would be to create a parameter deadzone per plugin that then filters the data to the mouse plugin. Its just one possible answer. Would it help if I sent you a video of the effect I see when it does reset the values to 0? (Make take me a little while as out of the country for a couple of weeks)

Posted: **Fri Jun 28, 2013 4:36 am**

I am happy to have found this thread! I have 3-Space sensor, the embedded version with a USB cable.

Honestly speaking I have two left feet when it comes to programming. I was very lost when reading all of the code exchanges

I am building my DIY Rift, since I am still waiting for mine (ordered early April)

I have seen the code you posted at Guthub, but I really have no clue on how to go about it installing it in FreePie.

Also you have managed to successfully use it with Vireio, how did you managed to do so?

I do apologize if I ask for this advice, but I have not seen any guides for the programming impaired!

Thanks for doing such amazing work mate!!!!

Posted: **Fri Jun 28, 2013 4:53 am**

Hannibalj2 wrote:I am happy to have found this thread! I have 3-Space sensor, the embedded version with a USB cable.

Honestly speaking I have two left feet when it comes to programming. I was very lost when reading all of the code exchanges

I am building my DIY Rift, since I am still waiting for mine (ordered early April)

I have seen the code you posted at Guthub, but I really have no clue on how to go about it installing it in FreePie.

Also you have managed to successfully use it with Vireio, how did you managed to do so?

I do apologize if I ask for this advice, but I have not seen any guides for the programming impaired!

Thanks for doing such amazing work mate!!!!

I am not sure if CyberVillian has released the latest version as a binary (installable program). I think so, but if not it should be coming very soon.

You can link YEI into Virieo very easily. On the Virieo settings you just need to pick the "shared memory tracker" in the tracker option.

Then you can just reference it something like this through freepie:

Code: Select all

def update():
   vireioSMT.yaw = -Math.degrees(yei[0].yaw)
   vireioSMT.pitch = Math.degrees(yei[0].pitch)
   vireioSMT.roll = Math.degrees(yei[0].roll)
if starting:
   yei[0].update += update

There may also be a dll you need to put in your plugins folder. Again I am not sure if this is automatically there in the new version.
Let me know if you have any problems. Will be good to have someone else doing some testing with the YEI

Posted: **Fri Jun 28, 2013 6:50 am**

It will be released very, very soon

Posted: **Fri Jun 28, 2013 7:00 am**

Hey man, Thanks for the quick response. How would I know if CyberVillain updated it?

Hehe, I don't really know about how "Reference it". But I'll look at FreePie and try figure it out!

Thanks Mate!

Posted: **Fri Jun 28, 2013 7:01 am**

CyberVillain wrote:It will be released very, very soon

Oh, Thanks a lot!!!!

Posted: **Fri Jun 28, 2013 7:06 am**

Hannibalj2 wrote:Hey man, Thanks for the quick response. How would I know if CyberVillain updated it?

Hehe, I don't really know about how "Reference it". But I'll look at FreePie and try figure it out!

Thanks Mate!

FreePIE works by the user creating a python script and then running it. The python script can reference one or more of the plugins that freePIE supports.

Usually best to have a play and get comfortable with it.
However as a brief guide (when the latest one is released):
1) Open freePIE and Vireio. (Make sure you dont have YEI Sensor Suite Open and Connected)
2) In Virieo have the tracking method as "Shared Memory Tracker". Have the screen mode to whatever you are using with your DIY
3) In freePIE, click File -> New.
4) Copy the code I posted above in its entirety.
5) Save it somewhere
6) Click F5 to run it.
At this stage nothing should happen although freePIE should be sending data to Virieo. To check this launch a supported game. The game should load SBS or whatever and you should be able to move the mouse by moving your sensor.

Posted: **Fri Jun 28, 2013 7:19 am**

vireioSMT is not a core plugin so it needs to be copied to the plugins folder of FreePIE

Posted: **Fri Jun 28, 2013 7:23 am**

Huge thanks to CyberVillain and baggyg for making this plugin possible. You guys are awesome

Posted: **Fri Jun 28, 2013 12:38 pm**

Hello Amigos!!! (Friend in Spanish) I am finally out of the office. I tried making a new script saving it and the running it with F5 shortcut.

I got this noticed on the lower UI, "6: global name 'yei' is not defined"

Could this be related to the Dll file not been on the Freepie folder? If so, where do I find the dll file?
Again, thanks for the help!

BTW, let me know what test you need, I'll give it a try!!

Posted: **Fri Jun 28, 2013 1:08 pm**

yei plugin is only available if you compile the latest version on Github.. But binary version is soon out

Posted: **Sat Jun 29, 2013 3:32 am**

Hey CyberVillain, Thanks for the latest release!!

I tried referencing from FreePie to Vireio with Baggyg, script;

"def update():
vireioSMT.yaw = -Math.degrees(yei[0].yaw)
vireioSMT.pitch = Math.degrees(yei[0].pitch)
vireioSMT.roll = Math.degrees(yei[0].roll)
if starting:
yei[0].update += update"

and then pressing F5.

I got this note on the bottom of the UI:
"4: global name 'vireioSMT' is not defined"

An idea what does this mean?

Thanks for the latest Binary update!!

Meant to be Seen

YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE

Re: YEI 3-Space Sensor and FreePIE