Category Archives: Projects

Personal projects that I am either working on or thinking of working on.

Unity, Daydream, VIVE and some more VR

Spent some time after hours doing some work with unity and blender with my friends Sam and Malcolm. We’re all trying to become more proficient in putting together virtual spaces and using these tools to build more interesting assets.

I’ve got a daydream headset now to complement my HTC Vive. I really want to reach the point where I can build things that work on flat PC screens and both the vive and daydream (cardboard might be nice as well, but it is less interesting as its control capabilities are quite limited).

Malcolm and Sam are focusing on the daydream for now. We’re all going after different sorts of content. I’m aiming for a computer mediated, turn based, multi-player game inspired by some of the old board wargames I played in high school and college.

Malcolm and Sam helped me get my phone and computer loaded with the daydream development tools and mostly running (I left my daydream headset at home so I’ll have to fill in the remaining details later). I still have quite a bit of coding to do in order to get a working initial environment for my game going. I’m also going to have to work to keep the graphical intensity at a level that the phones can handle…I expect the PC and vive will want a different sort of assets for practical purposes.

Once the base game is working, I’ll need to put together a PHP/MySQL back-end to connect the game-board implementation to other players. Details here remain to be worked out, but I expect the initial version will be hosted here with some hand coded PHP managing the back-end. I am still split on how to partition up the game rules logic. Ideally the local copy of the game would only handle display and rendering while the server side code would handle random number generation and rules logic. Placing that much complexity in the PHP code may not be an ideal solution…I’ll have to play with things more in order to be sure.

Looking at building a simple game with unity

I’m looking at building a game similar to stellar conquest (without borrowing any copyrighted content) using unity and then setting up a multiplayer capability through an internet connection (likely my hosting with some PHP persisting moves to a MySQL database).

I’ve got the basics figured out for laying out the playing surface and it looks as if prefabs work for creating stars, planets and ships. I can see how the player interface would work in VR (either room scale or three axis) but I’m going to have to dig in to work out hit-testing for on-screen mouse activity.

I’m going to be thinking about how to handle star generation. The game that is providing the inspiration used a fixed map with the star located at mostly symmetrical positions. I’m inclined to have my game place the stars using a random number generator but with a defined distribution of star types to ensure some level of balance.

I’m going to do the same sort of thing for planets…not cards from a deck as with the board game but again, randomized with appropriate probabilities to yield the right sorts of planet mix.

I think the next step is probably to build the star cluster and scatter some colored lights about through space…I’m really tempted to go with a three dimensional star cluster for the final version if VR is the main target.

Started adding mongodb support to C# code

I started adding in concrete MongoDB support to the tool code I’m building. Last night I incorporated the drivers into the solution and set up the connection code for the database. My initial attempt to directly use the C++/CLI object to push a record into the database failed but I expect to add a class that is properly serializable to BSON tonight and get volume information persistence working. I still need to get a better handle on updates in MongoDB. I know there are various sorts of atomic test and set sorts of operations on documents and in order to make this work properly with concurrent access, I need to understand those operations and use them to ensure that updates don’t ‘walk’ on themselves.

When I have a bit more time to type, I’ll add in more details on the MongoDB driver work and the approaches I’m using.

Looking forward to 2019

Well, 2018 was a bit tumultuous. Lots of high points and a similar number of disappointments. I feel as if I’m ending this year about even with where I began it. Some wins, some losses, mostly evening out overall.

Hoping for more from the year coming up. The gyrations of the previous year have helped to shake out some things that needed shaking out. Expectations are set more reasonably and I think the coming year will move more steadily forward along a less erratic course.

I’m expecting a productive year with things better squared away and the path forward clearer that it has been for some time. Lots to get to…much of it potentially exciting.

This last year I wrapped up the program I had been running as software lead. Lots of C#, WPF and Angular running medical robotics with a team of three software engineers working for me. Since that rolled to a successful close I’ve been filling as as an individual contributor on a Java based instrumentation program. Hoping that the new year will bring in a new challenge as this program is wrapped up and handed off. Plenty of challenges to tackle and lots of diversity in the work ahead.

I’m looking to get my RapRap build rolling on the home front. I’ve had most of the relevant electronics around for some time but have always had other priorities bumping work on the 3D printer aside. This year I have friends who are willing to help out with the build and my basement work-bench cleared and ready for action. I’ll need to order parts and run through the build process, but I expect that things will go more smoothly at this point than they have in some time.

I’ve spent a chunk of time over the KMC holiday break (KMC usually keeps enough scheduled holidays in reserve to shut down for the week between Christmas and New Years) getting some progress on file management tools I’ve been playing with for some time. Hoping this time that I’ll get some completed tools running to assist in managing the current sprawl of files on my machines here.

I’m also hoping to get around to some real VR coding this year. I’ve had an HTC Vive here for some time. This year its time to lay down some code and play with this thing’s capabilities in a real way. I expect Unity will likely be a reasonable platform to build things on. I’m also expecting to put more time into learning blender and improving my drawing skills to support the effort. Time will tell where this might go, but there’s plenty to play with.

I’ve poked at VHDL a bit over the last year. I have a break-out board with a Xilinx FPGA on it in my drawer here. I’m not sure whether any more work on this front will happen this year as I expect other priorities to dominate…but again, time will tell.

I also expect to get back to doing more photography. I’ve fallen out of the habit of taking pictures just for the sake of making pretty shots. I need to spend a bit more time in the coming year making art in addition to building code and learning tools…need to find a balance here as with all things.

JSON over Stdin/Stdout for small local components.

I’m looking at adding a local control capability to my little C++ based file and volume identifier tool. I’ve run into a number of small functions that would be well served by tools written in specific languages that have access to specialized APIs but would benefit from a local interface with somewhat decent performance.

Unix style text in/text out is limiting as the command/response format lacks structure and the performance (with one process start per request) is potentially unacceptable.

Adding in a command line switch that sets the tool into ‘json in/json out’ mode and keeps the program alive until the pipes drop or an exit command is received should address these issues.

Ideally, the stdin and stdout would transport UTF-8 data containing complete JSON entities…one as a request and one containing the complete response. This can continue until the hosting program sends an EOF or drops the pipes.

I’m wrapping together a very lightweight JSON generator/parser to support this effort and will be following that up with some testing of C++/Java/C# (and perhaps others) sub-process and pipe management coding. If all goes well, I should have a nice little approach for wrapping small pieces of code that need to run in a particular language but must be hosted elsewhere with decent performance and a robust communications format.

Automation for PDF Viewing

I’ve wanted to automate view management for PDF documents for some time. It would provide a way to make locating the document I want and getting content up on the screen amid a mass of technical documentation much easier (and with the cryptic names that many companies use for their pdf files that can be a big deal).

Ideally I’d like to access the viewer over something like a DCOM automation link with full control over the view state and other particulars. In a pinch, I’d settle for process control, cross process window size and location management and some command line arguments to force the view mode and initial page view.

Here are some pages that might be helpful with this (still reading things but trying to keep a record here).

Another approach would be to find a PDF renderer that can be run inside a C# or C++ process. Looking there as well… Suspecting there may very well be a project or two on GitHub.

Taking a quick look at Mbed

A friend at work pointed me at Mbed devices for real-time end of line work. I’ve been involved in work that used 68hc11 processors for that sort of thing (getting very long in the tooth) and I’ve looked at using AVR parts (cheap, dip packages and decently capable). PIC controllers also seem to show up frequently (but the small look I’ve taken at the PIC architectures doesn’t make me happy).

These are ARM Cortex-M0 devices with what initially looks like pretty decent support. As an outbound, real-time controller and a back-end in something like an RPi (for home stuff) these might be a better solution than the AVR chips.

I’ve had good results from building systems with the ‘quick twitch’ responses pared down to the smallest size reasonable and baked into small controllers and keeping the higher level control (that doesn’t have the real-time response requirements) back on a linux or windows based system. This keeps the complexity in a location where powerful development tools and more capable processors reside and makes development much simpler.

I’ve been looking at CAN as an intermediate communications bus for this sort of work as well. The SPI and I2C options work well for tightly coupled peripherals in the same voltage/signalling family but don’t extend well.

Ethernet is wonderful for larger scale coordination between components that are running relatively complete operating systems.

CAN splits the difference with a defined physical layer running differential signalling that provides common mode noise resistance and (probabaly…haven’t looked in detail) avoids ground reference issues. It is still low level enough to code directly to (unlike TCP where the stack gets a bit involved to do things right). It supports quite a few devices on a single connection and has a decent access arbitration mechanism.

I haven’t bought any parts to try playing with this yet, but it seems promising.

Continued RepRap work

Looking to take some more steps forward on a RepRap printer. I’ve got at least some of the electronics for a baseline machine and the Prusa i3 has a wood frame option that looks very attractive.

Electronics list is here,. and a comparison chart here. Alternatives here.   RepRap DIY (looks like a European site). Heated bed discussion. Very much hoping to be able to buy (either as parts or a full assembly) an aluminum plate heated bed like the one in the commercial Prusa i3

Prusa i3 github site. I’m hoping this is where all of the directions, instructions and parts lists live…

System Level Design and FPGA Options

Reading a few things last night there seem to be new tools that work at a more abstract level than VHDL out there. Mentioned were System Verilog, SystemC and Handel-C. I’ll have to take a look sometime in the future. For the moment I suspect that VHDL will more than meet my immediate needs.

I’ve also been looking at FPGA choices a little bit. The Spartan-6 on the breakout board I’ve got looks about right for my initial sandbox work. I’d like to find smaller, larger and newer options for ongoing things…ideally something that is inexpensive enough to use as glue/support logic and can be worked with without needing a custom PCB. It is also clear that the Spartan line is getting old and that Xilinx is shifting FPGA focus towards newer designs such as the Artix

I’d like to look a bit at the CPLD end of the spectrum as these seem to promise smaller, cheaper glue options, perhaps even with less demanding packaging choices. Wondering if Altera has interesting options there…