Skip to content

VR authoring, end to end

Unity prefabs in.
Headset-ready training out.

GVR is a VR authoring tool. Your developers publish interactive prefabs from Unity. Your training team drops them onto a 360° scene in the browser and wires the logic visually. Trainees type a short code into a headset and start.

Author in any browser. No headset needed to build one.

  1. Unity
  2. Browser
  3. Headset
  4. Analytics
onDoorOpenADD_SCORE 100code 7K4Q

Where GVR is used and what it replaces

Built for hands-on training in

  • Manufacturing
  • Rail & transit
  • Energy & utilities
  • Healthcare
  • Emergency response
  • Field service
  • 0Unity seats

    for the people who build the training. Authors work in a browser; the engine licence stays with the two developers who need it.

  • 1build, every headset

    The published manifest is the only thing a device downloads. Add a headset to the room and it joins with a code, not an install.

  • 14event types captured

    from session start to scene exit, gaze and grab included — without an LMS integration project standing between you and the data.

The pipeline

Four surfaces. One manifest.

Most VR training tools own one end of the problem — the engine, or the LMS. GVR owns the seam between them. A prefab a developer exports on Monday is on a trainee's head on Tuesday, and the results are on your dashboard by Tuesday night.

  1. 01Unity

    Author the prefab

    Developers build interactive prefabs against the GVR interaction framework — a door that opens, a lever that pulls, a valve that leaks. Export writes an AssetBundle for the headset, a GLB for the browser preview, and a manifest declaring every event and action the prefab exposes.

    hands offbundle + glb + manifest.json

  2. 02Browser

    Build the scenario

    Authors create a Presentation — slides, except each slide is a 3D scene. Drop in a 360° sphere as the environment, drag prefabs on top, place them with the gizmo, then wire the logic: on onDoorOpen add 100 points; on onDoorOpen reveal the extinguisher. No code, no Unity licence.

    hands offpublished build, version 3

  3. 03Headset

    Deliver by code

    Publishing freezes the scenario into an immutable build. Generate an access code and read it out to the room. Trainees type four characters into the headset, it pulls the manifest and only the assets that manifest references, and the module runs. No sideloading, no per-device setup.

    hands offdevice session, streaming

  4. 04Analytics

    See what actually happened

    Every scene entry, gaze, grab, prefab event, action fired and score change comes back with a head pose and a timestamp. Per-participant timelines, per-scene dwell, and a rollup across the whole cohort — so “did the training work” finally has an answer.

    outputrollups, exports, pass rates

What you get

Everything between the prefab and the report

GVR is not a headset app with a web dashboard bolted on. The authoring tool, the runtime contract and the analytics were designed against one another.

  • 360° environments

    Upload an equirectangular photo or video and it becomes the world. The scene renders it on the inside of a sphere, so what you place in the editor is exactly where the trainee sees it.

    SKYBOX_360 · COLOR · MODEL

  • Drag-and-drop authoring

    A scene rail of slides down the left, a live 3D viewport in the middle, an inspector on the right. Drag from the library onto the canvas, then move, rotate and scale with a real gizmo — or type exact numbers.

    W / E / R · snap · undo

  • Visual action logic

    Pick an object, pick one of the events its prefab declares, then stack the steps that follow: add score, reveal an object, jump to a scene, invoke an action back on the prefab. Ordered, delayable, no code.

    15 step types · conditions

  • Prefab library

    Every prefab your developers publish lands in one shared, versioned library with a thumbnail, a web preview mesh and its declared events and actions. Authors reuse; they never rebuild.

    versioned · org-scoped

  • Delivery by code

    Publish a build, generate a code, hand it out. The headset redeems it for a device session and pulls only the assets that build references. Codes expire, cap redemptions, and can be revoked mid-session.

    TEST + TRAINING codes

  • Training analytics

    Gaze, grab, release, prefab events, actions fired, answers, hints and scores — timestamped and tied to a participant. Roll it up per session, per scene, or across a cohort.

    per-scene dwell · pass rates

For developers

Your prefab is the API

GVR does not ask your developers to learn an authoring tool. It asks them to export a prefab that describes itself — and everything the training team can build is generated from that description.

Declare, do not document
Attribute a C# method and it becomes an action. Raise a GVR event and it becomes an event. The export writes both into the manifest, so the authoring UI can only ever offer authors things your prefab genuinely does.
Two artefacts, one export
An AssetBundle for the headset runtime and a GLB for the browser preview, built from the same prefab in the same pass. Authors get a real mesh to place; the trainee gets the real thing.
Versioned, never overwritten
Every export is a new version. Published builds pin the version they were authored against, so shipping v5 of a door cannot change a scenario that went live on v4.
Read the developer guide
fire-door-type-b/manifest.jsonjsonc
{
  "manifestVersion": 1,
  "name": "Fire Door, Type B",
  "slug": "fire-door-type-b",
  "version": 4,
  "unityVersion": "2022.3.44f1",
  "targetPlatforms": ["android-quest", "windows-openxr"],
  "bundleKey": "prefabs/fire-door-type-b/4/bundle.unity3d",
  "glbKey": "prefabs/fire-door-type-b/4/preview.glb",

  // What the prefab can TELL the scenario.
  "events": [
    { "key": "onDoorOpen", "label": "Door opened" },
    { "key": "onDoorClosed", "label": "Door closed" },
    { "key": "onHandleGrab", "label": "Handle grabbed",
      "payloadSchema": { "hand": "left | right" } }
  ],

  // What the scenario can TELL the prefab.
  "actions": [
    { "key": "OpenDoor", "label": "Open door" },
    { "key": "LockDoor", "label": "Lock door",
      "paramsSchema": { "durationMs": "number" } }
  ]
}

This file is the whole contract. The portal reads it to populate the event dropdown in the Actions tab; the headset runtime reads it to know which action keys it can be asked to invoke.

Pricing

Priced per organization, not per headset

Headsets get bought and reallocated; charging by device makes a training programme expensive to grow. Every plan includes unlimited trainees.

  • Studio

    Freewhile you evaluate

    Enough room to import a prefab, build a real scenario and try it on a headset before anyone signs anything.


    • 3 authors in one organization
    • 5 presentations, 10 prefabs
    • 25 GB of assets
    • TEST access codes
    • 30 days of analytics retention
    Create an account
  • Most teams start here

    Team

    $390per month, billed annually

    For a training function that runs real cohorts on a schedule and needs the results afterwards.


    • Unlimited authors and presentations
    • Unlimited prefabs, 500 GB of assets
    • TRAINING codes and scheduled sessions
    • Owner / Admin / Author / Viewer roles
    • 12 months of analytics retention
    • Per-participant timelines and cohort rollups
    Start with Team
  • Enterprise

    Customannual agreement

    For organizations with several training functions, a compliance team, and opinions about where the data lives.


    • Multiple organizations under one agreement
    • Choice of asset storage region
    • Custom analytics retention and export
    • Unity SDK onboarding for your engineers
    • Priority support with a named contact
    Talk to us

Full plan comparison and FAQ

Put a prefab on a headset this week

Create an organization, upload one prefab, build one scene, generate a test code. That is the whole loop, and it takes an afternoon.

Email and password. No card, no sales call.