Skip to main content
This page describes how VR training content is structured in the Molca VR SDK: configuration modules, scenario data and runtime, then either activities and steps (simulation) or tour areas and spots (tour). It complements VR architecture with a content tree. Product: Molca VR SDK (_MolcaSDK/_VR). Molca Core supplies Step and SequenceController; the Digital Twin SDK does not use this scenario model (DT overview).

End-to-end hierarchy

Dependency direction: modules register where scenarios live and how the app boots; scenario data selects simulation vs tour and is referenced by ScenarioManager; simulation drives ordered activities and steps; tour drives TourSubsystem (areas and spots), not the sequence graph.

1. Modules and settings

Other SettingModule types may appear in the same bag for media, modals, or networking; ScenarioDataConfig is the one most authors touch for which scenarios exist in the build or after a content fetch. Together, these are the module layer: they are not gameplay sequences themselves, but they wire the app to scenario assets and session behavior.

2. Scenario (asset and runtime)

  • Asset: BaseScenarioData in Scenario/Data/ — concrete types include SimulationScenarioData and TourScenarioData (see VR architecture glossary).
  • Runtime: ScenarioManager holds scenarioData, activities (used for simulation), timers, pause, and session hooks.
  • Branching: Scenario mode drivers implement simulation vs tour lifecycle (SimulationScenarioModeDriver vs TourScenarioModeDriver) so the manager stays a single orchestration point.
Simulation scenarios attach time limits and activity lists on the data side where applicable; tour scenarios pair with TourSubsystem for world navigation.

3a. Simulation: activity → step

Simulation training is sequential: users complete activities, each backed by a Molca Core sequence. Typical author flow: define scenario data → place ScenarioManager + ScenarioActivity entries in the scenario scene → assign root steps under each activity → add VR Step components for grabs, valves, teleports, etc.

3b. Tour: area → spot (not step-based)

Tour uses exploration, not the same activity/step graph as simulation. Progress and session posting still go through the same scenario/session stack; the mode driver routes lifecycle into TourSubsystem instead of stepping activities.

Simulation vs tour (quick comparison)