Tagged as: Unity 5

Wearable hololgrams. Image tracking with Vuforia and Hololens.

I have been playing around with the new Vuforia support for Hololens and trying to see how well it can track moving objects.  I started with the documentation @ “Developing Vuforia Apps for HoloLens” and my scene is based off the sample scene in the documentation.

The goal is to have a wearable bracelet that can anchor a hologram, using three fiducial markers.

After a number of attempts and tag designs I landed on this design.

The markers can be reliably detected, but a bit big!

The markers can be reliably detected, but a bit big!

My first attempt used tags that were about 1 3/8 inches, and I found it was rarely detecting them, only when really close.

The square target is big enough, the circle is too small to be detected reliably.

The square target is big enough, the circle is too small to be detected reliably.


Marker on the left ended up being too small to detect reliably.

Marker on the left ended up being too small to detect reliably.

The tags I ended up using are 2 inches, and can be detected at arms length.

One big gotcha that I have found, when you upload markers to the Vuforia device database, you need to ensure that you enter the correct width, as it is printed in the real world, or holograms will anchor too far above or below the object ( the lens thinks it is closer or further away than it really is )

You also want the “rating” in the Vuforia target manager to be as high as possible, images with lots of features are more augmentable. 1 star rating will not work at all.

There is also a camera setting, Camera Mode (SPEED vs DEFAULT vs QUALITY) results in selecting different camera resolutions, but it is not documented on what exactly is selected. I am using the SPEED setting, which I assume will identify the images quicker? I also have used the QUALITY setting, which did not seem to impact the FPS, speed of detection or distance needed.  Have not found much documentation on it.

Vuforia for Hololens has a feature called “Extended Tracking” that will pin objects to to their last known location when tracking is lost, which is nice if you would like to look away from something and look back and still have it registered.   Given the limited FOV of the camera, it seems you would want to use this feature in all cases where objects are mostly static, but it doesn’t work well for moving objects ( like in this case ) the holograms will get stuck and not update with your movement.

Ultimately, it seems like this sort of image location is really best suited for static objects. It works for a wearable bracelet, but I am thinking technologies like Lighthouse or Zapbox would do much better.

I can't use MRC or take screenshots while vuforia is running, so here is a shot through the lens via cellphone.

I can’t use MRC or take screenshots while Vuforia is running, so here is a shot through the lens via cellphone.

Unity Development: Procedural Cave Generation

Procedural generation has become a popular aspect of video games recently, with random number generation deciding things such as level design, powerup spawning and placement, and even more advanced systems like the AI Director in the Left 4 Dead series dynamically altering play based on random number generation and player performance.

In Left 4 Dead, when players do particularly well, the game will up the number of zombies that could potentially spawn to accommodate.

In this tutorial series, one of the community members from the Unity scene goes into detail about how to build a procedurally generated cave system, based off of a 2D Array which is used as a map. At the end of the tutorial series, there is no fully functional game, per se, but you will be able to navigate your generated map with a little red cube and collide with it properly, as some time is spent explaining how to make a collision mesh based off of the random generation results.

A look at the final product

A look at the final product

The generation starts off rather simple: It takes a 2D Array of a given size and populates it with either 1s or 0s depending on an input string (the seed). The tutorial goes into some depth about how to randomize the seed, albeit with one major mistake: It uses the Unity method “Time.time()” to determine the seed, which refers to in-game time. Thus, at game start the time will always be 0, hence the map generated will always end up being the same. To use the system time (a much better solution), the seed would need to look at System.DateTime.Now.ToString() instead. After a map is generated, we apply an algorithm to the map to smooth it out: For each tile in the map, fill it if there are a certain number of filled tiles around it, otherwise unfill it. The idea behind this algorithm is to see where patterns in the random generation lie, what tiles are all filed near each other, and use that to shape out the map.

A randomly generated map

A randomly generated map

After the map is generated and smoothed, then we need to clean up the grid so it looks cohesive instead of a few thousand squares combined together. To do this, the author uses the Marching Squares algorithm and applies it to the grid.

A map with Marching Squares

A map with Marching Squares

After Marching Squares comes the mesh to actually start making the grid into something usable for our finished product. This mostly extends the map along the Y-axis, to create walls where our edges are. After this we get to start editing the map some more – detecting regions in order to flesh out our “rooms” a little better, by removing any black or white spaces less than a certain customizable size. Next comes connecting these rooms. The author breaks this into two parts – part one just ensuring that rooms are connected, and then part two ensuring that all rooms are connected by using one single “parent” room and checking that each room is connected to it somehow – either directly or via another room.

All rooms are connected via passageways - the green line indicates where a passageway was made

All rooms are connected via passageways – the green line indicates where a passageway was made

And finally, the last part is spent making sure our collision mesh works by giving us a little player object and moving it about the grid. I have noticed two problems with this resultant product so far – the first being minor; since the player object is a cube and not all collisions are straight-on parallel, the cube starts spinning around rather fast once it collides into a wall. The second is rather major, though:


Yep, the map generator is completely independent of the player object, meaning that it can spawn inside walls, rather than caves. Because of the way the collision mesh works, however, it will still obey the walls present in the generated mesh, so in effect the map is inverted for our little cube friend here. The tutorial does not acknowledge how to fix this, though I suspect it wouldn’t be too hard to relate the cube’s position to a point on the map to check if the cube is somewhere “safe”.

And thus, we have a procedurally generated cave using nothing but scripts and a few materials. The trickiest part of this was actually generating the mesh – very time consuming and not a lot of immediate payout. However, in the end, this was still a good exercise in learning how to generate something using merely the time.