For my submission, the requirement of having multiple markers is met through having one marker that can be modified to allow the user to view what they perceive to be the same model in different ways.
The workflow resulting in the final marker was as such:
A normal marker looks like this, and represents only one model in BuildAR:
For this project, I had the idea of being able to break up a marker into pieces that can be replaced to give the appearance of change in the viewed model:
The idea refined to a larger marker (double usual size) to help with handling its pieces. Note the holes in the back of the marker that let me poke the pieces out instead of potentially damaging them by picking at them with my nail until they come loose.
However, the first try had too many fiddly details for BuildAR to easily distinguish from one another, so I simplified it to this:
The idea was refined somewhat by considering the marker interacting with BuildAR as a "finite state automaton" controlled by the user. The idea works by setting the "state" of the marker, and letting BuildAR react accordingly to that state. For each state you want BuildAR to react to, you need a different model associated with a marker image in that given state. Unfortunately, since this means you need several different models loaded into BuildAR, this idea can very quickly start to take up a lot of RAM.
No comments:
Post a Comment