Howdy all!
The Unity version of the HUD is coming along nicely - I've finished the code to pull in all the data from the IMU to one of the information panels, and I've been tweaking the code here and there to make sure the readings are accurate. The only (noteworthy) issue I've run into has been Unity's update() function, which runs once per frame. The application is (currently) so lightweight that the framerate can exceed the read/parse process of the serial data stream. I've implemented a crude way of temporarily solving that problem (execute this process every x number of frames), but framerate will still vary widely in the editor. However, you can put a frame limiter on applications that have been built, so that'll probably be the way to go. 60 or 120 FPS ought to be a good number to base all of the functions off of.
Below is a screenshot of the application running with all the IMU variables in the right info panel, which can be animated/moved around at will (SO much easier than Processing). On the far right, the raw serial data is shown, while the data that gets barfed out for debugging is in the lower left-hand corner.
The new build will be available soon - it's actually already ready to go, but since I've modified the original Adafruit 10-DOF example code to streamline the ReadLine() operation, I'll need to put the Arduino code up with it, and potentially a copy of the 10-DOF library, so folks can compile the new code. Sooo....there isn't much point quite yet, as the only changes have been on the serial side of things.
Cheers,
~Lexikitty
Saturday, March 14, 2015
Thursday, March 5, 2015
The Iron Girl Project - Systems Report and HUD Updates
Howdy y'all! Some interesting updates have happened with the HUD, so I'll dive right in.
I've swapped Processing out for the Unity game engine, both for performance and ease of manipulation in 3D space. Unity works much like a regular 3D application, whereas Processing requires you to place objects via a coordinate system. Attempting to animate any elements in Processing quickly became a nightmare, and adding and placing new components was time-consuming. Here's an example of the first copy of the Unity HUD:
Since Unity supports C#, a JavaScript-ish thing called UnityScript, and Boo (a Python variant), it means there's a nice variety of coding choices for different elements. For instance, the scripts that run the dynamic text on the screen are in JS, while the script that pulls in data from the serial port (which is fed numbers by an IMU hooked up to an Arduino) is in C#. Below is an example of the working serial feed.
After a lot of blundering about and experimenting, I took a few weeks to got some actual training in Unity (from a company called Digital-Tutos), after which I redid the HUD in GUI elements, rather than TextMesh objects mapped to 3D assets. This way, no matter what, elements on the HUD will resize to fit the screen resolution and aspect ratio of the target system. (The end goal of this is to achieve stereoscopic rendering via Google Cardboard's SDK, but shhh - don't tell anyone, that'll be a surprise). Examples of dynamic GUI elements:
Test builds are now available for both Windows and OS X over on the download page. Please download them, and comment below/send me a message on your experiences. I have a decent number of Linux and Windows test machines, but I have no testing platforms for OS X. I also don't have any way of testing multiple camera setups, as I only have 3 or 4 at home. If you put something on COM3 at 115200kbs, it'll write it to the Debug Log.
Have fun with it, and let me know the results!
In other news, I'm currently delaying work on fabrication (and to a lesser extent, design) of physical pieces for the IGP suit. I may be moving in the next few months to a larger space, which should greatly increase my ability to produce parts, but until then, I'd rather not prototype a bunch of stuff that I'll then have to carefully box up and move. So expect HUD-focused stuff for the next few months. Around September, things should settle down again and I'll be able to switch to physical production.
Have a lovely evening, and go make something awesome!
Cheers,
~Lexikitty
I've swapped Processing out for the Unity game engine, both for performance and ease of manipulation in 3D space. Unity works much like a regular 3D application, whereas Processing requires you to place objects via a coordinate system. Attempting to animate any elements in Processing quickly became a nightmare, and adding and placing new components was time-consuming. Here's an example of the first copy of the Unity HUD:
Since Unity supports C#, a JavaScript-ish thing called UnityScript, and Boo (a Python variant), it means there's a nice variety of coding choices for different elements. For instance, the scripts that run the dynamic text on the screen are in JS, while the script that pulls in data from the serial port (which is fed numbers by an IMU hooked up to an Arduino) is in C#. Below is an example of the working serial feed.
After a lot of blundering about and experimenting, I took a few weeks to got some actual training in Unity (from a company called Digital-Tutos), after which I redid the HUD in GUI elements, rather than TextMesh objects mapped to 3D assets. This way, no matter what, elements on the HUD will resize to fit the screen resolution and aspect ratio of the target system. (The end goal of this is to achieve stereoscopic rendering via Google Cardboard's SDK, but shhh - don't tell anyone, that'll be a surprise). Examples of dynamic GUI elements:
Test builds are now available for both Windows and OS X over on the download page. Please download them, and comment below/send me a message on your experiences. I have a decent number of Linux and Windows test machines, but I have no testing platforms for OS X. I also don't have any way of testing multiple camera setups, as I only have 3 or 4 at home. If you put something on COM3 at 115200kbs, it'll write it to the Debug Log.
Have fun with it, and let me know the results!
In other news, I'm currently delaying work on fabrication (and to a lesser extent, design) of physical pieces for the IGP suit. I may be moving in the next few months to a larger space, which should greatly increase my ability to produce parts, but until then, I'd rather not prototype a bunch of stuff that I'll then have to carefully box up and move. So expect HUD-focused stuff for the next few months. Around September, things should settle down again and I'll be able to switch to physical production.
Have a lovely evening, and go make something awesome!
Cheers,
~Lexikitty
Subscribe to:
Posts (Atom)