Ashiq's Portfolio
Toggle sidebar
Building Geo+: An AR App Archi...
Article
7 min read

Building Geo+: An AR App Architecture for Teaching Solid Geometry

Augmented Reality Unity Vuforia EdTech Architecture
Building Geo+: An AR App Architecture for Teaching Solid Geometry

Part one covered why AR fits a primary-school geometry lesson better than VR does. This post is about the machinery behind that claim โ€” how Geo+, the AR application reviewed in my third-semester seminar, actually gets a 3D pyramid to appear sitting on a child's desk, and what it lets them do with it once it's there.

The learning objectives came first

Before any architecture, Geo+'s scope was set by three explicit learning objectives, aligned with the Italian Education Department's guidelines for 3rd- and 4th-grade pupils:

  1. Recognize solid figures.
  2. Draw and translate representations of different 3D solids into 2D figures.
  3. Recognize significant features โ€” corners and edges โ€” and each solid's distinctive properties.

That ordering matters as a design lesson on its own: the interaction design (covered below) was built to serve those three objectives directly, not the other way around. An AR geometry tool with flashier features but a looser connection to a specific, teacher-validated curriculum would have been a worse tool, however more impressive the tech demo looked.

The pipeline: marker in, 3D solid out

MARKER โ”€โ”€โ–ถ VUFORIA TRACKER โ”€โ”€โ–ถ UNITY SCENE โ”€โ”€โ–ถ AR DISPLAY
(target      (camera frame,      (GameObjects,     (rendered solid
 image)       image recognition,  scripts,          anchored to the
              pose estimation)    animations)       marker in real time)

Geo+ is built in Unity, with Vuforia as the plugin that does the actual augmented-reality heavy lifting. Vuforia's own internal pipeline is worth understanding on its own terms: a camera frame comes in, gets converted to a usable pixel format, and is handed to a tracker that can recognize image targets, frame markers, multi-image targets, and virtual buttons. The tracker detects new objects, tracks previously-detected ones frame to frame, and evaluates any virtual buttons in view; the application layer queries the resulting state object, updates its own logic, and renders graphics composited over the live camera preview. The printed target image functions purely as a marker โ€” a known, trackable pattern the system can lock onto and use to anchor the 3D content's position and orientation in real space, frame after frame.

Inside the app: Hierarchy and Component

Geo+'s main component, GameSolidiAR, splits cleanly into two halves that map onto how Unity itself organizes a scene:

  • Hierarchy โ€” the graphical elements and GameObjects that populate the scene: the AR camera, the image target, the canvas, the GameObject representing whichever solid is active, buttons, and video playback elements.
  • Component โ€” the scripts that give those objects behaviour: animation and animator controllers, the game controller, UI button handlers, and the video playback controller.

This is a fairly ordinary separation of "what's on screen" from "what makes it behave," but it's worth naming because it's the same separation that shows up in essentially every interactive application, AR or not โ€” data/structure on one side, logic/behaviour on the other. Recognizing that Unity's Hierarchy/Component split rhymes with, say, a web app's view/controller split is exactly the kind of pattern-matching that makes learning one interactive framework faster the second time.

The broader AR-browser pattern the seminar covered

Beyond Geo+ specifically, the seminar looked at how AR browsers and SDKs in general architect the relationship between the app on the device and content hosted elsewhere. A recurring reference model splits responsibility into subsystems โ€” an app-side layer handling interaction, tracking, and presentation, plus a World Model (the actual points-of-interest or content data) and a Context subsystem. Two dominant patterns emerged for wiring those subsystems together:

  • "Gateway" architecture โ€” the AR browser talks to a vendor-run platform server, which acts as a gatekeeper mediating requests out to World Model content published on the open web. This is the more common pattern, largely because it gives the platform vendor a natural point to monetize, while still giving developers a place to publish and test content.
  • "Platform" architecture โ€” a variant where the World Model itself moves inside the vendor's platform rather than living openly on the web. More restrictive for developers, but gives the vendor tighter control over what content actually ships.

Geo+ doesn't need this distinction in its own simple form โ€” its content is bundled with the app rather than fetched from a remote World Model โ€” but understanding the pattern explains why more ambitious AR platforms (the kind that serve dynamic, publisher-updated content to many different client apps) end up looking like a web architecture with a camera bolted on: a gateway, a content host, and a thin client doing the rendering.

What a child actually does with it

The interaction design followed a Human-Centered Design approach, developed through several rounds of qualitative formative testing before the version evaluated in part three. The flow itself is short by design:

  1. Main menu โ€” pupils choose between two groups of solids: the rotating solids (sphere, cylinder, cone) on the left, and the polyhedral solids (cube, parallelepiped, pyramid) on the right.
  2. 3D visualization โ€” once a solid is picked, it appears anchored to the target marker. From here, pupils can zoom in and out, rotate the object, and pause the rotation โ€” pausing specifically to let them count faces, vertices, and edges at their own pace, which maps directly onto learning objective 3.
  3. The unfold sequence โ€” a dedicated button triggers a roughly three-minute video showing the solid's transformation from 3D into its flattened 2D net, built using GeoGebra, a dynamic mathematics tool designed for exactly this kind of visual, manipulable STEM content. The video also shows real physical objects sharing the same shape as the solid on screen, tying the abstract geometry back to the physical world one more time โ€” the situated-learning thread from part one, still running through the interaction design.
  4. On-screen recap โ€” after the unfold sequence, the screen displays direct questions ("How many faces does the pyramid have?") with the answers shown alongside, reinforcing the count the pupil was encouraged to make manually during the pause step.

Every control maps to one of the three stated learning objectives โ€” rotate-and-pause serves recognition and feature-counting, the unfold video serves the 3D-to-2D translation objective directly, and none of it depends on reading skill beyond simple labeled buttons, appropriate for the target age group.

Common pitfalls

  1. Designing features before objectives. Geo+'s interaction set is small and specific because it was built to serve three named learning goals, not to showcase what Vuforia can do.
  2. Ignoring marker-loss behaviour. Marker-based AR breaks immersion hard if the tracked image goes out of frame โ€” a detail easy to overlook until you've watched a real user's hands shake the tablet.
  3. Conflating "Hierarchy" and "Component" concerns. Mixing scene structure and behavioural logic in the same objects is a maintainability trap in Unity just as it is in any UI framework with a similar split.
  4. Skipping the physical tie-back. The unfold video's choice to show real matching objects, not just the abstract net, is what keeps the moment situated rather than purely diagrammatic.
  5. Over-scoping the World Model. For an app this focused, bundling content locally (as Geo+ does) avoids the real architectural complexity of a Gateway/Platform split that only pays off at a much larger content scale.

FAQ

Did you implement Geo+ or write any of its Unity/Vuforia code?
No โ€” this is a review of Rossano and Lanzilotti's published architecture and design description. The pipeline, component split, and interaction flow described here are drawn from their paper, not from code I wrote myself.
Why Vuforia specifically, rather than another AR SDK?
The seminar's source material used Vuforia as Geo+'s tracking plugin; it's a long-standing, Unity-native choice for marker-based tracking, which fits a use case โ€” a printed target image handed out with a tablet โ€” that doesn't need markerless or location-based AR.
Could Geo+'s approach work without a physical printed marker?
Marker-based tracking is simpler to implement reliably than markerless AR, and for a classroom tool distributed with a physical worksheet or card, requiring a printed marker isn't a real limitation โ€” it's a natural fit for how the tool is actually used.
Is the Hierarchy/Component split unique to Unity?
No โ€” it's a specific instance of the very general separation between structure/data and behaviour/logic that shows up across UI frameworks, game engines, and web MVC patterns alike; recognizing the shared shape is more useful than memorizing Unity's particular vocabulary for it.

Interested in AR/interactive app architecture or a full-stack build in Dubai, UAE? Get in touch.