This week, I experimented with generating a grid based on placed image targets, and ran into some issues with tracking stability.
As many TTRPGs are played on a grid, it makes sense that an in-engine grid would be necessary for a tool like this to function. While I wanted to use ground planes, combining them with image targets looked to be difficult. I decided to first try and simulate a grid by creating two targets which could be placed on opposite corners of a grid.
When the first target is found, the app would set that target as the world center in Unity, and then wait until it finds the second target. Once the second target is found, it calculates the distance between the two, rounds it out, and fills in the grid. All things considered, quickly throwing together and testing this process went fairly smoothly. I was able to set up a basic script that allows a specific method to be run when a target is found, and I created a singleton GridManager that creates the grid and holds references to it while the app is running. I ran into minor issues here and there with things like negative grid width, but nothing too major. This is the end result of my preliminary testing:
As it stands, this looks kind of neat, but I’m questioning how well it will work in the end. For now, the app treats target 1 as the world center, but target 2 still moves freely. This means that the grid won’t anchor itself to target 2 at all. This means that, if I get this working with a ground plane, it may be an extra struggle to use more than one target in cases where I need to perform a realignment; this then begged the question, why bother with two targets? While they make it easy to mark opposing corners of a grid rather than count out all the tiles you need, the implementation is complicated.
With my second take on grid generation, I tried something different – something that I had hoped would be significantly simpler to implement. Rather than relying on two targets, I could instead use one large target and build a grid from that based on a specified height and width. My original thought process had been that I wanted the user to be able to simply place their cards (which would be scaled relative to the size of a real-life grid tile) on the table and detect them, rather than need to count out the exact size of their grid, but I think that counting x and y dimensions is far from demanding.
As expected, this version was much easier to implement, especially since most of my grid creation code itself was already done. As it stands, it looks alright (ideally the grid’s center would be the target’s center), but larger grids would require either a massive target or that the player be willing to get up and examine the target repeatedly. With that, I opted to see how the grid would work completely targetless using the ground plane object.
Both of these objects appear to be completely misaligned with themselves and the ground. However, the area here is rather featureless, and I suspect that with less intense lighting and a more detailed surface it will function more predictably. I tried using my humanities readings and the smash bros meme from last week laid out near each other on a table to give it some detail, but…
If you can make out the placement marker on the left image, I applaud your impeccable eyesight, because I can’t even with the red box to help me out. The placement marker will shrink or grow depending on how far away the phone believes the surface is, and Vuforia appears to believe the monster can is significantly farther away than the block of text. While I assume this is caused by variations in the levels of detail between the two pages, this inconsistency concerns me. I tried this on several other surfaces later on, and it performed similarly inconsistently on a wooden table, my laptop keyboard, and a patterned couch. I couldn’t even get it to show up on other surfaces, like a floor with large tiles.
Unfortunately, I didn’t make as much progress this week as I would have liked. I’m happy I was able to generate grids in real space, but I hadn’t expected to struggle with stabilization for as much time as I did. For the next week, I’m going to tackle these stabilization issues (even if that means switching APIs again) and I’m going to try and track players’ locations in Unity.