Forum Discussion
Possibility of OR in unity free...
So, as my project states, I'm trying to work on making a VR glove/arm to add to the immersive experience of the OR. Unity had an issue, and any time I would try to read data from the system.io.ports, it would hard crash to the desktop without any errors being thrown. I'm guessing this is an issue with monodevelop not unity.
Either way, I had to figure out a way to get the serial port data I wanted into unity. The answer? Using pipes. Pipes are a form of interprocess communication. Think of it as a network connection, but from one program to another, instead of one computer to another. You still send stuff as a buffer in bytes even.
Anyway, my brother and I got this working in unity free last night. With it we can send any form of byte data directly to unity in effectively real time. This means that theoretically someone could write a wrapper for the standard C/C++/Whatever to where c# can get the data directly, and then just send it to unity.
I'll be working on this further to get it running for my vr glove thing, but I can post the code if anyone is interested. I'll probably end up making it run as a background service, so no window pops up, so no one would be the wiser as to it running on the system.
I'll update everyone as it comes together (the glove thing, which will include this program) if anyone shows any interest. The only downfall is it may cause a few ms of lag (read data in one program, send to other, other read data, data is applied.) but we'll see I guess. I don't have my oculus yet (and probably won't for a month or so), so I can't test that part out right now.
That's all, Good day!
Either way, I had to figure out a way to get the serial port data I wanted into unity. The answer? Using pipes. Pipes are a form of interprocess communication. Think of it as a network connection, but from one program to another, instead of one computer to another. You still send stuff as a buffer in bytes even.
Anyway, my brother and I got this working in unity free last night. With it we can send any form of byte data directly to unity in effectively real time. This means that theoretically someone could write a wrapper for the standard C/C++/Whatever to where c# can get the data directly, and then just send it to unity.
I'll be working on this further to get it running for my vr glove thing, but I can post the code if anyone is interested. I'll probably end up making it run as a background service, so no window pops up, so no one would be the wiser as to it running on the system.
I'll update everyone as it comes together (the glove thing, which will include this program) if anyone shows any interest. The only downfall is it may cause a few ms of lag (read data in one program, send to other, other read data, data is applied.) but we'll see I guess. I don't have my oculus yet (and probably won't for a month or so), so I can't test that part out right now.
That's all, Good day!
10 Replies
Replies have been turned off for this discussion
- I was curious how long before someone came up with a workaround. Looking forward to seeing how this plays out; keep us posted!
- I think there is another reason why you need Pro and that is the Post Processing shader that counters the lenses fisheye distortion, not just the native plugin communication.
- Some workarounds have already been found by mtbs3d people (including the warping) :
http://www.mtbs3d.com/phpbb/viewtopic.php?f=140&t=16326 - Well, since the warping is fixed via the driver thing, then all that's left is getting a wrapper for c# finished, and my own little program working a bit better. (can't make it work for the wrapper until the wrapper is finished XD) Luckily, Entroper is helping by working on a wrapper for us, so when it gets done, we can get this working hopefully.
- So, there was a random error that broke unity by freezing it. It turns out unity doesn't like using system.threading. So... I rewrote the C# code to be asynchronous, and am trying to get the unity side to use invoking as a threading process. It works fine... until I try to read the buffer out. T_T.
So, at this point, it's either put stuff back to using threading in unity, or try and figure out why it's freezing on reading the buffer. T_T.
I'll keep working at it, but figured some people may want an update. "CaliberMengsk" wrote:
I'll keep working at it, but figured some people may want an update.
Thanks, and best of luck!- Fully working now... Only one major issue, and that's that unity isn't closing the thread when stopping the game, so when you try to start. I need to figure that one out. Either way, here's a video of it running correctly:
http://www.youtube.com/watch?v=tQv8gv57L3g
When not screen recording with OBS at 1920x1080, I get around 7,000-8,000 sends and receives between c# and unity. While recording it was still 5,000 to 6,000 times a second, so pretty darn good.
I'll work at it to make it more modular also (so you can add it to your project) and hopefully have some sort of a release soon. Only other issue is I still don't have an ETA on my rift, so I can't personally test anything, even if the wrapper for the rift gets finished. Should be some time within the month I hope. T_T - Thanks for sharing that, very nice. I am also working on something similar, I have an old Polhemus Fastrak with 4 sensors and am working on getting the data into Unity.
I have managed to read the data from the serial port in Unity using system.IO.ports without it crashing. Not sure why you had a problem. But it seemed to be very slow at parsing the data within Unity so I made a c# dll that connects to the Fastrak and parses the data, and then I just communicate directly with the dll from Unity. Seems to work OK so far but I am not 100% finished. Maybe Pipes might be a better option for me too. "CaliberMengsk" wrote:
So, as my project states, I'm trying to work on making a VR glove/arm to add to the immersive experience of the OR. Unity had an issue, and any time I would try to read data from the system.io.ports, it would hard crash to the desktop without any errors being thrown. I'm guessing this is an issue with monodevelop not unity.
Either way, I had to figure out a way to get the serial port data I wanted into unity. The answer? Using pipes. Pipes are a form of interprocess communication. Think of it as a network connection, but from one program to another, instead of one computer to another. You still send stuff as a buffer in bytes even.
Anyway, my brother and I got this working in unity free last night. With it we can send any form of byte data directly to unity in effectively real time. This means that theoretically someone could write a wrapper for the standard C/C++/Whatever to where c# can get the data directly, and then just send it to unity.
I'll be working on this further to get it running for my vr glove thing, but I can post the code if anyone is interested. I'll probably end up making it run as a background service, so no window pops up, so no one would be the wiser as to it running on the system.
I'll update everyone as it comes together (the glove thing, which will include this program) if anyone shows any interest. The only downfall is it may cause a few ms of lag (read data in one program, send to other, other read data, data is applied.) but we'll see I guess. I don't have my oculus yet (and probably won't for a month or so), so I can't test that part out right now.
That's all, Good day!
With the MYO and the Leap motion plus this will thing will be awesome and easy to control"Krisper" wrote:
I am also working on something similar, I have an old Polhemus Fastrak with 4 sensors and am working on getting the data into Unity.
Hi, I am also working to make a VR arm using Oculus Rift DK2 and Polhemus Fastrak or Polhemus Liberty for tracking.
So I will need some help for getting data from Polhemus to move the arms in Unity.
Thanks,
