# Building Digital Twins with Unity and realvirtual.io Welcome to the realvirtual.io documentation Welcome to realvirtual.io, the ultimate framework for Automation Concept Design, Simulation, Virtual Commissioning, and 3D Human-Machine Interface (HMI) development based on Unity. We've combined the power of Unity with the flexibility of realvirtual.io to empower you to create stunning 3D models for various destination platforms, including Windows, Linux, MacOS, iOS, Web GL, and Android. Want to learn more about Digital Twins and the theoretical concepts behind them? Check out this free eBook:\\

eBook - Building scalable industrial digital twins with Unity

{% embed url="" %} If you want to see it in action without any installation,\ you can check out the demo model as a WebGL build here: {% embed url="" %} {% hint style="info" %} Formerly known as game4automation, we have rebranded our product to realvirtual. {% endhint %} With realvirtual.io you can build models like this:

Digital twin runtime ui

### Getting Started To embark on your realvirtual.io journey, follow these initial steps: 1. **Install Unity and realvirtual.io**: Refer to the installation instructions for a seamless setup. 2. **Explore the Demo Scene**: Open the demo scene and run the demo model to get a firsthand look at what you can achieve with realvirtual.io. 3. **Model Building Basics**: Learn how models are structured and discover the components used in the "How to build models like this" section. 4. **Conveyor Motion and Sensor Attachment**: Check out the tutorial on making a simple conveyor move and attaching a sensor for interactive functionality. 5. **User Interface, Asset Structure, and Physics**: Dive into the basics of the User Interface, Asset Structure, and Physics. These are essential aspects covered under the "Basics" section and can be further explored in the demo model. 6. **Explore Tutorials and Demos on YouTube**: Find more helpful tutorials and demonstrations on our YouTube channel. ### Our AI digital twin assistant for GPT4 users If you are GPT4 user you can use our special training GPT. {% embed url="" %} realvirtual.io Digital Twin Assistant {% endembed %} ### realvirtual.io Community on NPM Join our community on NPM to access additional assets and examples at[ ](https://www.npmjs.com/package/com.realvirtual.community). This platform also welcomes you to contribute and share your own assets with fellow realvirtual.io users.. ### To get support If you require assistance, encounter a bug, or have specific requests, please utilize our support resources: * **Support Forum**: For a collaborative learning experience, visit our support forum at [realvirtual.io Forum](https://forum.realvirtual.io/). Engaging on the public forum allows others to learn alongside you. ### For developers Developing with Unity is a dynamic and thriving experience, supported by an active developer community. Before diving into realvirtual.io specifics, we recommend exploring these valuable resources: * **Unity Documentation**: For comprehensive guidance, refer to the [Unity documentation](https://docs.unity3d.com/Manual/index.html). * **Video Tutorials**: If you prefer video-based learning, check out [Unity's video tutorials](https://unity3d.com/de/learn/tutorials). * **Unity Forum**: Engage with the Unity community on the [Unity Forum](https://forum.unity.com/) to find solutions and insights into game development. * **realvirtual.io Class documentation:** After gaining a solid understanding of Unity fundamentals through these resources, consult the "Starting your development" section for crucial information on organizing your project and commencing your own development within realvirtual.io. Thank you for choosing realvirtual.io as your Automation Concept Design and Simulation solution. We look forward to supporting your creative journey in the world of 3D modeling and virtual commissioning. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Installation Installing realvirtual.io and Unity Before you dive into the world of realvirtual.io, you'll need to set up your development environment correctly. Here's a step-by-step guide to get you started. ## realvirtual.io 6.3 (Unity 6.3 LTS) {% hint style="success" %} **Supported Unity Version**: realvirtual.io 6.3 requires **Unity 6.3 LTS** (version number **6000.3** in Unity Hub). {% endhint %} {% hint style="info" %} Starting with version 6.3, realvirtual is distributed as **Unity Package Manager (UPM) packages** (`io.realvirtual.starter`, `io.realvirtual.professional`). The installation depends on where you purchased realvirtual — see Step 3 below. {% endhint %} {% hint style="info" %} **Automatic Configuration**: For new installations, [Project Settings](/basics/project-settings) are applied automatically in the background to optimize your Unity project for industrial automation. For updates to existing projects, a dialog will appear asking if you want to apply these settings. {% endhint %} ### Step 1: Install Unity 6.3 LTS Install **Unity 6.3 LTS** through the Unity Hub. In Unity Hub, the version number is displayed as **6000.3** (e.g., 6000.3.5f1). For detailed instructions, refer to Unity's official installation guide. {% embed url="" %} Unity 6 Installation guide {% endembed %} ### Step 2: Create a New Unity Project 1. Open **Unity Hub** and click **New project**. 2. Select **Universal 3D** under Core templates to use the Universal Render Pipeline (URP). 3. Set a project name and choose a location for the project folder. 4. Ensure **Editor version 6000.3** (Unity 6.3 LTS) is selected. 5. Click **Create project**.

Creating a new Universal 3D project with Unity 6.3 LTS

### Step 3: Install realvirtual Packages The installation depends on where you purchased realvirtual. Choose the section that applies to you. #### Purchased from the Unity Asset Store 1. Open **Window > Package Manager** in Unity. 2. Select **My Assets** in the left panel. 3. Find **realvirtual Starter** (and **realvirtual Professional** if purchased) and click **Download**. 4. After downloading, click **Import** to install the UPM packages into your project. #### Purchased directly from realvirtual.io For your first installation, download the `.tgz` package files from the **realvirtual Customer Portal**. The link and login credentials are provided on your invoice. After downloading, install the packages in Unity: 1. Open **Window > Package Manager**. 2. Click the **+** button in the top-left corner and select **Install package from tarball...**.

Install package from tarball in Package Manager

3. Navigate to the downloaded `.tgz` file and select **io.realvirtual.starter** first.

Select the starter package tarball file

4. Wait for the import to complete. This may take a few minutes. 5. Repeat the process for **io.realvirtual.professional** if you purchased the Professional edition.

realvirtual Professional installed via tarball in Package Manager

**Setting Up User Hub for Future Updates** After installing the packages, the **realvirtual** menu appears in the Unity menu bar. Use the built-in **User Hub** to manage updates: 1. Go to **Tools > realvirtual > User Hub** in the Unity menu.

Open User Hub from the realvirtual menu

2. In the **Login** tab, enter your **Invoice Number**, **Billing ZIP Code**, and **Email**. Click **Login**.

User Hub login with invoice credentials

**Activate UPM Registry (Recommended)** To receive automatic update notifications, activate the realvirtual UPM Registry: 1. In User Hub, go to the **Packages** tab. 2. Click **Activate UPM Registry**.

Activate UPM Registry in the Packages tab

3. Unity will add a scoped registry to your **Project Settings > Package Manager** and show a confirmation dialog.

Scoped registry added to Project Settings

4. Future updates will now appear automatically in the Package Manager under **My Registries**. Use **Check for Updates** in User Hub to verify. **Manual Updates via Tarball** Alternatively, you can download newer versions from the **Downloads** tab in User Hub (or from the Customer Portal) and install them via **Install package from tarball** as described above.

Download packages from the User Hub Downloads tab

### Step 4: Handle Signature Warnings {% hint style="warning" %} When installing packages from the Customer Portal or User Hub (not from the Asset Store), Unity may show a **Missing Signature** or **Invalid Signature** warning. This is expected — realvirtual packages distributed outside the Asset Store are not Unity-signed. It is safe to click **Close** and continue. {% endhint %}

Missing Signature warning — safe to close

Invalid Signature warning — safe to close

### Step 5: Import Demo Scenes After installation, a dialog will ask if you want to import the **Getting Started** demo scene. Click **Import Now** to get started right away.

Import the Getting Started demo scene

You can import additional demo categories at any time using two methods: **Via Package Manager:** Select **realvirtual Starter** (or Professional) in the Package Manager, go to the **Samples** tab, and click **Import** for the demo categories you want.

Import demo scene categories from the Samples tab

**Via Demo Scenes Browser:** Go to **Tools > realvirtual > Demo Scenes Browser** in the Unity menu. This window shows all available demo scenes organized by category with descriptions.

Open Demo Scenes Browser from the realvirtual menu

Demo Scenes Browser with categories and scene descriptions

### Step 6: Explore the Demo Scene The Getting Started demo scene opens automatically after import. It showcases a complete automation cell with conveyors, a robot, sensors, and a machine — all working together.

realvirtual 6.3 demo scene

Press **Play** in the Unity Editor to start the simulation and see the automation in action. ### Possible Problems and Fixes #### Wrong Input System If you see red error messages in the **Console** related to the Input System, make sure that the **Active Input Handling** in **Project Settings > Player > Configuration** is set to **Both (old and new Input System)**. #### Wrong Render Pipeline If your demo scene appears pink, you may be using the wrong render pipeline. We recommend switching to the **Universal Render Pipeline (URP)**. See [Render Pipelines](/advanced-topics/render-pipelines) for details. #### TextMesh Pro Essentials Not Imported If you encounter problems with text in the Runtime UI, go to **Window > TextMeshPro > Import TMP Essential Resources** to install the required components. ### (Optional) Clean Up Unnecessary Unity Demo Folders To keep your project clean, you can delete Unity's default demo assets if present: * **Scenes** * **Settings** * **TutorialInfo** *** ## Upgrading from realvirtual 6.0 to 6.3 If you have an existing project using **realvirtual 6.0.x** (the `.unitypackage` version), follow these steps to migrate to the new UPM package format. {% hint style="warning" %} **Important: Two-Step Process** — First upgrade Unity, then upgrade realvirtual. Do not attempt both simultaneously. {% endhint %} ### Step 1: Upgrade Unity to 6.3 LTS 1. Open **Unity Hub** and change the **Editor Version** of your project to **6000.3** (Unity 6.3 LTS). 2. Accept any compatibility warnings and let Unity convert your project. ### Step 2: Remove the old realvirtual folder 1. **Close Unity** completely. 2. Delete the **Assets/realvirtual** folder from your project directory (this is the old `.unitypackage` content). 3. Delete the **Library** folder to force Unity to regenerate all cached metadata. {% hint style="info" %} **Don't worry about references!** All references in your scenes and prefabs are preserved. Unity maintains them through GUIDs, even when folders are deleted and reimported from a different location. {% endhint %} ### Step 3: Install the UPM packages 1. Reopen your project in Unity 6.3 LTS. You will see compilation errors — this is expected. 2. Install the new UPM packages following **Step 3** from the [installation instructions above](#step-3-install-realvirtual-packages) (either via Asset Store or Customer Portal tarball). 3. After the packages are installed, compilation errors should be resolved. ### Step 4: Verify the upgrade 1. Check the **Console** window for any remaining errors. 2. Open one of your scenes and verify that all components, references, and materials are intact. 3. If materials appear pink, go to **Tools > realvirtual > Settings > Switch to Universal Render Pipeline (URP)** to convert them. {% hint style="success" %} After upgrading, you can use the [User Hub](#setting-up-user-hub-for-future-updates) to set up the UPM Registry for future automatic updates. {% endhint %} *** ## realvirtual.io 6.0 (Unity 6 — .unitypackage) {% hint style="warning" %} This section covers the **legacy .unitypackage** installation for realvirtual 6.0.x. For version 6.3 and later, follow the UPM instructions above. {% endhint %} {% embed url="" %} Tutorial realvirtual.io 6 and Unity 6 Installation {% endembed %} ### Step 1: Install Unity 6 LTS Install **Unity 6000.0 LTS** (Unity 6) through the Unity Hub. ### Step 2: Create a New Unity Project 1. Open **Unity Hub**. 2. Select **Universal 3D** under Core templates. 3. Ensure **Editor version 6000.0 LTS** is selected. 4. Click **Create Project**.
### Step 3: Install realvirtual.io 6 * **Direct Purchase from realvirtual.io**: 1. Download the `realvirtual.unitypackage` file from your account on the realvirtual.io download website. 2. Drag and drop the file into the Unity Project window, or go to **Assets > Import Package > Custom Package**. * **Unity Asset Store**: 1. Open **Window > Package Manager**. 2. Under **My Assets**, locate **realvirtual.io 6** and click **Download**, then **Import**. When prompted about a **URP Upgrade**, select **Install / Upgrade**.

Installation Warning

Import Unity Package

After import, the demo scene opens automatically.

Demo scene after installation

### Possible Problems and Fixes See the [problems and fixes section above](#possible-problems-and-fixes) — the same issues and solutions apply. *** ## realvirtual.io 2022 and before ### 1. Install Unity If you haven't already, install Unity on your computer. Unity offers both free and licensed versions, depending on your use case. Check Unity's official website [here](https://store.unity.com/) to determine which version suits your needs. {% embed url="" %} Installation of realvirtual.io 2022 (old deprecated version) {% endembed %} > Our new releases is always based on the latest Unity Long Term stable release. Our main version number (e.g. 6) always corresponds to the Unity version number. For example to run realvirtual.io 2022.09 you need Unity 2022.03 LTS. ### 2. Unity Hub (Recommended) We highly recommend installing Unity Hub, a tool that simplifies managing multiple projects and Unity installations. You can download Unity Hub from Unity's official download pages. ### 3. Create a New Project Launch Unity and create a new empty project by selecting "New." Choose a location on your computer to store your project files and give your project a name. Then, click "Create Project." When prompted to choose a template, select the standard 3D template. This will form the foundation of your project:

Creating a new Unity Project with the Unity Hub

### 5. Ensure .Net Standard Framework 2.1 and Mono are Enabled By default, Unity should have .Net Standard 2.1 and Mono enabled. However, in some cases, especially when integrating realvirtual.io into an older project, this setting might be incorrect. To confirm or change this setting: * Go to Player Settings by selecting "Build Settings" > "Player Settings." * Under "Configuration," change the Scripting Runtime Version to ".NET Standard 2.1" For the scripting backend, it's recommended to start with Mono rather than IL2CPP, as Mono typically compiles much faster.

Selecting the .Net Standard 2.1 in the Unity Player Project Settings

### 6. Acquire realvirtual.io Go to the Unity Asset Store and purchase the version of realvirtual.io that suits your needs, whether it's Lite or Professional. ### 7. Import realvirtual.io You can import realvirtual.io directly from the Unity Asset Store or manually download the asset. To install it manually, follow these steps: * From the main menu, go to "Assets" > "Import Package" > "Custom Package..." * A new window will appear, displaying the contents of the realvirtual.io package. Select "All" and click "Import."

Import custom package

This will show a new window with all the realvirtual.io package contents: ![](/files/6HJLa8yagUmbBJqYI3Hk) Please select *All* and *Import*. ### 8. Verify Installation After importing the realvirtual.io package, check for the following: * You should see an additional "realvirtual" folder (previously "game4automation" before 2022) in your project structure. * A new "realvirtual" menu should be available in the main menu bar.

Project view after realvirtual.io installation

### 9. Set Standard Settings {% hint style="info" %} Usually, standard settings are applied automatically after a fresh installation or update of realvirtual.io. However, if you encounter compile errors in the console window, it may be due to conflicts between your existing project assets and realvirtual.io. {% endhint %} In such cases: * Address the compile errors first to ensure there are none remaining. * Once errors are resolved, apply the standard settings by selecting "realvirtual" > "Apply Standard Settings" from the main menu. Applying standard settings will configure: * Standard layer naming (for physics). * Standard physics collision matrix. * Standard light settings. Congratulations! You've now completed the installation process and are ready to explore the Demomodel outlined in the documentation. # Editions: Starter vs Professional Feature overview of realvirtual Starter and Professional realvirtual.io ships in two editions that share the same core engine and the same project format. **Starter** gives you the complete simulation core — drives, sensors, transport, grippers, MUs and logic — everything you need to build and run a digital twin. **Professional** adds the productivity tools, the full industrial interface library, robotics, the HMI suite and realvirtual WEB on top. A project always opens in either edition. Anything you build in Starter keeps working when you move up to Professional — Professional is purely additive. {% hint style="info" %} Both editions run on the same Unity version and use the same scene and prefab format. Upgrading from Starter to Professional only adds the `io.realvirtual.professional` package — no migration is required. {% endhint %} ## Which edition do I need? * **Starter** — Build and simulate machines and lines, define logic, import geometry, and publish to Windows or WebGL. Ideal for concept design, training and standalone simulations. * **Professional** — Add virtual commissioning against real PLCs and robot controllers, CAD import with live update, robot inverse kinematics, performance tooling for large assemblies, the 3D-HMI suite, multiplayer and realvirtual WEB. {% hint style="success" %} Throughout the documentation, Professional-only features are marked with a **(Pro)** suffix in the page title and a hint box at the top of the page. {% endhint %} ## Core simulation | Feature | Starter | Professional | | ---------------------------------------------------------------------------------------------------- | :-----: | :----------: | | [Drives, CAM & Kinematic](/components-and-scripts/motion) | ✅ | ✅ | | [Sensors & Measurement](/components-and-scripts/sensors) | ✅ | ✅ | | [TransportSurface & Guided Transport](/components-and-scripts/motion/transportsurface) | ✅ | ✅ | | [Chain & Chain Element](/components-and-scripts/motion/chain) | ✅ | ✅ | | [MU, Source & Sink](/components-and-scripts/mu-movable-unit) | ✅ | ✅ | | [Picking & Placing (Grip, Gripper, Fixer, Pattern)](/components-and-scripts/picking-and-placing-mus) | ✅ | ✅ | | [Changing MUs (Material, Switcher, Part, Cutter)](/components-and-scripts/changing-mus) | ✅ | ✅ | | [PathTracer](/components-and-scripts/motion/path-tracer) | — | ✅ | | [KinematicMU](/components-and-scripts/motion/kinematicmu-pro) | — | ✅ | | [Volume Tracking](/components-and-scripts/volume-tracking-pro) | — | ✅ | ## Logic & interaction | Feature | Starter | Professional | | -------------------------------------------------------------------------------------------------------------------------- | :-----: | :----------: | | [Unity Scripting](/components-and-scripts/defining-logic/unity-scripting) | ✅ | ✅ | | [Behavior Graph](/components-and-scripts/defining-logic/behavior-graph) | ✅ | ✅ | | [LogicSteps](/components-and-scripts/defining-logic/logicsteps) | ✅ | ✅ | | [Recorder](/components-and-scripts/defining-logic/recorder) | ✅ | ✅ | | [3D Buttons & Screen Overlay Buttons](/components-and-scripts/scene-interaction/3d-buttons) | ✅ | ✅ | | [Lamp, Interact3D, KeyboardMove](/components-and-scripts/scene-interaction) | ✅ | ✅ | | [Tooltip](/components-and-scripts/scene-interaction/tooltip-pro) | — | ✅ | | [Scene Selectables](/components-and-scripts/scene-interaction/scene-selectables-pro) | — | ✅ | | [State Statistics](/components-and-scripts/scene-interaction/state-statistics) | — | ✅ | | [HMI Components (Tab, Pushbutton, Switch, Value, Slider, …)](/components-and-scripts/scene-interaction/hmi-components-pro) | — | ✅ | | [ModelZoo](/components-and-scripts/scene-interaction/modelzoo-pro) | — | ✅ | ## Editor tools | Feature | Starter | Professional | | ------------------------------------------------------------------------- | :-----: | :----------: | | [Hierarchy Window & Quick Edit](/basics/user-interface/quick-edit) | ✅ | ✅ | | [Demo Scenes Browser](/basics/user-interface/demo-scenes-browser) | ✅ | ✅ | | [Model Checker](/basics/user-interface/model-checker) | ✅ | ✅ | | [Recent Items](/basics/user-interface/recent-items-pro) | — | ✅ | | [Move Pivot Points](/basics/user-interface/move-pivot-points-pro) | — | ✅ | | [Selection Window](/basics/user-interface/selection-window) | — | ✅ | | [Material Window](/basics/user-interface/material-window-pro) | — | ✅ | | [Measurement](/basics/user-interface/measurement-pro) | — | ✅ | | [Kinematic Tool](/basics/user-interface/kinematic-tool-pro) | — | ✅ | | [Clean Restart](/basics/user-interface/clean-restart-pro) | — | ✅ | | [Duplicate Finder](/basics/user-interface/duplicate-finder) | — | ✅ | | [Mesh Tools](/basics/user-interface/mesh-tools) | — | ✅ | | [Group Assignment Tool](/basics/user-interface/group-assignment-tool-pro) | — | ✅ | ## CAD & performance | Feature | Starter | Professional | | -------------------------------------------------------------------------------------------- | :-----: | :----------: | | [Importing & Exporting (FBX, STEP via Unity, …)](/basics/importing-and-exporting) | ✅ | ✅ | | [Cadenas parts4cad](/basics/cadenas-parts4cad) | ✅ | ✅ | | [CADLink (direct CAD import)](/basics/cad-import/cadlink) | — | ✅ | | [CAD Checker](/basics/cad-import/cad-checker) | — | ✅ | | [CAD Updater](/basics/cad-import/cad-updater) | — | ✅ | | [Combine Meshes](/components-and-scripts/performance-tools/combine-meshes-pro) | — | ✅ | | [Mesh Optimizer](/components-and-scripts/performance-tools/mesh-optimizer-pro) | — | ✅ | | [Hierarchy Cleanup](/components-and-scripts/performance-tools/hierarchy-cleanup-pro) | — | ✅ | | [Create Prefab](/components-and-scripts/performance-tools/create-prefab-pro) | — | ✅ | | [Performance Optimizer](/components-and-scripts/performance-tools/performance-optimizer-pro) | — | ✅ | ## Robotics | Feature | Starter | Professional | | ---------------------------------------------------------------------------- | :-----: | :----------: | | [Robot Inverse Kinematics](/components-and-scripts/robot-inverse-kinematics) | — | ✅ | | [Robot Program Export (Beta)](/components-and-scripts/robot-program-export) | — | ✅ | ## Collaboration & web | Feature | Starter | Professional | | ------------------------------------------------------------------ | :-----: | :----------: | | [Publishing (Windows, WebGL)](/basics/publishing-the-digital-twin) | ✅ | ✅ | | [Multiplayer](/components-and-scripts/multiplayer-pro) | — | ✅ | | [realvirtual WEB (browser 3D-HMI)](/extensions/realvirtual-web) | — | ✅ | ## Interfaces The signal layer and the basic interface tooling are in Starter; the industrial protocol and controller interfaces are Professional. | Feature | Starter | Professional | | -------------------------------------------------------------------------------------------------- | :-----: | :----------: | | [Signal Manager & Signal Tools](/components-and-scripts/interfaces/interface-tools/signal-manager) | ✅ | ✅ | | [Signal Importer / Exporter](/components-and-scripts/interfaces/signal-importer-exporter) | ✅ | ✅ | | [S7 TCP](/components-and-scripts/interfaces/s7-tcp) | ✅ | ✅ | | [FMI](/components-and-scripts/interfaces/fmi) | ✅ | ✅ | | [OpenCommissioning](/components-and-scripts/interfaces/opencommissioning) | ✅ | ✅ | | [Igus Rebel](/components-and-scripts/interfaces/igus-rebel) | ✅ | ✅ | | [Custom Interfaces (FastInterface)](/components-and-scripts/interfaces/custom-interfaces) | ✅ | ✅ | | [OPC UA](/components-and-scripts/interfaces/opcua) | — | ✅ | | [Modbus](/components-and-scripts/interfaces/modbus) | — | ✅ | | [MQTT](/components-and-scripts/interfaces/mqtt) | — | ✅ | | [EthernetIP](/components-and-scripts/interfaces/ethernetip) | — | ✅ | | [UDP](/components-and-scripts/interfaces/udp-pro) | — | ✅ | | [Websocket](/components-and-scripts/interfaces/websocket-pro) | — | ✅ | | [TwinCAT (ADS)](/components-and-scripts/interfaces/twincat) | — | ✅ | | [TwinCAT HMI](/components-and-scripts/interfaces/twincat-hmi) | — | ✅ | | [PLCSIM Advanced](/components-and-scripts/interfaces/plcsim-advanced) | — | ✅ | | [Siemens Simit](/components-and-scripts/interfaces/siemens-simit-interface-pro) | — | ✅ | | [Simit Shared Memory](/components-and-scripts/interfaces/simit-shared-memory) | — | ✅ | | [Bosch Rexroth ctrlX](/components-and-scripts/interfaces/ctrlx) | — | ✅ | | [Festo AX Controls / PLCnext](/components-and-scripts/interfaces/festo-plcnext) | — | ✅ | | [SEW SimInterface](/components-and-scripts/interfaces/sew-siminterface-pro) | — | ✅ | | [Simulink](/components-and-scripts/interfaces/simulink) | — | ✅ | | [Windmod Y200](/components-and-scripts/interfaces/windmod-y200-pro) | — | ✅ | ### Robot controllers | Feature | Starter | Professional | | ------------------------------------------------------------------------- | :-----: | :----------: | | [ABB RobotStudio](/components-and-scripts/interfaces/abb-robotstudio) | — | ✅ | | [KUKA](/components-and-scripts/interfaces/kuka) | — | ✅ | | [Fanuc](/components-and-scripts/interfaces/fanuc-pro) | — | ✅ | | [Denso Robotics](/components-and-scripts/interfaces/denso-robotics-pro) | — | ✅ | | [Mitsubishi McpX](/components-and-scripts/interfaces/mitsubishi-mcpx) | — | ✅ | | [Universal Robots](/components-and-scripts/interfaces/universal-robots) | — | ✅ | | [Keba](/components-and-scripts/interfaces/keba-interface) | — | ✅ | | [RoboDK](/components-and-scripts/interfaces/robodk) | — | ✅ | | [Wandelbots Nova](/components-and-scripts/interfaces/wandelbots-nova-pro) | — | ✅ | | [RFSuite](/components-and-scripts/interfaces/rfsuite-pro) | — | ✅ | ## Updates & support | Feature | Starter | Professional | | ------------------------------------------------------------------------------------------- | :-----: | :----------: | | [Customer Portal](/basics/customer-portal) | ✅ | ✅ | | [Login & Download Updates (User Hub, UPM Registry)](/basics/login-and-download-updates-pro) | — | ✅ | ## Upgrading from Starter to Professional To move from Starter to Professional, add the `io.realvirtual.professional` package next to your existing `io.realvirtual.starter` package — follow the same steps as in the [Installation](/basics/installation) guide. Your scenes, prefabs and references are preserved automatically. ## See Also * [Installation](/basics/installation) * [Release Notes](/release-notes) * [License Conditions](https://realvirtual.io/en/license-conditions/) # Project Settings Unity project configuration optimized for industrial automation with realvirtual framework. ## Overview The Apply Standard Settings feature configures Unity projects with optimal settings for industrial automation development. These settings ensure the best performance, stability, and user experience when working with realvirtual components. {% hint style="info" %} **Automatic Application**: Standard settings are usually applied automatically after a fresh installation or update of realvirtual.io. However, if you encounter compile errors, you may need to apply them manually. {% endhint %} ## When to Apply Settings Manually ### After Resolving Compile Errors If you encounter compile errors in the console window, it may be due to conflicts between your existing project assets and realvirtual.io: 1. **Address compile errors first** to ensure there are none remaining 2. Once errors are resolved, apply the standard settings by selecting **"realvirtual" > "Apply Standard Settings"** from the main menu ### Manual Application You can manually apply these settings at any time through the realvirtual menu: 1. Go to **realvirtual** menu in Unity's main menu bar 2. Select **"Apply Standard Settings"** 3. Confirm the application when prompted
Recommended Project Settings Dialog

Dialog asking to apply standard realvirtual project settings for optimal automation configuration

{% hint style="warning" %} **Use Carefully for Existing Projects**: The Recommended Project Settings feature makes significant changes to Unity project configuration. Review the changes carefully before applying to existing projects. {% endhint %} ## Settings Applied Applying standard settings will configure: * **Standard layer naming** (for physics) * **Standard physics collision matrix** * **Standard light settings**
Applied Settings Summary

Summary of successfully applied settings showing layers, scene view, build settings, physics, and performance optimizations

### Additional Optimizations The system also configures additional Unity settings for optimal industrial automation performance: #### Project Structure * **Layers & Collision Matrix**: Configured for automation components * **Scene View Optimization**: Hierarchy collapsed, shaded mode enabled * **UI Layer Management**: Hidden from Tools visibility for cleaner interface #### Development Tools * **Transform Tools**: Move tool active with Pivot/Local mode enabled * **realvirtual Tools**: QuickEdit toolbar and overlay enabled * **Script Icons**: Configured in Gizmos folder for better visual identification #### Build & Runtime Settings * **Build Settings**: Linear color space, Mono backend, .NET Standard 2.0 * **Physics Optimization**: 50Hz update rate with improved solver accuracy * **Performance Settings**: VSync disabled, background execution enabled ## Detailed Logging The Console provides detailed information about each change made during the configuration process:
Console Log Details

Console log showing detailed information about each setting applied, including specific Unity menu paths

The console log shows: * Timestamped entries for each change * Specific Unity menu paths for verification * Confirmation of successful application * Reference information for troubleshooting ## Benefits ### Performance Optimization * **Physics Settings**: Optimized for industrial simulation accuracy * **Rendering**: Linear color space for better visual quality * **Background Execution**: Continuous operation when Unity loses focus ### Development Experience * **Clean Interface**: Optimized tool visibility and organization * **Efficient Workflow**: Pre-configured tools and shortcuts * **Visual Clarity**: Better scene organization and component identification ### Industrial Automation Focus * **Collision Management**: Proper layer setup for automation components * **Precision**: Enhanced physics solver for accurate movement * **Compatibility**: .NET Standard 2.0 for broader platform support ## See Also * [Installation Guide](https://github.com/game4automation/doc/blob/doc/installation.md) - Complete installation process * [Project Path Display](https://github.com/game4automation/doc/blob/doc/user-interface/project-path-display.md) - Toolbar project path feature * [Quick Edit](https://github.com/game4automation/doc/blob/doc/user-interface/quick-edit.md) - Quick edit overlay menu # Demo Model First experiences with realvirtual.io based on the demo model {% hint style="info" %} This section describes the new demo model since version 6.1.0. For a description of the old demo model, which is still included in current releases, please check page [**Old Demo Model**](/basics/demo-model/demo-model) {% endhint %} {% embed url="" %} What's inside a digital twin (realvirtual Know-How) {% endembed %} ## Overview The demo model showcases most of the **realvirtual.io** features in a single Unity scene. This allows you to quickly explore and test realvirtual.io’s functionality without having to set up your own scene from scratch.

realvirtual.io Demo model

## Starting and Navigating in the Demo ### Open the Demo Model 1. In the Unity Editor, navigate to the top menu. 2. Select **Tools > realvirtual > Open demo scene**. The demo model will open in the Unity Scene view. ### Start the Demo Model 1. Press Unity’s **Play** button to start the demo model. 2. Upon entering play mode, you will see two views: * **Scene View**: The standard Unity editor view for scene editing. * **Game View**: A preview of the final compiled version of your Unity project. 3. If the **Game View** window is not open, it will open automatically when you press Play. 4. You can move around and explore the scene in both views. ### Mouse Navigation in Game View * **Keyboard + Mouse** (Default Unity Controls): * **W, A, S, D** + **Right Mouse Button** drag to move around in 3D space. * **Right-click + Drag** rotates the camera view. * **Mouse Scroll Wheel** zooms in and out. ### Touch Navigation in Game View If you are on a mobile device or a Windows computer with a touchscreen, you can navigate using touch gestures: * **One-Finger Drag** to pan the view. * **Two-Finger Gestures** to rotate, pan, and zoom. * **Three-Finger Drag** to tilt the scene. ### Navigation in Scene View Navigation in **Scene View** with the mouse is largely the same as navigating in **Game View**. Unity provides a standard set of mouse and keyboard shortcuts for moving around your scene > **Note:** For a more comprehensive overview of Scene View navigation and customization, please refer to the official Unity Documentation. ### Hotkeys | (Mouse) Key | Action | | ------------------------- | --------------------------------- | | Right Mouse Button | Rotate scene | | Middle Mouse Button Wheel | Zoom in and out | | Middle Mouse Button | Pan in a direction | | Right Arrow Key | Move the scene to the **right** | | Left Arrow Key | Move the scene to the **left** | | Up Arrow Key | Move the scene **up** | | Down Arrow Key | Move the scene **down** | | Shift + Up Arrow Key | Zoom **into** the scene | | Shift + Down Arrow Key | Zoom **out of** the scene | | T | Top view | | F | Front view | | B | Back view | | L | Left view | | R | Right view | | F1,F2,F3 | Saved views which can be extended | ### Overlay Buttons On the right side of the **Scene**, you will notice a set of **overlay buttons**.

Overlay buttons for hiding components and changing camera positions (views)

These buttons are **fully configurable** to allow for custom end-user interactions. In the demo model, they serve the following functions: 1. **Hide/Show Groups** * The first two buttons toggle the visibility of certain groups (e.g., specific machine parts or UI elements). 2. **Camera Positions** * The next four buttons switch between pre-defined camera views, allowing you to quickly navigate to important areas in the scene. More information about the overlay buttons can be found in section [**Overlay Buttons**](#overlay-buttons). Feel free to adapt or extend these buttons for your own project requirements, such as adding more camera angles, toggling additional objects, or triggering other custom actions. ### 3D Buttons In addition to the **overlay buttons** (used primarily for scene navigation), the demo model also includes **3D Buttons** positioned within the scene. These buttons serve as **virtual stand-ins** for real machine buttons: * **Direct PLC Connection**: Each 3D Button is linked to the PLC signals (inputs/outputs), enabling interaction with the machine’s drives and automation logic. * **Realistic Simulation**: Pressing these buttons in the virtual environment replicates the actions of physical buttons on the actual machine.

3D Buttons within the Scene

For more information on setting up and customizing these 3D Buttons, see the [**3D Buttons**](#id-3d-buttons) section. ## More Information About the Demo Model In this section, you will find additional details about the **realvirtual.io** demo model. You can use this information as a reference when creating or customizing your own models. ### **realvirtual object (prefab)** The **realvirtual** object is the foundation of every **realvirtual.io** model. It handles overall settings, provides a base plate, sets up basic lighting, and manages scene navigation in Play mode. > **Important:** You must include this prefab in every model you build to ensure correct functionality and navigation. For more information please check the section [**realvirtual**](/components-and-scripts/game4automation)**.** ### **3D Components** The demo model includes **pre-prepared 3D components**—such as conveyors, a robot, a machine, and **3D buttons** that interact with the PLC. These elements were created specifically to showcase various **realvirtual.io** features and provide an interactive environment for testing. > **Note:** With **realvirtual.io Professional**, you can import your own CAD data in **STEP format**. For more information, see the [**CAD Import**](/basics/cad-import) section, which explains how to bring custom 3D models into your Unity scene. Within the **Demo Cell**, you will find a **CNC** component that has been placed into the scene as a **Prefab**. If you want to learn more about how Prefabs work or how to create your own reusable components, see the [**Reusable Components (Prefabs)**](/basics/reusable-components-prefabs) section. ### Drives and Kinematics The CNC machine consists of multiple **Drives**, organized into a **Kinematic Hierarchy** that controls machine axes movement. For more details on configuring drives, defining movement, and working with kinematics, refer to the [**Motion and Kinematics**](/components-and-scripts/motion) section.

Defined kinematic for the CNC Machine

The **Drives** in the kinematic hierarchy are linked to **Signals** (specifically, **PLCInputs** and **PLCOutputs**) that are controlled by a **PLC**. In the demo model, the PLC is represented by a **Unity script** within the scene. However, you can also connect an **external PLC** via various **Interfaces** that **realvirtual.io** provides. Connecting to a real PLC is particularly useful for: * **Virtual Commissioning**: Testing and validating PLC code against a virtual model before deploying to a physical system. * **3D HMI**: Using the 3D model as an interactive, real-time human-machine interface. ### **Interfaces** ![](/files/BmyGxN8NuVu2c6Q1TtFi)\\ In the demo model, there is a **demonstration interface** set up to work with **TwinCAT**. However, since TwinCAT integration is only available in **realvirtual.io Professional**, the actual interface script for TwinCAT is **not included** in the standard version.

Interface Signals in Demo

The TwinCAT interface in the demo model is configured with multiple signals that could be exchanged between the virtual machine and a real Beckhoff PLC. Typically, signals are imported directly from the PLC program via the interface communication (e.g. for Beckhoff) or via a signal table (for other interfaces such as Siemens S7). If you are using **realvirtual.io Professional**, you can fully leverage the TwinCAT interface to establish a live connection to a Beckhoff PLC for virtual commissioning or real-time simulation. For more details on setting up and configuring interfaces for different type of PLCs or robots, refer to the [**Interface** ](#interfaces)section. ### **Sources and MUs** ![](/files/e7Z0cogBb7ndAF8fwzUY) \ In realvirtual.io, objects that move based on physics are called [**MUs**](/components-and-scripts/mu-movable-unit) (movable units). In the demo model, there is one source for the Turbine, which automatically creates a copy of itself (a process called spawning in Unity). It is considered good practice to place newly created MUs as sub-objects of a dedicated object in the Hierarchy. In the demo model, this dedicated object is named **MUs**. During simulation, you can see all dynamically generated MUs under **MUs**. ### **PLCs** ![](/files/wAu8lvQv9SvGNyuQlkIu)\ Because we do not have real PLCs connected to the demo model, we programmed simple control logic to operate the model. This control logic communicates with the behavior models of drives and sensors, as well as with lights and buttons, by using the Signals defined in the interface section.

PLC code written in Unity scripting and connected to the Signals

Defining PLC logic within the model itself is primarily used for pure simulation and demonstration purposes. It can also be useful for preparing virtual commissioning models, where a simple logic helps test the kinematics and functionality of the model before connecting to a real PLC. There are several ways for defining custom logics. Please check the section [**Defining Logic.**](/components-and-scripts/defining-logic) © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Old Demo Model First experiences with realvirtual.io based on the demo model {% hint style="info" %} This is a description of the old demo model which was used until realvirtual 6.0.1. It is still inside of our delivery and you find it under Assets/realvirtual/Scenes/DemoRealvirtualOld.unity {% endhint %} The old demo model looks like this:

The old ard demo model

#### Start the old demo model The demo model can be started with the play button. You will get a *Scene view* and a *Game View*. If the Game View window is not opened, it will open automatically on start. You can navigate in the scene in both views. The Game View is a preview of the later on the compiled version of Unity. On low performance computers the *Game View* is a little bit slower, than in the final Player version. On good performing computers the difference is negligible. #### Mouse navigation You can navigate in the scene with the mouse or keyboard: | (Mouse) Key | Action | | ------------------------- | --------------------------------- | | Right Mouse Button | Rotate scene | | Middle Mouse Button Wheel | Zoom in and out | | Middle Mouse Button | Pan in a direction | | Right Arrow Key | Move the scene to the **right** | | Left Arrow Key | Move the scene to the **left** | | Up Arrow Key | Move the scene **up** | | Down Arrow Key | Move the scene **down** | | Shift + Up Arrow Key | Zoom **into** the scene | | Shift + Down Arrow Key | Zoom **out of** the scene | | T | Top view | | F | Front view | | B | Back view | | L | Left view | | R | Right view | | F1,F2,F3 | Saved views which can be extended | #### Touch navigation It is also possible to use touch navigation on mobile devices or windows computers with touch screens. You can pan with one or two fingers. With two fingers it is possible to rotate, pan and zoom. With three fingers the scene can be tilted. #### Space Navigator If you have a 3D mouse from 3DConnextion you can use the mouse to navigate in the 3D scene. ## Some more information about the demo model **Game4automation object (prefab)** The first step for creating a new model, is to place the Realvirtual prefab into the scene. This object handles the overall settings, provides a base plate, the basic lighting and the scene navigation in game mode. You need to use this in every model you build. You can change the parameters of the base plate or the lighting by clicking on the objects. This will override the inherited properties from the realvirtual.io Asset. For more information about Prefabs and inheritance please check the Unity documentation about [Prefabs](https://docs.unity3d.com/Manual/Prefabs.html) or check the [Unity video tutorial ](https://unity3d.com/de/learn/tutorials/topics/interface-essentials/prefabs-concept-usage). **3D Components** The demo model is based on several pre-prepared 3D components like the conveyor, the handling system and the robot. These components were created just for demo purposes. With realvirtual.io Professional you can import your own CAD data based on step files. Please check the section [CADImport](/basics/cad-import). The 3D components in the demo scene are *Handling, ConveyorCan, ConveyorBox, Cabinet, Robot*) **Interfaces** ![](/files/BmyGxN8NuVu2c6Q1TtFi)\ The model is equipped with one demonstration Interface. It is an S7 [Interface](/components-and-scripts/interfaces) to the Siemens Controller. For more information about interfaces please check Section Interface. For demo purposes, in the demo model the interface is turned off so that the model can run in the absence of any external software connections. Nevertheless, signals are created for the interface, and the full model is controlled by a script substituting for a PLC, to handle the signal events. **Signals** Each interface can be of a certain type (S7TCP, Shared Memory, PLCSIM Advanced and so on) and can contain several signals. Signals are usually imported from the counterpart of the interface (for example if Simit is up and running, the signals can be automatically imported from Simit) or signals can be manually created based on the prefabs. See more about Signals and Signal types in Section Interface. In the model you will find several signals, for example *CanGripperClosed,GantryYStart* and so on. On a signal you always see the signal value in the Hierarchy view. For example *False* and *True* for boolean signals. **PLC-Inputs** (which means outputs from Unity) are in **red**. **PLC-Outputs** (which means inputs to Unity) are in **green**. **Sources and MUs** ![](/files/e7Z0cogBb7ndAF8fwzUY) \ The objects, which are moving based on Physics, are called [*MU*](/components-and-scripts/mu-movable-unit) (= movable unit) in realvirtual.io. The model has two sources. One for the cans (*CAN*)= and one for the blue plastic box (*PlasticBox)*. The [Sources ](/components-and-scripts/mu-movable-unit/source)are automatically creating a copy of itself (this is called spawning in Unity). It is always good practice, to place the newly created [*MU*](/components-and-scripts/mu-movable-unit)*s* as sub object of a special object in the hierarchy. In the demo model this is the object *MU*. During simulation runtime you will find all dynamically created [*MU*](/components-and-scripts/mu-movable-unit)*s* under *MU*. **PLCs** ![](/files/wAu8lvQv9SvGNyuQlkIu)\ Because we don't have real PLCs connected to the demo model, we programmed some simple control logic to drive the model. These control logics are communicating with the behavior models of the drives and sensors by using the Signals in the interface section. {% hint style="info" %} Control logics inside the model are using signals for controlling the model mainly for demo purposes. If you just want to control the model, you can also control the public properties on the drives or sensors directly. See more in Section[ Defining Logic.](/components-and-scripts/defining-logic) {% endhint %} In the Demo model we used [Unity Scripting ](/components-and-scripts/defining-logic/unity-scripting)for defining the "PLC" logic. You can also use our [Logicsteps](/components-and-scripts/defining-logic/logicsteps), [Unity Visual Scripting ](/components-and-scripts/defining-logic/unity-visual-scripting)or [Playmaker ](https://github.com/game4automation/doc/blob/doc/basics/demo-model/broken-reference/README.md)if you would like to use more visual approaches. The control logics inside the model are using signals for controlling the model mainly for demo purposes. If you just want to control the model, you can also control the public properties on the drives or sensors directly. See more in Section PLC. **UI** You can add UI components to a scene. These UI components can be connected to signal inputs or outputs of the PLC. For example, this is very useful when you want to replace real buttons with virtual ones in your model. In the UI components you find several elements to control the model. During simulation you can see in the Game-Window the UI elements:
The UI elements can be opened and closed by clicking on the slider button in the middle of the bottom corner of the screen. Additional buttons and tabs can be added to your own models as you would like. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Editor User Interface Building the Digital Twin in the Unity editor with realvirtual.io The editor user interface is the environment within Unity where you define your digital twin using realvirtual.io. This interface leverages the full flexibility of Unity, allowing you to create and configure your digital twin. Once your digital twin is ready, you can publish it as a finished product for various platforms such as Windows exe, Android app, WebGL, and more. Refer to the [Supported Platforms](/advanced-topics/supported-platforms) and [Publishing the Digital Twin](/basics/publishing-the-digital-twin) sections for details on this process. The user interface for the published digital twin is covered in the [Runtime UI](/basics/runtime-ui) section. ## Main menu bar Most of the realvirtual.io functions can be found in the main menu bar under "realvirtual.io." Here, you can add components or scripts to the scene and access various features.

Unity UI and realvirtual.io main menu

## For a deeper understanding of the user interface and its functionalities, the documentation is organized into various subsections, each focusing on specific aspects of interaction and editing within the platform. These subsections are designed to guide users through the various tools and features available, enhancing their workflow and efficiency in managing 3D models and scenes. #### Key UI Features and Navigation: * [**Model Hierarchy Navigation**](/basics/user-interface/hierarchy-window): Utilize the Hierarchy Window for a structured view and navigation through the Digital Twin hierarchy, allowing easy access and organization of the scene's components. * [**3D Scene Editing**](/basics/user-interface/3d-views): Engage with the 3D Views for comprehensive editing capabilities within your 3D scene, offering a direct and interactive way to manipulate Digital Twin elements. * [**Quick Edit Menu**](/basics/user-interface/quick-edit): Access the most common tasks rapidly with the Quick Edit Menu, designed to streamline your workflow by providing shortcuts to frequently used actions. * [**Pivot Point Adjustment**](/basics/user-interface/move-pivot-points-pro): Learn how to move Pivot Points of objects, facilitating precise alignment and positioning. * [**Selection in Large Models**:](/basics/user-interface/selection-window) Use the Selection Window for efficient selection within big models and assemblies, working with groups, hiding and unhiding groups ensuring you can easily find and manipulate specific elements in complex scenes. * [**3D Model Measurement**](/basics/user-interface/measurement-pro): Measure distances within the 3D mode. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Hierarchy Window Navigating the model hierarchy The Hierarchy window is a fundamental feature in Realvirtual.io that allows users to manage the components of their virtual models. In this view, you can manipulate and organize various components, known as "Gameobjects," within your scene, providing an efficient way to structure and maintain your virtual environment. In Realvirtual.io, the term "Gameobject" is used interchangeably with the Unity engine's concept of a GameObject. Essentially, a Gameobject represents an object within your virtual scene, encompassing everything from physical entities to more abstract elements.

Hierarchy vidw

Within the Hierarchy window, you have the flexibility to add new Gameobjects or remove existing ones through the context menu.

Hierarchy context menu

### Component Icons Gameobjects in the Hierarchy window can be enhanced by the addition of various components. Realvirtual.io provides an extensive library of specialized components designed for machinery and automation, including Drives, Sensors, TransportSurfaces, PLC Interfaces, and more. To help users quickly identify these components, standard components are represented by unique icons in the Hierarchy View. These icons serve as visual cues, making it easier to understand the composition of a Gameobject at a glance.

Icons in Hierarchy View

### Hiding elements To maintain a clean and organized workspace, the Hierarchy window includes a convenient feature for hiding elements. Located on the right side of the Hierarchy View, a small switch box allows you to deactivate (and hide) a Gameobject and all of its associated subcomponents. This functionality is particularly useful when working on complex scenes with numerous elements, helping you focus on specific aspects of your virtual model without unnecessary distractions. ### PLCInputs and PLCOutputs in Hierarchy Realvirtual.io organizes automation interfaces of robots, PLCs, and more as signals. It provides multiple interfaces to link your Digital Twin to real automation systems like Siemens, Beckhoff, Rockwell, ABB, and UR Robots. Signals are associated with specific interfaces and can often be auto-imported from PLCs. In the Hierarchy view during simulations, you can see signals and their properties. PLCInputs are read, and PLCOutputs are green. You can interact with boolean signals by forcing or unforcing them to specific values for testing and control.

Signals in Hierarchy View

For a comprehensive understanding of the standard functions and features of the Hierarchy View, we recommend referring to the official Unity documentation. {% embed url="" %} # 3D Views Scene and Game Window In Realvirtual.io, a notable distinction from many common simulation systems is the presence of two 3D views within Unity: the "Scene View" and the "Game View." Typically, you work in the "Scene View" when adding, moving, and inspecting your Digital Twin. It provides a detailed environment for your design and development process. It's important to note that the Scene View is exclusively available within the Unity Editor. When you publish your Digital Twin as a compiled executable for platforms like Windows, iOS, Android, WebGL, or MacOS, only the "Game View" becomes a part of the delivered application. The Game View serves as a preview of the final Digital Twin application. In some scenarios, such as virtual commissioning, you may not even need to publish your Digital Twin, and you can continue working solely within the Unity Editor's Scene View. However, in other use cases, such as when delivering the Digital Twin to end-users as a 3D interface integrated with a physical machine, the Scene View becomes a valuable tool. Here, you can develop unique user interactions and preview how the final Digital Twin product will appear. When you initiate simulation mode, the Game View automatically starts. To maintain efficiency and workflow, we typically position the Game View window in the bottom left corner of the workspace. This arrangement ensures that the Scene View remains readily accessible throughout your work in the Unity Editor.

Unity editor with Scene view and small Game view in the bottom right corner

For further details on the standard functions and features of the Scene view in Unity, we recommend consulting the official Unity documentation. {% embed url="" %} ### Scene View Gizmos Gizmos in the Scene View of Realvirtual.io are helpful tools while editing your Digital Twin in the 3D environment. You can access Gizmos via the icon located in the top right corner of the Scene View. This allows you to enable or adjust the size of Gizmos according to your needs. When all Gizmos are turned off, you won't see any Gizmos or the QuickEdit Overlay window. We recommend setting the size of 3D icons to 0, especially for camera and light icons, as they are typically not necessary during editing:

Scene view Gizmos settings

Realvirtual.io provides unique Gizmos for certain components, primarily for drives. These specialized Drive Gizmos are visible when the Gameobject with the added drive is selected in the Hierarchy view. During edit mode, the Drive Gizmo indicates the positive direction of the drive, aiding in precise adjustments and configurations.

Drive Gizmo during edit mode

In simulation mode, Drive Gizmos display the current position of the drive, along with a green arrow indicating the drive's current moving direction. This feature enhances real-time monitoring and control during simulations.

Drive Gizmo during simulation mode

# Quick Edit ## What's New in Version 6.0.3 * **New Toolbar Integration**: QuickEdit can now be activated via the realvirtual toolbar buttons in Scene View * **Modern UI Toolkit**: Complete visual redesign with improved styling * **Better Organization**: Components grouped by functionality * **Enhanced Pivot Tools**: Integrated MovePivot functionality with dedicated toolbar button * **Improved Performance**: Faster rendering and responsiveness * **Dark Theme**: Professional dark interface matching Unity's theme * **Dual Activation**: Both toolbar button and F1 hotkey activation methods available {% hint style="info" %} **Updated in Version 6.0.3**: QuickEdit has been redesigned with modern UI Toolkit and enhanced overlay integration. {% endhint %} ## Overview The QuickEdit overlay is a powerful Scene View tool that provides instant access to essential realvirtual components and functions. The redesigned interface features a modern, dark-themed UI with organized component categories and enhanced pivot tool integration.
New QuickEdit UI Toolkit Interface

QuickEdit overlay with modern UI Toolkit design and enhanced component organization

## Key Features ### Component Categories The new QuickEdit interface organizes components into logical groups: * **Positioning Tools**: Local, Global, Pivot controls with X-, Y+, Z+ axis buttons * **Ground Operations**: "To Ground", "Pivot to B...", "Align Y Up" * **Object Management**: "Empty" and "To Empty" for GameObject creation * **Core Components**: Transport Surface, Sensor, Axis, Kit * **Interaction**: Grip, Fixer, Joint * **Motion Systems**: Simple Drive, Cylinder, Gear, CAM, Follow Position, Destination Drive, Drive Erratic, Drive Speed ### Enhanced Controls * **Pivot Integration**: Direct access to pivot manipulation tools * **Speed Control**: Target Speed slider with precise value input * **Playback Controls**: Back, Stop, Forward buttons for simulation control * **Context-Sensitive**: Available functions adapt to selected object(s) ## How to Use ### Activation Methods **Method 1: Toolbar Button (New in 6.0.3)** The QuickEdit overlay can now be activated via the new realvirtual toolbar in the Scene View:
realvirtual Toolbar Buttons

New realvirtual toolbar with Quick Edit and Move Pivot buttons in Unity Scene View

**Method 2: Keyboard Shortcut** Press **F1** in Scene View to toggle QuickEdit overlay (traditional method) ### Usage Steps 1. **Activation**: Click the **Quick Edit** button in the realvirtual toolbar or press **F1** 2. **Selection**: Select objects in the Scene View or Hierarchy 3. **Component Addition**: Click component buttons to add to selected objects 4. **Pivot Control**: Use positioning tools for precise object manipulation 5. **Speed Adjustment**: Use the Target Speed slider for drive components ## Drive Control Settings When working with Drive components, QuickEdit provides controls for setting up drive parameters that will be used during Play Mode:
QuickEdit Drive Controls

Drive control section for configuring target speed and jog settings for Play Mode

### Control Settings * **Back (◀)**: Sets the drive to jog backward when Play Mode starts * **Stop (■)**: Sets the drive to stop/idle state for Play Mode * **Forward (▶)**: Sets the drive to jog forward when Play Mode starts ### Speed Configuration * **Target Speed**: Sets the target speed value for the selected drive (shown as "100" in mm/s) * **Pre-Play Configuration**: Speed setting is applied to the drive component for use in Play Mode * **Units**: Speed configured in millimeters per second (mm/s) ### Usage for Play Mode Preparation 1. **Select Drive**: Click on a Drive component in the Scene View or Hierarchy 2. **Set Speed**: Configure the Target Speed value for Play Mode operation 3. **Set Direction**: Choose Back, Stop, or Forward for initial Play Mode behavior 4. **Enter Play Mode**: The drive will use the configured settings when simulation starts This feature is particularly useful for: * **Play Mode Setup**: Configure drive behavior before entering Play Mode * **Speed Configuration**: Set target speeds for automation sequences * **Initial State Setting**: Define whether drives should jog forward, backward, or remain stopped * **Simulation Preparation**: Prepare drive parameters for testing automation logic ## QuickEdit in Play Mode During Play Mode, QuickEdit transforms into a powerful real-time control and monitoring interface, allowing you to interact with drives and control simulation parameters while the automation is running:
QuickEdit in Play Mode

QuickEdit during Play Mode showing active drive controls, timescale adjustment, and real-time drive monitoring

### Simulation Controls
Simulation Speed Controls

Close-up view of Timescale and Drive Speed Override controls for simulation speed adjustment

#### Timescale Control * **Timescale Slider**: Adjust simulation speed from slow motion to accelerated time (shown: 368.8) * **Current Value Display**: Shows current timescale multiplier in real-time * **Slider Range**: From 0.1 (slow motion) to max (very fast simulation) * **Real-time Adjustment**: Changes apply immediately to entire simulation speed #### Drive Speed Override * **Global Speed Control**: Override all drive speeds with a master multiplier (shown: 1.0) * **Independent Control**: Separate from timescale - affects only drive movements * **Slider Range**: From 0 (stopped) to max speed multiplier * **Testing Feature**: Ideal for testing automation sequences at different drive speeds ### Active Drive Monitoring #### Drive Selection and Control * **Drive List**: Shows currently selected or active drives in the scene * **Real-time Status**: Displays current drive positions and states * **Position Display**: Shows exact drive positions (e.g., "A3: 205.8°") * **Live Updates**: Values update continuously during simulation #### Manual Drive Control * **Back (◀)**: Manually jog selected drive backward during simulation * **Stop (■)**: Stop selected drive immediately * **Forward (▶)**: Manually jog selected drive forward during simulation * **Override Automation**: Manual controls can override automated sequences ### Real-time Features #### Visual Feedback * **Active Drives**: Highlighted drives show which components are currently moving * **Position Indicators**: Real-time position values displayed for monitoring * **Status Colors**: Visual indicators show drive states (moving, stopped, etc.) #### Interactive Control * **Live Adjustment**: All controls respond immediately during simulation * **No Pause Required**: Adjust parameters without stopping the simulation * **Multi-drive Support**: Monitor and control multiple drives simultaneously ### Use Cases in Play Mode * **Speed Testing**: Adjust timescale to observe automation at different speeds * **Drive Override**: Take manual control of drives during automated sequences * **Performance Tuning**: Test different speed settings in real-time * **Debugging**: Stop specific drives to isolate issues during simulation * **Training**: Demonstrate system behavior at various speeds * **System Optimization**: Fine-tune drive speeds and timing while observing results ### Key Differences from Edit Mode | Feature | Edit Mode | Play Mode | | -------------------- | ----------------------- | ---------------------------------- | | **Drive Controls** | Set initial parameters | Real-time drive control | | **Speed Settings** | Configure for Play Mode | Active speed override | | **Timescale** | Not available | Real-time simulation speed control | | **Position Display** | Static values | Live updating positions | | **Purpose** | Preparation and setup | Active simulation control | ## Configuration ### Aligning Pivot Points To align pivot points, you can use the Pivot button. This window will open the Move Pivot window. For more information check the page [Move Pivot.](/basics/user-interface/move-pivot-points-pro) ### Changing Quickedit Visibility You can toggle the visibility of the Quickedit window on/off using the Hotkey F1. If you wish to change the hotkey, you can do so within the realvirtual.io controller inside the scene. ![](/files/3LuluRtJIrz3YUQDxmLT) ## Prerequisites * Unity 6000.0.28f1 (Unity 6) or later with realvirtual framework * Scene must contain a realvirtual.io controller component * Basic familiarity with Unity Scene View interface ## Troubleshooting * **QuickEdit not appearing**: Ensure F1 hotkey is enabled in the realvirtual.io controller settings * **Toolbar buttons missing**: Verify Unity 6+ installation and proper realvirtual framework setup * **Drive controls unresponsive**: Check that drive components are properly configured and selected * **Outdated interface**: Ensure you're using realvirtual version 6.0.3 or later for the new UI Toolkit design ## See Also * [Move Pivot Points (Pro)](/basics/user-interface/move-pivot-points-pro) - Advanced pivot manipulation tools * [Reparenting Tool (Pro)](https://github.com/game4automation/doc/blob/doc/basics/user-interface/reparenting-tool-pro.md) - Hierarchy management * [Runtime UI](/basics/runtime-ui) - Play Mode interface controls # Demo Scenes Browser {% hint style="info" %} This feature was added in realvirtual **6.3**. {% endhint %} ## Overview The Demo Scenes Browser provides categorized access to all sample scenes included with realvirtual Starter and Professional. ## Opening the Browser * Menu: **Tools > realvirtual > Demo Scenes** * Or via the realvirtual toolbar dropdown in the editor toolbar

Demo Scenes Browser

## Categories ### Starter | Category | Scenes | | --------------------- | ----------------------------------------------------------------------------------- | | **Getting Started** | Main introduction scene with conveyor belt system, drives, sensors, and MU handling | | **Drives** | Drive types: raycast-based position limits, force drive, conditional start | | **Transport Systems** | Conveyors, chains, guided transport, radial conveyors, surface transfer | | **Object Handling** | Gripping, MU cutting, physics, MU changes | ### Professional | Category | Scenes | | --------------------- | -------------------------------------------------------------------------- | | **PLC Interfaces** | Protocol demos: OPC-UA, TwinCAT, S7, Modbus, MQTT, and more | | **Robotics** | IK robots, target blending, kinematic MU | | **Robot Interfaces** | Real controller interfaces: KUKA, Universal Robots, Fanuc, Denso, and more | | **Advanced Features** | Multiplayer, statistics, volume tracking | ## Importing Demo Scenes Click **Import** next to any scene. This uses Unity's Package Manager Samples import system. Scenes are imported to: * `Assets/Samples/realvirtual Starter/6.3.0/Demo Scenes/` * `Assets/Samples/realvirtual Professional/6.3.0/Demo Scenes (Pro)/` You can also click **Open Package Manager** at the bottom to access the standard Unity Package Manager for manual sample import. ## See Also * [Installation](/basics/installation) * [Folder Structure](/basics/folder-structure) # Recent Items (Pro) Quick navigation to recently used GameObjects, Assets, and Scenes {% hint style="info" %} **Professional Feature**: Recent Items is only available in realvirtual Professional version 6.0.7 and above. {% endhint %} Recent Items provides quick access to recently used GameObjects, project assets, and scenes through a Scene View overlay panel. ![Recent Items Overlay Panel](/files/5QD7oGXNJZXarv7Opyzp) ## Overview Recent Items automatically tracks your selection history and organizes items into three categories: * **Scene Objects**: GameObjects from your scenes (shows up to 5 items) * **Project Assets**: Scripts, prefabs, materials, etc. (shows up to 5 items) * **Scenes**: Scene files you've opened (shows up to 3 items) Objects in different scenes are marked with **(→)** and prompt you to switch scenes when clicked. ## How to Use 1. Click the **Recent** button in the realvirtual toolbar to toggle the overlay 2. Click any item to navigate to it immediately 3. The overlay closes automatically after selection 4. Use **Clear All** button to remove history ## Features * **Auto-tracking**: Continuously monitors your selections * **Unity Icons**: Each item shows its appropriate icon (blue for prefabs, etc.) * **Time Stamps**: Shows when you last accessed each item (2m, 5h, 3d, etc.) * **Smart Scene Switching**: Prompts before switching to different scenes * **Persistent History**: Maintains history across Unity sessions * **Auto-refresh**: Updates every 2 seconds when visible ## Prerequisites * Unity 6 (6000.0.28f1) or newer * realvirtual Professional 6.0.7+ ## See Also * [Quick Edit](/basics/user-interface/quick-edit) - Scene View overlay for component addition * [Move Pivot Points (Pro)](/basics/user-interface/move-pivot-points-pro) - Advanced pivot tools * [Selection Window (Pro)](/basics/user-interface/selection-window) - Advanced selection management *** © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. # Project Path Display A compact Unity Editor window that displays the current project path. {% hint style="info" %} **Enhanced in Version 6.0.3**: Project Path Display now integrates directly with Unity's main toolbar for better visibility and accessibility. {% endhint %} A compact Unity Editor feature that displays the current project path directly in Unity's toolbar for easy reference during development. ## Overview The Project Path Display shows the full path of your current Unity project in Unity's main toolbar, providing immediate visual confirmation of which project you're working on. This feature is particularly useful when working with multiple realvirtual projects or when team members need to verify project directories. ## Features ### Toolbar Integration The Project Path Display is now integrated directly into Unity's main toolbar, providing immediate visibility without taking up additional screen space:
Project Path in Unity Toolbar

Project path displayed in Unity's main toolbar showing "E:\realvirtual6\game4automation\realvirtual"

### Configuration Options Access the Project Path Display settings through the right-click menu in the toolbar:
Project Path Display Settings

Right-click menu showing "Show Project Path in Toolbar" and "Apply Standard Settings" options

## Properties * **Toolbar Integration**: Displays directly in Unity's main toolbar for maximum visibility * **Auto-updating**: Path updates automatically if the project changes * **Space Efficient**: No additional window required - integrated into existing interface * **Always Accessible**: Visible whenever Unity is open * **Context Menu**: Easy toggle on/off through right-click options ## Usage ### Enabling the Feature **Method 1: realvirtual Menu**
realvirtual Menu Options

realvirtual menu showing "Show Project Path in Toolbar" and "Apply standard settings" options

1. Go to **realvirtual** menu in Unity's main menu bar 2. Select **"Show Project Path in Toolbar"** (✓ indicates it's enabled) 3. The full project path will immediately appear in the toolbar **Method 2: Right-Click Context Menu** 1. **Right-click** on the Unity toolbar (in the project path area) 2. Select **"Show Project Path in Toolbar"** from the context menu 3. The full project path will immediately appear in the toolbar ### Disabling the Feature 1. **Uncheck** "Show Project Path in Toolbar" from either the realvirtual menu or right-click context menu 2. The project path display will be hidden from the toolbar ## Additional Features ### Project Settings The realvirtual menu also provides access to **"Apply standard settings"** which configures comprehensive Unity project settings optimized for industrial automation. For detailed information about this feature, see the dedicated [Project Settings](/basics/project-settings) page. ## See Also * [Editor User Interface](/basics/user-interface) - Overview of all editor interface tools * [Quick Edit](/basics/user-interface/quick-edit) - Quick edit overlay menu with toolbar integration # Move Pivot Points (Pro) The Move Pivot tool provides precise control over GameObject pivot points and positioning within the Unity Editor, specifically designed for realvirtual automation components. ## Overview The Move Pivot tool is a specialized Unity Editor window that allows you to reposition GameObjects by aligning them to specific vertices, midpoints, or other objects' pivot points. This tool is particularly useful for precise positioning of automation components, sensors, and mechanical parts in industrial simulation environments. {% hint style="info" %} This feature is only available in the realvirtual Professional version. {% endhint %} The tool supports three primary positioning methods: * **Vertex-based positioning**: Align objects to selected mesh vertices with single-point, two-point midpoint, or three-point center calculations * **Object-to-object alignment**: Position objects relative to other GameObjects' pivot points or geometric centers * **Circle and bore center detection**: Click a round surface and let the tool calculate its exact center, axis and radius — see [Circle and Bore Center Detection](#circle-and-bore-center-detection) > **💡 Hint**\ > The Move Pivot tool respects Unity's undo system, allowing you to safely experiment with different positioning configurations. ## Opening the Tool Access the Move Pivot tool through: * **Menu**: **realvirtual** > **Move Pivot (Pro)** * **Quick Access**: Available in the realvirtual quick tools menu or Scene View overlay
Move Pivot Overlay Button

Move Pivot tool accessible via Scene View overlay button

The tool automatically selects the currently highlighted GameObject in the Hierarchy as the primary object to move.
Move Pivot Tool Interface

Move Pivot tool interface showing object selection and positioning options

## Properties ### Object Selection #### Object 1 (Target Object) The GameObject that will be moved and repositioned. * **Selection method**: Automatically uses the currently selected GameObject, or click **Reset** to clear and manually select a new target * **Visual feedback**: The selected object is highlighted with visual indicators in the Scene View #### Object 2 (Reference Object) An optional reference GameObject for object-to-object alignment operations. * **Selection method**: Click **Select Object2** and then click on the desired GameObject in the Scene View * **Visual indicators**: * RGB-colored axes display the object's pivot point * White-colored axes show the geometric center ### Point Selection #### Point 1, Point 2, Point 3 Individual vertex points selected from mesh geometry for precise positioning calculations. * **Selection method**: Click the respective point button, then click on mesh vertices in the Scene View * **Visual feedback**: Selected points are marked with colored gizmos * **Precision**: Zoom in on target areas for more accurate vertex selection ## Editor Tools ### Interactive Gizmos The tool provides real-time visual feedback through colored gizmos: * **Object highlighting**: Target objects display selection indicators * **Pivot visualization**: Colored axes show current and proposed pivot positions * **Point markers**: Selected vertices are marked with distinct visual indicators * **Alignment preview**: Visual guides show the results of alignment operations ### Scene View Integration * **Click selection**: Direct vertex and object selection in the Scene View * **Hover feedback**: Objects and vertices highlight when hoverable * **Camera navigation**: Full compatibility with Unity's Scene View navigation
Move Pivot Scene View

Move Pivot tool in action showing selected points, current pivot position, and visual gizmos in the Scene View

## Usage Examples ### Single Point Alignment Position an object's pivot to a specific mesh vertex: 1. Select the target GameObject in the Hierarchy 2. Open **realvirtual** > **Move Pivot (Pro)** 3. Click **Point 1** to activate vertex selection mode 4. Click on the desired vertex in the Scene View 5. Use the alignment options to move the object's pivot to the selected point ### Midpoint Positioning Align an object between two vertices: 1. Follow steps 1-2 from single point alignment 2. Click **Point 1** and select the first vertex 3. Click **Point 2** and select the second vertex 4. Use the midpoint alignment option to position the object between the two points ### Three-Point Center Alignment Position an object at the geometric center of three vertices: 1. Select your target GameObject and open the Move Pivot tool 2. Select **Point 1**, **Point 2**, and **Point 3** on different mesh vertices 3. Apply the three-point center alignment to position the object at the calculated center
Three-Point Center Alignment

Three-point center alignment showing calculated center position from selected vertices

### Object-to-Object Positioning Align one object's pivot with another object's pivot or center: 1. Select the target GameObject (Object 1) 2. Click **Select Object2** and choose the reference GameObject 3. Choose between: * **Pivot alignment**: Aligns Object 1's pivot with Object 2's pivot point (RGB axes) * **Center alignment**: Aligns Object 1's pivot with Object 2's geometric center (white axes) ## Circle and Bore Center Detection {% hint style="info" %} This method was added in realvirtual **6.3.6** (Professional), which is currently in beta and planned for the upcoming release. {% endhint %} Placing a pivot on the axis of a bore, a shaft or a cylinder is the most common reason to move a pivot on imported CAD — and the hardest to do by hand. The bounding-box center, a single vertex and a triangle centroid all lie beside the true center, because CAD tessellation is unevenly dense: the middle of a round face carries far fewer triangles than its rim, so any averaged position drifts toward the denser area. **Move to Circle / Bore Center** removes the guesswork. You click the round surface once and the tool derives the exact center, axis and radius from the geometry itself. ### Quick Start 1. Select the GameObject whose pivot you want to move. 2. Open the Move Pivot tool and choose **Move to Circle / Bore Center** from the method dropdown. 3. Click the round surface in the Scene View — the cylindrical wall of a shaft or bore, or a flat face that contains a bore. 4. The detected circle, its axis and the resulting pivot position appear as gizmos. Check the reported radius and deviation. 5. Click **Apply**. The detection runs on the click only, never while you hover, so large assemblies stay responsive. ### Properties **Place at** (dropdown) Determines where along the detected axis the pivot lands: at the height you clicked, in the middle of the feature, or at either end. Use *Middle of extent* for a shaft that should rotate about its center, and *Clicked position* when the pivot belongs on a specific face. **Surface angle** (degrees) The maximum angle between neighbouring triangles that still counts as the same surface, 35° by default. Raise it for very coarse tessellation, lower it if the detection runs across a chamfer onto an adjacent face. **Align local axis to circle axis** (boolean) Rotates the object so the chosen local axis (X, Y or Z) points along the detected axis — the fastest way to prepare a part for a rotational **Drive**. This works when the circle sits on a *different* object than the one being rotated; aligning an object to a feature on itself is geometrically impossible, since the geometry turns with the object, and the tool tells you so. ### What the tool reports The panel always shows the radius, the axis and the deviation of the fit. A small deviation confirms that the surface really is round and that the detection covered it completely. If a reliable circle cannot be determined, the tool refuses to return a result and names the reason instead of silently placing the pivot somewhere plausible — for example when only part of the circle is covered, when the surface is curved but not cylindrical (a sphere, torus or free-form face), or when the surface is not round enough. Click a more complete round face, or raise the surface angle if a coarsely tessellated cylinder is being cut short. ### Automating it The same detection is available to AI assistants and scripts through the MCP tool `transform_circle_center`, which takes an object path and a world-space ray and returns center, axis and radius. Interactive and automated results are identical, because both use the same detection core. ## Tips and Best Practices ### Precision Techniques * **Zoom for accuracy**: Use Scene View zooming to ensure precise vertex selection * **Multiple angles**: View selection areas from different angles to confirm correct vertex targeting * **Grid snapping**: Enable Unity's grid snapping for additional positioning precision ### Workflow Optimization * **Test before committing**: Use Unity's undo system to experiment safely with different positioning options * **Scene organization**: Work with simplified scene views when positioning complex assemblies * **Verification**: Always verify the selected object and intended pivot point before applying changes ### Complex Scenes * **Object isolation**: Use Unity's isolation mode for complex scenes with overlapping geometry * **Layer management**: Organize objects on different layers for easier selection * **Naming conventions**: Use clear GameObject names for easier identification during selection ## Reset and Undo Operations ### Reset Functionality The **Reset** button clears all current selections and settings: * Deselects all point selections * Clears Object 1 and Object 2 references * Removes all visual gizmos and indicators * Returns the tool to its initial state ### Undo Support All Move Pivot operations are fully integrated with Unity's undo system: * Use **Ctrl+Z** (Windows) or **Cmd+Z** (Mac) to revert positioning changes * Multiple undo levels supported for complex positioning sequences * Undo history preserved across tool sessions ## See Also * [Unity Editor Tools](https://github.com/game4automation/doc/tree/doc/basics/editor-tools.md) - Overview of realvirtual editor utilities * [Component Positioning](https://github.com/game4automation/doc/tree/doc/components/positioning-components.md) - Guide to precise component placement * [Scene Setup Best Practices](https://github.com/game4automation/doc/tree/doc/basics/scene-setup.md) - Efficient scene organization techniques # Selection Window (Pro) Working with large assembly structures {% hint style="info" %} The Selection Window is only available within the professional version. {% endhint %} The Selection Window is enabling a fast selection of components in the 3D assembly (game object) hierarchy. You can select components based on the visibility status, assign [groups ](/components-and-scripts/motion/group)to components and view and hide groups. ## **Opening the selection window** To open the Selection window please select *`realvirtual`*`> Selection window (Pro)` in the realvirtual.io menu. This will open this window:
### **Actions with ALL** In the section `Actions with ALL` you can sop the suppression of all components or show all hidden components. ### **Selection** It is important to know that there are two levels of selection. The first one is the normal Unity Selection (this means all highlighted objects in the hierarchy). You can save currently selected objects in a temporarily g4a selection by pushing `Add selected`. All actions that you are performing under `Actions with Selection` are performed on the Unity AND rvselection. | Button | Description | | -------------------- | ------------------------------------------------- | | `Add selected` | Adds the selected components to the rvselection | | `To Unity selection` | Moves the rvselection to the Unity selection | | `Remove selected` | Removes the selected objects from the rvselection | | `Remove all` | Removes all objects from the rvselection | | `Select Invisible` | Selects all invisible objects | | `Select Visible` | Selects all visible objects | | `Select Unlocked` | Selects all unlocked objects | | `Select Locked` | Selects all locked objects | | `Select Layer` | Selects all objects on the defined layer | | `Select Material` | Selects all objects with the defined material | ### **Actions with selection** These are actions that you can perform with the selected objects. The actions are always performed for all objects in the current Unity and realvirtual.io selection. | Button | Action | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | `Assign Material` | Assigns the selected material | | Change Shader | Changes the shader of the material | | Material Update | With a material update, defined materials in a scene can be replaced with others. [Material Update](#material-update) | | `Suppress children` | Suppresses all children components in the hierarchy view | | `To new Parent` | Moves the components to the new (selected) parent | | `Copy to empty Parent` | Makes a copy of the components and moves them to the new (selected) parent | | `To Layer` | Moves the components to the defined layer | | `Visible` | Makes the selected components visible | | `Invisible` | Makes the selected components invisible | | `Isolate` | Isolates the selected components (and makes the rest invisible) | | `View all` | Stops the isolation and displays all components | | `Lock` | Locks the components | | `Unlocked` | Unlocks the components | | `To Group` | Assigns the components to the defined group. If the group is not yet existing it is created. | | `Remove Groups` | Removes all groups from the selected components | | `Collapse same level` | Collapses all components to the same hierarchy level | | `Expand same levels` | Expands all components to the same hierarchy level | | `Pivot to origin` | Moves the pivot of the component to the origin of the defined component | | `Pivot to center` | Moves the pivot of the component to the center of the defined component | | `Static` | Makes the components static | | `Movable` | Makes the components non-static (movable) | | `Remove G4A scripts` | Removes all realvirtual.io Scripts from the selected components | | Remove missing scripts | Removes all null-components from the current selection | | Bake to single mesh | Combines all selected meshes to one mesh and saves it to a new gameObject. You can define a name for this gameObject in "Name baked mesh:" | ### **Groups** In the Group section, you can find all groups that are defined in the current model. | Button | Action | | ------ | --------------------------------------------------------------- | | Plus | Adds the selected components to the Group | | Minus | Removes the selected components from the Group | | Hide | Hides all components which are currently belonging to the Group | | Show | Shows all components currently belonging to the Group | ### Material Update The Material update allows you to replace defined materials in a scene with others by one click. To use this feature, you need to define an update by creating an asset called "MaterialUpdate" in the current folder, which can be defined in the Inspector. To create the asset, right-click in the Project area and select "Create/realvirtual/Add material update settings".

material update

You can use the following parameters to specify which materials should be replaced:\ material, RGB color, and material name or partial name.\ All of these input parameters are considered in the order listed.\ You can assign a specific material or a blueprint material, but only one of these options can be defined at a time.\ Multiple mappings can be defined, and to add another mapping, simply click on the "+" button. The mappings in the list are carried out sequentially, and they can overwrite each other.\ The material update replaces materials of imported, non-instantiated prefabs with instantiated ones, resulting in improved performance. ,\ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Material Window (Pro) Improve work with imported CAD-data {% hint style="info" %} The Material Window is only available within the professional version. {% endhint %} {% hint style="info" %} Duplicate detection feature was added in realvirtual **6.0.7** (Professional) {% endhint %} The Material Window makes it easy to assign materials to selected objects and includes integrated duplicate detection to identify identical meshes in your scene for performance optimization.

Material Window showing duplicate detection with "Found 3 identical copies" header and Identical (4) buttons

### Opening the material window To open the material window please select: Tools > realvirtual > MaterialWindow (Pro). ### Choose a material palette To select a palette, simply click on the current material list. If you want to create your own material, click on "New material set". This creates an asset called: "MaterialPalet" in the Assets folder and displays its parameters in the Inspector. You can then create your material list. ### Duplicate Detection When you select an object in the scene hierarchy, the Material Window automatically detects identical meshes: **Selection Header** * **Selected Object Name** – Displays the name of the currently selected GameObject * **Duplicate Count** – Shows "Found X identical copies" if duplicates are detected **Identical Meshes Indicator** * **Identical (X) Button** (green) – Appears on the right side of each material row * **Click to Open Duplicate Finder** – Opens the full Duplicate Finder window for detailed analysis * **Real-time Detection** – Updates automatically when selecting different objects This integrated duplicate detection helps you quickly identify optimization opportunities while working with materials, making it easy to find and consolidate identical geometries in your scene. ### Select and set materials The material window contains a palette of materials with the following actions: * **Apply** – Assigns the material to the currently selected object * **Apply All** – Assigns the material to all objects in the current selection * **Identical (X)** – Opens Duplicate Finder for the material's associated meshes (when duplicates exist) ## See Also * [Duplicate Finder](/basics/user-interface/duplicate-finder) - Full duplicate detection tool with scene visualization * [Model Checker](/basics/user-interface/model-checker) - Scene validation and optimization tool # Measurement (Pro) Taking measures in the editor window {% hint style="info" %} Measurement is only included in realvirtual.io Professional {% endhint %} The Measurement tool, designed for use within the Unity Editor's scene window, facilitates the precise measurement of distances between two points in a scene. It extends its functionality by calculating the center point upon selecting a third point, drawing the circle that intersects these points, and providing the circle's diameter and radius.

Measure tool in unity editor mode

### Accessing the Tool * Navigate to `Tools > realvirtual > Measurement (Pro)` in the main menu to open the tool.
### How to Use 1. **Initial Point Selection**: Upon opening, the tool automatically sets to select the first point. After choosing the first point, it transitions to selecting the second point. 2. **Measuring Distance**: After the second point is selected, the tool calculates and displays the distance between the two points, including distance breakdowns on each axis. Optionally, distances can be displayed in millimeters. 3. **Determining a Circle**: * Click the 'Point3' button to enter the selection mode for a third point. * Selecting the third point draws the circle defined by the three points and shows the circle's diameter and radius in the tool's window. 4. **Resetting Selections**: The 'Reset' button clears all selections, enabling the user to start anew with the selection process. # Kinematic Tool (Pro) Defining kinematics in complex CAD designs {% hint style="info" %} The Kinematic Tool is only included in realvirtual.io Professional edition. If you don't use the Professional edition please use [Kinematic ](/components-and-scripts/motion/kinematic)and [Group ](/components-and-scripts/motion/group)together with manually adding [Drives](/components-and-scripts/motion/drive) or Physical joints. {% endhint %} The `KinematicTool` provides a graphical user interface (GUI) for creating, configuring, and managing kinematic axes and their components within realvirtual. It enables users to easily create and manipulate axes, set axis references, manage limits, and handle connections between axes and other components. The tool saves all configurations in the Axis script, which is automatically added to relevant components. In the background, the KinematicTool adds necessary standard components such as [Drives](/components-and-scripts/motion/drive), [Kinematic](/components-and-scripts/motion/kinematic), and [Group ](/components-and-scripts/motion/group)based on the kinematic definition. Users can define Kinematic Axes (with [Drives](/components-and-scripts/motion/drive)) that precisely follow the Drives' positions, as well as Physical Axes (with Unity PhysX Joints) that are controlled purely by Unity's physics connections. For a detailed walkthrough of using the Kinematic Tool, be sure to check out our [YouTube tutorial](https://youtu.be/nPNgIWcwDAM). {% embed url="" %} ## Open the Kinematic Tool To open the Kinematic Tool window, you can: * Select **Tools > realvirtual > Kinematic Tool** in the realvirtual.io menu. * Click the **"Axis"** button within the realvirtual scene overlay menu. * Use the hotkey **"Alt+K"**.
## Create a Kinematic Axis **Open the Kinematic Tool:** * The Axis will be created as a child of the currently selected GameObject when you open the Kinematic Tool. * Enter a new **Axis Name** in the provided field. * Click **Create Axis** to generate the Axis.

Create a new Axis

## Select Axis Reference After creating the Axis: 1. **Select a Reference GameObject:** * Choose a GameObject that will define the position of the Axis. This GameObject does not need to be part of the Axis itself; it serves to establish the center point of rotation or direction of movement. 2. **Visualize Reference Points:** * While in Set Axis Reference mode, you can hover over GameObjects. The geometrical center will be marked with a white cross, while the pivot point of the object will be indicated by green, red, and blue crosses. These centers can be used as reference points. 3. **Choose Reference Type:** * **Pivot Point:** Preferably use the pivot point of the GameObject for accurate Axis positioning. * **Bounding Box Center:** Use this if the pivot point is not suitable. * **Radius Center:** Select this if no appropriate object is available. For the Radius Center, you need to choose three vertices on the object to define the center point.

Select Axis Reference

By following these steps, you ensure precise positioning and orientation of your Kinematic Axis. ## Select Axis Direction * **Select the Axis Direction:** * After selecting the reference point, the next step is to set the direction of the Axis. You can choose the direction, which will be displayed as a pink line in the editor. Or you can iterate through some options with "Ctrl + D". * It is possible to efine an offset for the current axis rotation. Browse standard values using\ "Ctrl + R". * **Visualize the Axis Type:** * The type of the Axis will be indicated using a gizmo, which helps in visualizing the axis configuration. * **Adjust Gizmo Distance:** * Modify the line length and distance by using the Gizmo Distance option. This allows for precise adjustments to the visual representation of the Axis in the scene.

Selecting the Axis Direction

* **Axis Direction:** Choose the direction from the drop-down menu or browse options with "Ctrl + D". * **Axis Rotation:** Define an offset for the current axis rotation. Browse standard values using\ "Ctrl + R". When creating a physical axis that adheres to specific movement constraints, you should define upper and lower limits. This ensures that the axis respects these boundaries during operation. ## Select parts belonging to the Axis An Axis is a kinematic component that consists of several GameObjects moving together. To define which GameObjects are part of the Axis, follow these steps: ### Select Parts Mode (Selecting with hovering over the parts) 1. Select Parts Mode: * Activate "Select Parts" mode to start defining which parts will be associated with the Axis. 2. Highlight and Select Parts: * Hover over the parts in the Scene that should belong to the Axis. The mesh of the parts will be highlighted for easy identification. Click the left mouse button to add the highlighted parts to the Axis. 3. Deselect Parts: * To remove parts from the selection, hold the "Shift" key while clicking on them. This mode is particularly useful if the CAD structure is not oriented towards kinematics, requiring you to select each part individually. ### Select Parts in the Scene (Selecting in the Hierarchy View). To exit "Select Parts" mode, click the pink button associated with this mode. You can then select parts directly in the Hierarchy view. This approach is useful if the CAD structure is already somewhat kinematic-oriented, and you wish to select entire hierarchy elements. After selecting elements in the Hierarchy view, click "Add Selected Parts" to include all selected parts and their subparts in the Axis. ### **Select Parts by Collision Detection** 1. **Select Neighbours:** * Use the "Select Neighbours" function to select all neighboring parts of the currently defined Axis parts. This function only recognizes immediate neighbors. 2. **Fill:** * The "Fill" option selects all parts located between the currently selected components. 3. **Select Connected:** * The "Select Connected" function identifies all parts connected to the selected components, including those that are not immediate neighbors. After using "Select Neighbours," "Fill," or "Select Connected," the detected parts will be highlighted in Unity's Hierarchy view. You can review the selections before finalizing the process. Click "Add Selected Parts" to incorporate these parts into the Axis. ## Adding a Drive To control the Axis with a drive, click "Add Drive." This action means the Axis's position will be fully managed by the Drive. If you choose not to add a Drive, the Axis will be controlled entirely by physical joints. ## Changing the View, Isolate and Hide Mode While selecting parts, you can adjust the view by using the "Isolate" or "Hide" buttons. These options allow you to isolate or hide selected parts for better visibility and management.

Isolate Mode while seelcting parts

## Defining the Kinematic Hierarchy ### **For Drive-Controlled Axis:** * To define a kinematic hierarchy for Drive-controlled axes, you can simply arrange one axis below another in the hierarchy.

Kinematic hierarchy by parent child relations in Gameobjet hierarchy

* Alternatively, you can specify the Kinematic parent under "Connected Axis." This will automatically establish the kinematic hierarchy when the simulation begins. ### **For Physical Axis:** * Physical axes are controlled by Unity physics through joints and do not have a drive. Therefore, you should avoid using the GameObject hierarchy to represent the kinematic chain. Instead, use "Connected Axis" to define kinematic connections. * In cases where you need to have two axes on one kinematic object, define the additional axis as a child of the first physical axis and select "Secondary Axis." This setup will automatically create two or more joints on one Rigidbody when the simulation starts.

Secondary Axis (TCPConnection) one one Axis (TCP)

© 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Clean Restart (Pro) ## Clean Restart Unity Automatically restart Unity with a clean cache to fix import issues and ensure clean configuration changes. {% hint style="info" %} **Professional Feature**: Clean Restart Unity is only available in realvirtual Professional. {% endhint %} **realvirtual → Settings → Clean Restart Unity (Pro)** ### What It Does 1. Saves your current work 2. Closes Unity completely 3. Deletes the Library folder (Unity's cache) 4. Restarts Unity automatically 5. Reimports all assets with clean cache {% hint style="warning" %} This process takes 5-15 minutes depending on project size. {% endhint %} ### When to Use * **After configuration changes** (switching between Professional/Starter/etc.) * **Import errors or corrupted assets** * **Shader compilation problems** * **Unexpected Unity behavior** * **Before important builds** ### How to Use 1. Click **realvirtual → Settings → Clean Restart Unity (Pro)** 2. Confirm the dialog 3. Wait for Unity to restart and reimport assets The process is fully automated - just wait for completion. ### For Non-Professional Users If you don't have realvirtual Professional, you can achieve the same result manually: #### Manual Clean Restart Steps: 1. **Save your work** in Unity 2. **Close Unity completely** 3. **Delete the Library folder** in your project directory * Navigate to your project folder * Delete the entire `Library` folder 4. **Restart Unity** and open your project 5. **Wait for reimport** (5-15 minutes) #### Important Notes: * The `Library` folder is Unity's cache - deleting it is safe * Your project files (`Assets`, `ProjectSettings`) are never touched * Unity will recreate the Library folder automatically ### Troubleshooting **Unity won't close?** Wait 2 minutes, then use Task Manager (Windows) or Activity Monitor (Mac) to force-close Unity processes. **File access errors?** Temporarily disable antivirus real-time scanning during the process. **Long reimport times?** This is normal for large projects - be patient and let Unity finish. # Model Checker Finding common issues in your model In new scenes, the Model Checker runs automatically upon scene startup to detect common issues and recommend performance optimizations. You can activate the checker using the shortcut Alt+T or via the main menu. To deactivate it, use the provided buttons in the UI. Select the "Info" button to view relevant documentation pages, or choose "Show" for certain issues to highlight related game objects in the scene.

Model Checker for detecting common issues in the current scene.

Alternatively, the Model Checker can be disabled through the setting in the scene's realvirtualController.

Turning off model checker in realvirtualController

Here is an overview of the performed checks: 1. **CheckNonStaticMeshes:** Identifies non-moving GameObjects without Drive components in parent hierarchies. 2. **CheckStaticMeshes:** Detects static meshes under drives that prevent movement. 3. **HugeMeshes:** Warns about objects with excessively large vertex counts (>5% of total) compared to others. 4. **NumberOfMeshes:** Advises on optimizing performance by reducing the number of meshes if exceeding 1000. 5. **NonSharedMaterials:** Alerts about GameObjects with a high number of distinct materials (>20) for optimization. 6. **MUsWithoutRigidbody:** Highlights MUs lacking Rigidbody components for physics interactions. 7. **GuidedTransport:** Identifies MUs without GuidedMU components needed for guided transport surfaces. 8. **SensorRaycastLayer:** Advises adding standard layers (rvMU or rvMUSensor) for Raycast Sensors to detect collisions with MUs. 9. **CheckSinkLayer:** Advises using the standard layer (rvSensor) for Sink components for collision detection with MUs. 10. **SensorColliderLayer:** Suggests using the standard layer (rvSensor) for Collider Sensors for efficient collision detection with MUs. 11. **ComplexColliders:** Notes the presence of numerous Mesh Colliders (>20) and suggests using simpler colliders like Box Colliders for better performance. 12. **ManyColliders:** Alerts about a high number of colliders (>300) in the scene, advising reduction for performance improvement. 13. **CollidersOnNonStandardLayers:** Identifies Colliders not on standard layers (rvMU, rvMUSensor, rvTransport, rvSelection, rvSensor), recommending standard layers for efficient collision detection. 14. **NumberOfLights:** Advises optimizing performance by reducing the number of lights (>2) and turning off shadows. These checks aim to improve scene performance and functionality by identifying common issues and providing actionable recommendations. # Duplicate Finder (Pro) {% hint style="info" %} This feature was added in realvirtual **6.0.7** (Professional) {% endhint %} **Duplicate Finder** is an editor tool that identifies identical meshes in your scene using hash comparison, enabling performance optimization through asset consolidation. ## Overview The Duplicate Finder analyzes meshes in your scene and identifies geometrically identical objects, even if they have different names or are positioned differently. This helps optimize scene performance by consolidating duplicate assets. ## Key Features * **Mesh Hash Comparison** – Uses sophisticated hashing to identify identical geometries * **Visual Scene Highlighting** – Shows duplicate objects with wireframe gizmos and labels * **Performance Optimization** – Reduces memory and rendering overhead * **Batch Operations** – Select and manage multiple duplicates at once * **Scene Hash Caching** – Speeds up repeated analysis with cached hash data ## Accessing Duplicate Finder Open the tool from Unity's menu: `Tools > realvirtual > Duplicate Finder (Pro)`

Duplicate Finder window showing 6 clones of a fence object with scene visualization

## How It Works 1. **Select an Object** – Select any GameObject in your scene hierarchy 2. **Automatic Analysis** – Duplicate Finder calculates mesh hash and finds matches 3. **Visual Feedback** – Identical objects are highlighted in the scene view 4. **Take Action** – Review and consolidate duplicates to optimize performance ## Window Interface

Duplicate Finder interface showing visualization options, action buttons, and clone list

The Duplicate Finder window is organized into several sections: ### Visualization Options * **Show Wireframe Gizmos** (checkbox) – Display yellow wireframe outlines around duplicate objects in scene view * **Show Number Labels** (checkbox) – Show numeric labels \[0], \[1], \[2], etc. above each duplicate instance * **Refresh** (button) – Recalculates mesh hashes and updates duplicate detection ### Action Buttons * **Select All (X Clones + Original)** (green button) – Selects all duplicate objects plus the original in the scene hierarchy. The button displays the total count dynamically. * **Materials to Clones** (button with brush icon) – Copies all materials from the selected object to all detected clones * **Components to Clones** (button with gear icon) – Copies all components from the selected object to all detected clones ### Clone List * **Selected Object** – Shows the currently selected object name at the top (highlighted with blue cube icon) * **Numbered Clones** – Lists all detected duplicates with sequential numbers \[0], \[1], \[2], \[3], etc. * **Object Names** – Displays the GameObject name for each clone with blue cube icon * **Navigation Icons** – Click the circle icon on the right to select and navigate to that object in the hierarchy ### Status Display At the bottom of the window, a yellow warning triangle displays: **"Found X duplicate(s) of the selected object"** ## Common Applications * **CAD Import Optimization** – Identify repeated components in imported CAD assemblies * **Scene Performance** – Reduce memory usage by consolidating identical meshes * **Asset Management** – Find opportunities to reuse existing prefabs * **Quality Assurance** – Verify component standardization across factory layouts ## Performance Impact **Benefits of Consolidation:** * Reduced memory footprint from shared meshes * Improved rendering performance with fewer unique geometries * Better asset management with prefab reuse * Smaller build sizes ## See Also * [Material Window](https://github.com/game4automation/doc/blob/doc/basics/user-interface/material-window.md) - Material management with duplicate detection * [Model Checker](/basics/user-interface/model-checker) - Scene validation tool # Mesh Tools (Pro) {% hint style="info" %} This feature was added in realvirtual **6.3.3** (Professional) {% endhint %} **Mesh Tools** is a tabbed editor window that combines mesh-related utilities for working with imported CAD models. It provides two tools: **Auto Correct Pivots** for fixing off-center mesh origins, and **Mesh Separator** for splitting combined meshes into individual parts. ## Accessing Mesh Tools **Editor Window:** `Tools > realvirtual > Mesh Tools (Pro)` **Context Menu (quick access for Mesh Separator):** * Right-click a GameObject > `realvirtual > Separate Mesh` * Right-click a GameObject > `realvirtual > Merge Child Meshes` *** ## Tab 1: Auto Correct Pivots

Correct Pivots tab showing analysis results for a conveyor system — all 12 meshes passed with zero offset

### Overview CAD models frequently arrive with mesh pivots (transform origins) far away from the actual geometry. A small bracket might have its origin at the machine's global zero point, hundreds of millimeters away. This causes poor rotation behavior, difficulty placing objects, and issues with Drive axes. Auto Correct Pivots fixes this by recentering the mesh vertices around the local origin and compensating the transform so the geometry stays in exactly the same world position. ### How It Works For each mesh in the selected hierarchy, the tool: 1. Calculates how far the mesh center is from the local origin 2. Clones the mesh and offsets all vertices so the center becomes the origin 3. Moves the transform to compensate, keeping the mesh visually in place 4. Preserves all child positions so nothing in the hierarchy shifts 5. Updates any MeshCollider referencing the original mesh 6. Saves the corrected mesh as an asset in `Assets/CorrectedPivots/` ### Settings * **Root Object** -- The root GameObject to scan. All MeshFilters in the hierarchy below this object are analyzed. Defaults to the current selection. * **Min Offset (mm)** -- Only meshes whose pivot is further than this distance from the mesh center are corrected. Default: `1.0` mm. Increase this to skip meshes with minor offsets. ### Workflow 1. Select the root object of your imported CAD model 2. Open `Tools > realvirtual > Mesh Tools (Pro)` 3. The **Auto Correct Pivots** tab is shown by default 4. Set the root object and adjust the threshold if needed 5. Click **Analyze** to scan the hierarchy -- the results list shows each mesh with its offset distance 6. Review the results -- click any item to ping/select it in the Hierarchy 7. Click **Apply All Corrections** to batch-correct all meshes above the threshold 8. Use **Ctrl+Z** to undo the entire operation if needed ### What Gets Skipped * Meshes with offset below the threshold * GameObjects with a SkinnedMeshRenderer (bone-based skinning would break) * MeshFilters with no mesh assigned or with zero vertices ### Notes * Corrected meshes are saved as `.asset` files in `Assets/CorrectedPivots/`. You can safely delete this folder to reclaim disk space -- the meshes are referenced by the scene. * If multiple GameObjects share the same source mesh, each receives its own corrected copy. * The operation works correctly on rotated and scaled objects, including objects deep in nested hierarchies. *** ## Tab 2: Mesh Separator

Mesh Separator with color-coded island preview in the Scene view — 18 islands detected on a machine assembly

### Overview CAD imports and mesh-baking tools often produce a single mesh containing multiple disconnected parts. The Mesh Separator detects these disconnected islands using a Union-Find algorithm with configurable vertex welding and lets you split them into individual GameObjects. You can also reverse the process by merging multiple child meshes into one combined mesh. ### Key Features * **Island Detection** -- Automatically finds disconnected mesh regions using vertex connectivity analysis * **Color-Coded Preview** -- Each island is highlighted with a unique color overlay and wireframe in the Scene view * **Selective Separation** -- Choose which islands to separate using per-island toggles * **Mesh Merging** -- Combine multiple child MeshRenderers into a single mesh on the parent * **Vertex Attribute Preservation** -- Normals, tangents, UVs (all channels), vertex colors, and bone weights are preserved * **Sub-Mesh & Material Support** -- Material assignments and sub-mesh structure are maintained during separation ### Settings * **Weld Threshold** -- Vertices closer than this distance (in meters) are treated as the same point for connectivity detection. Default: `0.0001`. Increase this value if islands that should be connected are being split apart. * **Delete Original Mesh** -- When enabled, the original MeshFilter and MeshRenderer are removed after separation. When disabled (default), the original renderer is simply disabled. * **Auto Preview** -- Automatically updates the island preview whenever you select a new object. ### Islands Shows the detected islands with color swatches and vertex/triangle counts. Use the checkboxes to select which islands to separate. The **All** and **None** buttons quickly toggle all islands. ### Actions * **Separate All** -- Separates every detected island into its own child GameObject * **Separate Selected** -- Separates only the checked islands * **Merge Child Meshes** -- Combines all child MeshRenderers into one mesh on the selected parent object ### Workflow 1. Select a GameObject with a combined mesh in your scene 2. Open `Tools > realvirtual > Mesh Tools (Pro)` and switch to the **Mesh Separator** tab 3. The preview activates automatically, coloring each island in the Scene view 4. Toggle individual islands on/off using the checkboxes 5. Click **Separate All** or **Separate Selected** 6. The separated parts appear as child GameObjects with individual meshes ### Common Use Cases * **CAD Assembly Splitting** -- Break apart imported CAD models that were exported as a single combined mesh into individual parts for animation or interaction * **Drive Assignment** -- Separate a combined mesh so each part can be assigned to its own Drive component for independent motion * **Selective Export** -- Split a mesh to isolate specific parts for GLB export or WebViewer usage * **Performance Optimization** -- Merge previously separated parts back into one mesh to reduce draw calls * **Sensor Preparation** -- Create individual colliders per part by separating the mesh first *** ## See Also * [Duplicate Finder (Pro)](/basics/user-interface/duplicate-finder) * [Mesh Optimizer (Pro)](/components-and-scripts/performance-tools/mesh-optimizer-pro) * [Combine Meshes (Pro)](/components-and-scripts/performance-tools/combine-meshes-pro) # Group Assignment Tool (Pro) Assign GameObjects to groups by clicking directly in the Scene View {% hint style="info" %} The Group Assignment Tool is a new feature in realvirtual **6.3.4**. It is a **Professional-only** feature and is not available in the Starter version. {% endhint %} The Group Assignment Tool is a dedicated scene-picking tool for organizing GameObjects into [Groups](/components-and-scripts/motion/group) by clicking, dragging, or assigning whole connected assemblies directly in the Scene View. It complements the hierarchy-based [Selection Window](/basics/user-interface/selection-window) and the axis-based [Kinematic Tool](/basics/user-interface/kinematic-tool-pro) with a pure scene-picking workflow for rapid bulk assignment.
Group Assignment Tool assigning fences to a group in the Scene View

Painting meshes into the "Fences" group directly in the Scene View

## Opening the Tool Open the tool in one of three ways: * Menu `Tools > realvirtual > Group Assignment (Pro)` * Keyboard shortcut `Alt+G` * The Group Assignment toolbar toggle in the Scene View overlay toolbar ## Scene Picking The large button at the top toggles **Scene Picking** on and off. When it is **ON** (green) you can pick meshes in the Scene View; when **OFF** (yellow) the tool is idle and normal selection works as usual. Press `Escape` in the Scene View to switch picking off at any time. ## Active Group Pick the group you are currently assigning to from the **Active Group** dropdown, or type a name into **New Group** and press **+ Create** to start a fresh group. The active group name is shown in its group color and is remembered across Editor sessions. ## Modes | Mode | Action | | ------------- | ----------------------------------------------------------------------------------------------- | | **Assign** | Click (or drag over) meshes to add them to the active group. | | **Remove** | Click meshes to remove them from the active group. | | **Connected** | Click a mesh to assign its entire connected assembly (flood-fill). Requires the Burst Compiler. | You can also use modifier keys while in any mode: **Shift + Click** removes, and **Ctrl + Click** assigns the connected assembly. ### Connected Mode and Tolerance In **Connected** mode, hovering a mesh previews the whole connected blob in the group color, and clicking assigns all of it at once. The **Tolerance** slider (0–5 mm) controls how large a gap between meshes is still treated as "connected" — increase it to bridge small gaps in imported CAD geometry. A status line shows how many blobs and meshes were detected, and an **Undo Last** button reverts the most recent connected assignment in one step. {% hint style="info" %} Connected mode requires the Burst Compiler. Without it the button is disabled. {% endhint %} ## Options | Option | Description | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Include Children** | Also assigns the clicked object's child meshes to the group. | | **Exclusive (only unassigned meshes)** | Skips meshes that already belong to any group, so you only fill the gaps. Blocked meshes are highlighted red on hover. | | **Isolate Unassigned** | Hides all meshes that already have a group, leaving only the unassigned ones visible — a fast way to find what still needs assigning. | | **Show All Group Colors** | Tints every grouped mesh in its group color directly in the Scene View. Uses a MaterialPropertyBlock, so there is no per-frame performance cost. | A progress line below the options shows how many meshes in the scene are already assigned, for example `73/100 meshes assigned (73%)`. ## Groups List The **GROUPS** list shows every group in the scene with a color swatch, member count, and a filter field. Click a group name to make it active. Each row has the following buttons: | Button | Action | | -------- | ------------------------------------------------------------- | | **Sel** | Selects all members of the group in Unity. | | **Isol** | Isolates the group — hides every mesh that is not a member. | | **Hide** | Hides all members of the group. | | **✕** | Removes the group and all its assignments after confirmation. | ## History The **History** panel lists the last 10 assignments (newest first). For each entry you can press **✕** to remove that object from the group again, or **◎** to ping and frame the object in the Scene View. ## Bottom Bar | Button | Action | | -------------------- | -------------------------------------------------------------------------- | | **Show All** | Restores everything hidden by Isolate / Hide / Isolate Unassigned. | | **Reset Highlights** | Clears all hover and group-color highlights. | | **Refresh** | Rescans the scene and rebuilds the group list, statistics, and highlights. | ## Quick Start 1. Open the tool with `Alt+G` and make sure **Scene Picking** is ON. 2. Choose an **Active Group** or create a new one with **+ Create**. 3. In **Assign** mode, click or drag over the meshes you want to add. Use **Ctrl + Click** to grab a whole connected assembly. 4. Use **Show All Group Colors** to review the result, then refine with **Shift + Click** (remove) where needed. ## See Also * [Group](/components-and-scripts/motion/group) – the component that stores the group assignment * [Selection Window (Pro)](/basics/user-interface/selection-window) – hierarchy-based selection and grouping * [Kinematic Tool (Pro)](/basics/user-interface/kinematic-tool-pro) – axis-based assignment for kinematic chains * [Group Manager](/basics/runtime-ui/group-manager) – runtime visibility control of groups \ © 2026 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Runtime UI User interface for the published Digital Twin The Runtime UI will be, if you compile your project to any destination platform, part of your delivered Digital Twin. The Runtime UI can be customized by yourself and extended with the standard Unity UI components if you wish. You can have a preview of the Runtime UI in the Game Window during simulation mode in Unity editor. The Runtime UI is part of the realvirtual.io prefab. It can be enabled and disabled in the Realvirtual (before 2022 *Game4AutomationController)*, which is a script on the top level of the [Realvirtual](/components-and-scripts/game4automation) prefab. The Runtime UI looks like this:

Runtime UI of the Digital Twin

### Top Menu

Top menu runtime ui

In the top menu bar of the RuntimeUI you find the following buttons. | Button | Description | | ---------------------------------------- | --------------------------------------------------------------------------------------------- | | Play | Pushing on the play button will restart the simulation | | Pause | Pauses the simulation | | Step Forward | Steps one physics step forward | | Ortohogonal / Perspective | Switches between ortogonal and perspective view | | Side / Top / Frond View Overlay | Turns on/off the Orthographic side views | | First Person Controller / CAD controller | Switches between first person controller and cad like mouse controller | | Object Selection | enables object selection | | Connection Status | Switches the connection status and displays in green if an interface is connected (see below) | | Quality Settings | Allows to change the render quality - this only works in Standard Render Pipeline | If you don't need the Runtime UI it can be turned off in the Game4AutomationController bei deselecting *UI Enabled on Start*. It is also possible to turn off certain buttons in the Top Menu by deactivating the Gameobjects. ### Connection Status ![](/files/xmK53LgoUhK4MJX8oafG)\\ If you toggle this button the connection status will be switched between *Connected* and *Disconnected*. All realvirtual.io objects which are based on the *realvirtual.ioBehavior* class can be enabled or disabled based on this connection switch. \ The main usecase of this switch is to have one model which can run in Simulation mode, where everything in the model is controlled by included scripts and in Virtual Commissioning (Connected) mode, where some scripts might be disabled and interfaces are enabled. With this option you can decide this on a very detailed level for every component. ![](/files/B4XY3ZWGfVuNuUm933il) For this all realvirtual.io components have the property **Active** this property can be one of the following | Value | Description | | ------------ | ----------------------------------------------------------------------------------------------------- | | Always | The script is always active, independent from the connection switch | | Connected | The script is only active when the connection switch is set to Connected (the plugs are connected) | | Disconnected | The script is only active when the connection switch is set to Disconnected (the plugs are connected) | | Never | The script is never active and always disabled | | Don't change | The script enabled status is not changed based on the Connection Switch | If you implement your own behavior components you need to implement your enable and disable logic of your script into the standard methods *OnEnable* and *OnDisable*. The interface base classes already have this and call automatically *OnConnect()* and *OnDisconnect()*. ### Object Selection ![](/files/G7Rr61EdlbkDK9Hs9IvX) {% hint style="danger" %} In runtime it might happen, that not all meshes can be hovered / selected. This is due to static batching in the Player settings. Please turn off `Project Settings > Player > Other Settings > Static Batching` {% endhint %} The object selection enables selection of scene elements and offers options for focusing on and rotating around objects. It can be enabled or disabled by setting the *ObjectSelectionEnabled* property in the [Game4AutomationControlle](/components-and-scripts/game4automation)r.

Activated object selection with selected CAN object (with RuntimeInspector enabled in Game4AutomationController)

{% hint style="info" %} Object selection is using a mesh collider, which is added to every game object at the start, if no collider is already present. These gameobjects are assigned to *g4a Selection* layer. Further information concerning Layers is described in [Physics](/basics/physics). {% endhint %} While navigating the scene with the mouse pointer, moving the pointer over an object will highlight it. By clickon on an object it will get selectid. If the *RuntimeInspector* is enabled in [RealvirtualController](/components-and-scripts/game4automation) the properties of the selected objectare displayed. The "Runtime Inspector" is disabled in the [demo model.](/basics/demo-model) | key | action | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- | | one click left mouse button | object is selected | | double click left mouse button | object is selected and the camera focus is set | | F | camera focus is set to the currently selected object | | right mouse button pressed | rotation around selected object | | ALT | as long as ALT is pressed the camera will follow the selected object. The selected object is centered and rotation is done around the object | | ESC | deselect the selected object | Additional configuration options for object selection can be accessed through the Selection Raycast Component, located on the Main Camera. Within this component, the Highlight Function, Highlight Colors, and Center Icon can be enabled or disabled, and their settings can be modified.

Additional settings for Object Selection in SelectionRaycast component on the main camera.

### Camera Positions Camera positions, perspective settings as well as the settings for the orthographic side views are saved to the current values as soon as you quit the scene. This is done by the *CameraPos* Scriptable asset. This asset can be assigned in the *SceneMouseNavigation*, which is attached to the main camera.

SceneMouseNavigation attached to the main camera, taking care about saved camera positions

If you use a standard *Realvirtual (before 2022 Game4automation)* component in your scene, all scenes are sharing the same standard camera settings. To create a new camera position setting you need to create a new scriptable component like this:

Creating a scriptable component for camera positions

You can save this asset wherever you would like to and assign it to the SceneMouseNavigation. For creating a new camera position or saving the camera position when you leave play mode you should turn on `Save Camera Pos On Quit`. You need to turn it off again if you don't want to change the Start Camera Position\\
#### Main Camera You can move the main camera as you are used to it in Unity Editor mode. If you want to change the sensitivity of movement, please change the settings in the *SceneMouseNavigation* script which is attached to the Main camera. Additionally there are some standard hotkeys (see below) for Front (F), Back (B), Top (T), Left(L) and Right (R) Side view for the main camera. #### Orthographic Camera / Side Views ![](/files/j2INr3jJAA9fjxwkZ5AN) Sometimes additional side, top and front views are very handy. This is for example the case, if you would like to teach a robot and have a good view on the current orientation and position. By selecting "O" or by using the Icon in the top menu bar 3 overlay windows are opened with 3 additional orthographic cameras.

Orthographic views can be turned on with Key "O"

You can move each orthographic view by using the mouse within the view. Pushin "O" again closes the view. With Plus and Minus on the Numpad you can increase the size of the views and with "Tab" you can rotate all the Orthographic cameras by 90 Degrees around the global Y axis.. ### Hotkeys Most hotkeys (besides standard camera navigation) are defined within the RealvirtualController (before 2022 *Game4AutomationController)* You can turn off all hotkeys by deselecting *Enable Hotkeys*. By selecting *None* in one hotkey only this hotkey is deactivated. ![](/files/CFvascNhAvoKB1cTH6Dq) ### Scene Navigation #### Mouse The scene mouse navigation is controlled by a script which is attached to the Main Camera, which is part of the realvirtual.io prefab. With the *SceneMouseNavigation* properties you can change the behavior and speed of the mouse navigation. #### Touch The touch navigation, which is mainly used for mobile devices, is also attached to the Main Camera. With the properties of the *TouchInterface* script you can control how the touch interface is behaving. ![](/files/OaBxlENB8YrdXW1xrwFi) #### First Person Controller New in Version 2019.3 is a included First Person Controller. You can move in the scene like in a First Person Shooter game.

First person view during simulation

The First Person View is enabled and disabled by the button with a mouse or a person in the top bar of the runtime ui. The first person view is active when the button looks like this: ![](/files/NfnSOgXlOiQUCQ6513Bi) During the First Person View you can control the view with the following buttons: | Button / Mouse | Description | | -------------- | --------------------------------- | | Mouse movement | changes the direction of the view | | W | moves forward | | A | moves left | | D | moves right | | S | moves backward | | Y | person goes into knees | | Shift | movement is faster | ### Runtime Inspector The runtime inspector is meant for debugging or inspecting in detail component properties. You can change these properties but the properties are not changed when you leave the simulation mode. This means that the runtime inspector is not meant to replace the Unity Editor. In standard settings the runtime inspector is disabled. You can turn the RuntimeInspector on in the Game4AutomationController settings: ![](/files/0QMyBXdERs5I6kwPDBSx)\ You can open the runtime inspector with the Arrows on the left hand side of your screen: ![](/files/wf7Mbx8EvpptbgR4HAoo) © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Group Manager Set visibility options of groups during Play Mode The `GroupManager` system enables the management of visual groups within the PlayMode. It facilitates showing, hiding, and toggling visibility of game objects and meshes based on predefined group settings. The `GroupManager` is part of the realvirtual prefab.
Under the "Visible Groups" section, you can configure settings for each group to be available in PlayMode. The parameters are: * Group Name: Select a group from the dropdown, which lists all scene groups. * Disable Game Object On Hide: Choose whether to disable the GameObject when the group is hidden. * Disable Mesh On Hide: Choose whether to disable the mesh renderer when the group is hidden. * Inactive On Start: Specify if the group should be hidden at the start of the application. ### Group Window in PlayMode During PlayMode the GroupWindow open by clicking on the GroupWindow Button in the main toolbar.
Each selectable group is listed. Groups with GameObjects disabled on hide are marked with a circle icon, while those using the mesh renderer are marked with an eye icon. # Debug Console Debugging without the Unity Editor in a Build The **Debug Console** in realvirtual.io is based on the [Unity Ingame Debug Console](https://github.com/yasirkula/UnityIngameDebugConsole), which is licensed under the **MIT License** (Copyright © Süleyman Yasir KULA). This tool provides **full access to Unity’s console log in a build** and allows the execution of **custom commands**. It is particularly useful for **debugging** and for modifying specific **player application properties** during runtime.

Debug Console

## How to Use the Debug Console 1. **Add the Debug Console Prefab**\ To enable the Debug Console in your project, add the prefab located at: ``` Assets/realvirtual/UIPrefabs/DebugConsole.prefab ``` into your scene hierarchy. 2. **Opening the Debug Console**\ While running the simulation, you can open the Debug Console by clicking in the **bottom-left corner** of the screen. 3. **Console Log Indicators** * If there are any console log entries, small **icons** and a **log count** will appear to notify you. * You can review **warnings, errors, and other logs** in real time. 4. **Executing Commands**\ The Debug Console also supports **custom commands**, allowing you to trigger specific functions or modify application settings directly. ## Console Commands To see a full list of available commands, type the following in the Debug Console's input field: ``` bashKopierenBearbeitenhelp ``` **Available Commands** | Command | Description | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **ConnectOff** | Disables Connect Mode. This setting is saved for the next start. | | **ConnectOn** | Enables Connect Mode. This setting is saved for the next start. | | **DebugOff** | Turns off Debug Mode. The player must be restarted for this change to take effect. *Please note: Not all components take care about Global Debug Mode.* | | **DebugOn** | Turns on Global Debug Mode in realvirtualController. The player must be restarted for this change to take effect. *Please note: Not all components take care about Global Debug Mode.* | | **DeletePrefs** | Deletes all PlayerPrefs (everything what is saved with [RuntimePersistence](/basics/runtime-ui/runtime-persistence) or saved manually via script). The model returns to the standard settings. | | **help** | Prints all available commands. | | **help \[commandName]** | Prints detailed information about the specified command. | | **InspectorOff** | Disables the Runtime Inspector. The player must be restarted for this change to take effect. | | **InspectorOn** | Enables the Runtime Inspector. The player must be restarted for this change to take effect. | For more information about implementing your own commands please check # Mouse Sensitivity Control 3D navigation sensitivity during runtime with persistent settings. {% hint style="info" %} **New in Version 6.0.3**: Mouse Sensitivity control is available in the Settings window during Play Mode. {% endhint %}
Mouse Sensitivity Settings Window

Settings window showing Mouse Sensitivity slider (0.1-3.0 range) during Play Mode

## Overview The Mouse Sensitivity feature allows users to adjust 3D navigation speed in real-time during Play Mode. Settings are automatically saved and restored across Unity sessions. ## Settings * **Range**: 0.1 (very slow) to 3.0 (very fast) * **Default**: 1.0 (normal sensitivity) * **Access**: Settings window during Play Mode * **Persistence**: Automatically saved using Unity PlayerPrefs ## Navigation Types Affected * Camera rotation and orbiting * Zoom controls (scroll wheel) * Panning operations * Touch navigation on mobile devices ## How to Use 1. Enter **Play Mode** in Unity 2. Open the **Settings** window from the runtime UI 3. Adjust the **Mouse Sensitivity** slider to your preference 4. Changes apply immediately 5. Settings persist automatically when exiting Play Mode ## Use Cases * **Accessibility**: Accommodate different user preferences * **Hardware Compatibility**: Adjust for different mouse types and DPI settings * **Training Environments**: Provide comfortable navigation for new users * **Demonstrations**: Quick sensitivity adjustment for different presentation scenarios # Responsiveness realvirtual.io is designed to run on a variety of devices, including **PCs, mobile devices, WebGL, and different screen resolutions**. Achieving a responsive and adaptive UI across these platforms can be challenging. To simplify this, **realvirtual.io includes special scaler scripts** to handle different screen sizes and resolutions automatically. You can adopt the settings based on your special application needs. ### **Scaler Scripts for Responsive UI** #### **Toolbar Scaler** The **Toolbar Scaler** ensures that toolbars scale properly depending on screen size and platform. * **Adjusts toolbar height and scale** dynamically. * **Handles scaling for different screen resolutions**, ensuring UI elements remain accessible. * **Platform-specific deactivation:** * Allows disabling elements for **Linux, Windows, and WebGL** when needed.

Toolbar Scaler

#### **Overlay Button Scaler** The **Overlay Button Scaler** is used for the ovlerlay buttons on the right hand side. * **Dynamically scales UI buttons based on screen size.** * **Custom width and height settings** for different screen resolutions. * **Supports platform-based UI adjustments** (e.g., different behaviors for **Android, iOS, WebGL**).

Oberlay Button Scaler

# Runtime Persistence Saving properties in the Build In some cases, it is necessary to allow changes to properties (e.g., **interface settings**) during runtime in a **built application**. **Runtime Persistence** enables automatic storage and retrieval of values to maintain settings across sessions. ## **Introduction** ### **How It Works** * **Persistent Storage**: All defined values are **loaded before `OnEnable` and `Awake`** methods are executed. * **Automatic Saving**: Values are **saved automatically** when the scene is closed, ensuring that changes persist. * **Uses PlayerPrefs**: The data is stored using Unity’s **PlayerPrefs** system, which varies based on the platform. ### **Where Data is Stored?** The **PlayerPrefs** storage location varies by platform: * **Windows**: Stored in the **Registry** under: ``` HKEY_CURRENT_USER\Software\[Company Name]\[Product Name] ``` * **MacOS**: Stored in a **.plist file** under: ``` ~/Library/Preferences/unity.[Company Name].[Product Name].plist ``` * **Linux**: Saved in the `~/.config/unity3d/` directory. For more details, refer to the **Unity PlayerPrefs documentation**. ## Saving Data via Runtime Persistence Component The **Runtime Persistence** component allows saving and restoring **component properties** in Unity **without custom programming**. It enables automatic persistence of values such as **interface settings, network configurations, and UI preferences** across sessions. Besides the persistence itself properties can be configured to be editable via the Options window during Runtime.

Options window with properties to be chanded during runtime

Runtime Persistence Component

### **How to Use the Runtime Persistence Component** 1. **Attach the Component** * Add the **Runtime Persistence** script to the GameObject containing the properties you want to save. 2. **Assign Properties to Save** * Under **Properties to Save**, click **+** to add a new property. * **Component**: Select the script containing the property. * **Name**: Enter the exact **property name** from the script. 3. **Enable Automatic UI Integration** * **Show in Options (`✔`)**: The property will be automatically added to the **realvirtual.io Options Window** for user configuration. 4. **Handling Events** * **OnValueChanged**: Triggered when the property is modified in the Options Window (after the user exits the field). * **OnOptionsWindowClosing**: Triggered when the Options Window is closed. * These events can be used to execute **custom logic** when values change. ## Example: Mouse Sensitivity Control One key feature using Runtime Persistence is **Mouse Sensitivity** control for 3D navigation. For detailed information, see the dedicated [Mouse Sensitivity](/basics/runtime-ui/mouse-sensitivity) page. ### **Example Use Case (Interface Configuration)** **Scenario:** Saving the IP address of a **Denso Interface** (`DensoCobotta1300`). * **Component:** `DensoCobotta1300 (Denso Interface)` * **Property Name:** `ipAdress` * **Show in Options:** `✔` (IP field will appear in the UI). * **OnValueChanged Event:** Calls`OnValueChangedReconnectInterface.OnValueChanged`, which **deactivates and reactivates the interface** if the IP changes. # Camera Control Control camera movement and focus during runtime to track moving objects, create cinematic views, or guide users through your digital twin. {% hint style="info" %} **New Feature**: CameraFollowObject component is available since realvirtual version 6.0.7. {% endhint %} ## Overview realvirtual provides comprehensive camera control capabilities for runtime navigation, object tracking, and preset camera positions. The system is designed for both **no-code Inspector configuration** and **scripting integration**, making it accessible to designers while remaining powerful for developers. > **📝 Note** This section covers **runtime camera control features** for following objects and loading preset positions. For standard scene navigation with mouse/keyboard during runtime (pan, rotate, zoom, first-person mode), see the main [Runtime UI](/basics/runtime-ui) documentation. ### Camera Control Options realvirtual offers three complementary approaches to camera control: **1. Camera Position Presets (CameraPosition Component)** ⭐ *Recommended for beginners* * Save and load complete camera views as reusable preset assets * Create camera navigation buttons without any coding * Automatic startup position loading * Keyboard shortcuts and touch gestures for quick access * Perfect for: multi-view dashboards, guided tours, preset navigation **2. Object Following and Focus (CameraFollowObject Component)** * Track moving objects continuously (follow mode) * One-time smooth transitions to view specific objects (focus mode) * Auto-calculated distance and angles or custom positioning * Optional user control (rotation/zoom) during following * Perfect for: AGV tracking, process monitoring, operator attention management **3. Direct Camera Control (SceneMouseNavigation API)** * Programmatic camera positioning from scripts * Advanced integration with automation logic * Custom camera sequences and animations * Perfect for: automated demonstrations, complex camera movements, custom UI ### Common Use Cases * **Camera Preset Navigation** - Quick access to predefined views via buttons, keyboard, or gestures * **AGV/Mobile Robot Tracking** - Follow autonomous vehicles as they navigate through facilities * **Process Visualization** - Focus on specific machines or operations during demonstrations * **Guided Tours** - Create automated camera sequences that highlight key areas * **Multi-View Dashboards** - Provide operators with instant access to different facility areas * **Operator Training** - Direct user attention to important components * **Remote Monitoring** - Track critical moving equipment in real-time Camera control integrates seamlessly with PLC signals, UI buttons, and scripting, making it suitable for both automated sequences and user-controlled interactions. *** ## Camera Position Presets - No-Code Approach The **CameraPosition** component system provides the simplest way to create camera navigation without any coding. It allows you to save complete camera views as reusable preset assets and trigger them via buttons, keyboard shortcuts, or touch gestures. ### How It Works The CameraPosition system consists of two parts: 1. **CameraPos ScriptableObject Assets** - Store camera state (position, rotation, distance, orthographic settings) 2. **CameraPosition Component** - Load and activate camera presets when triggered This separation allows you to create a library of camera views that can be reused across different buttons, keyboard shortcuts, and automation triggers.
CameraPosition Inspector showing configuration for camera preset views

Two CameraPosition components configured with different preset views and activation methods

### Creating Camera Position Presets Follow these steps to create and save a camera position preset: **In Edit Mode:** 1. **Create the ScriptableObject asset** * Right-click in Project window → **Create > realvirtual > Add Camera Position** * Name the asset descriptively (e.g., "MainOverview", "RobotStation1", "TopView") 2. **Attach CameraPosition component to Main Camera** * Select the **Main Camera** in Hierarchy (`/realvirtual/Main Camera`) * Click **Add Component** → Search for **CameraPosition** 3. **Assign the ScriptableObject asset** * In the CameraPosition component, assign your CameraPos asset to the **Campos** property **In Play Mode (Game Mode):** 4. **Start the simulation** * Press the **Play** button to enter Play mode 5. **Position your Game view camera** * Navigate the camera to your desired view using realvirtual runtime controls: * **Middle mouse button + drag** - Pan camera * **Right mouse button + drag** - Rotate camera around pivot point * **Mouse scroll wheel** - Zoom in/out 6. **Save the current position** * With the Main Camera still selected, find the CameraPosition component in Inspector * Click the **"Save current Position"** button * The CameraPos asset now stores the current Game view camera position > **⚠️ Important** Camera positions must be **saved in Play mode** when the Game view camera is active. The "Save current Position" button captures the runtime camera's current position and rotation. > **💡 Tip** Create multiple CameraPos assets for different areas or views in your digital twin. Build a library of presets like "Overview", "DetailView1", "DetailView2", "TopView", "SideView" for comprehensive navigation. ### Adding CameraPosition to Your Scene Camera position components are typically added to the **Main Camera** (`/realvirtual/Main Camera`) to manage different camera views. **Step 1: Add CameraPosition Component to Main Camera** 1. Select the **Main Camera** in your Hierarchy (`/realvirtual/Main Camera`) 2. Click **Add Component** in the Inspector 3. Search for and add **CameraPosition** 4. Assign your CameraPos asset to the **Campos** property 5. Configure activation settings (keyboard shortcut, activate on start, etc.) **Step 2: Add Multiple CameraPosition Components (Optional)** You can add multiple CameraPosition components to the Main Camera, each configured for a different view: 1. Add another **CameraPosition** component to the same Main Camera 2. Assign a different CameraPos asset (e.g., "TopView", "DetailView") 3. Set a different **Key Code** (e.g., F1 for first view, F2 for second view) 4. Repeat for additional preset views **Step 3: Connect to UI Buttons (Optional)** For button-based navigation: 1. Select your UI button GameObject 2. In the Button component's **OnClick** event list, click **+** 3. Drag the **Main Camera** GameObject to the object field 4. Select **CameraPosition > SetCameraPosition()** from the function dropdown 5. If you have multiple CameraPosition components on the Main Camera, select the specific one you want to trigger ### CameraPosition Properties #### Basic Configuration **Name** (string) - Display name for this camera position. Shows in runtime UI and can be used for identification. Default: "Main Camera" **Campos** (CameraPos asset) - The camera position preset asset to load. This ScriptableObject contains the saved camera state (position, rotation, distance, orthographic settings). Assign the CameraPos asset you created earlier. #### Activation Methods **View Name** (string) - Optional identifier for this view. Can be used for scripting lookups or display purposes. Example: "View1", "Overview", "DetailStation" **Key Code** (KeyCode) - Keyboard shortcut to activate this camera position. Press this key during runtime to instantly load the preset view. Examples: * **F1, F2, F3** - Function keys for quick view switching * **Alpha1, Alpha2** - Number keys for numbered views * **None** - Disable keyboard activation **Activate On Start** (boolean) - When enabled, this camera position automatically loads when Play mode starts or when the component is enabled. Use this for your default startup view. > **⚠️ Warning** Only enable **Activate On Start** on ONE CameraPosition component. Multiple components with this setting enabled will conflict. **Double Tap Gesture** (Touch Interaction) - Configure touch gesture activation for mobile or touchscreen interfaces: * **None** - Disable touch gesture activation * **Touch Interaction GameObject** - Assign the touch interaction component that manages gestures * When assigned and user performs double-tap gesture, this camera position activates This enables touchscreen users to quickly navigate between views using familiar double-tap gestures. ### Inspector Buttons The CameraPosition component provides two convenient buttons in the Inspector: * **Save current Position** - Captures the current Scene view camera state and updates the assigned CameraPos asset * **Set Camera to saved Position** - Loads the camera view from the assigned CameraPos asset These buttons work in both Edit mode and Play mode, allowing you to test and refine camera positions during development. > **💡 Workflow Tip** Use "Save current Position" to quickly update presets as you refine your views. Navigate to the desired position in Scene view, then click the button to update the asset without leaving the Inspector. ### Common Setup Patterns **Pattern 1: UI Button Navigation (No Coding)** Create a navigation panel with buttons for different views: 1. Create 3-5 CameraPos assets for different areas (Overview, Station1, Station2, etc.) 2. Select **Main Camera** and add 3-5 CameraPosition components (one for each view) 3. Assign different CameraPos assets to each CameraPosition component 4. Add UI buttons to your Canvas 5. Connect each button's OnClick event to **Main Camera > CameraPosition > SetCameraPosition()** 6. Select the specific CameraPosition component for each button Result: Users click buttons to instantly navigate between predefined views. **Pattern 2: Keyboard Shortcuts** Provide power users with keyboard shortcuts: 1. Select the **Main Camera** in Hierarchy 2. Add multiple CameraPosition components to the Main Camera 3. Assign different CameraPos assets to each component 4. Set different KeyCodes (F1, F2, F3, etc.) for each CameraPosition 5. Set Active to "PlayModeOnly" on all components Result: Press F1-F5 to instantly switch between 5 preset views. **Pattern 3: Automatic Startup View** Set a default camera position when the scene starts: 1. Select your Main Camera in Hierarchy 2. On the **SceneMouseNavigation** component, configure camera position settings: * **Last Camera Position** - Assign your default startup view CameraPos asset * **Set Camera Pos On Start Play** - Enable to load this position at startup * **Save Camera Pos On Quit** - Enable to save current camera state when exiting Play mode * **Set Editor Camera Pos** - Enable to sync Scene view with saved position * **Interpolate To New Camerapoitions** - Enable for smooth camera transitions
SceneMouseNavigation camera position settings

SceneMouseNavigation component on Main Camera showing camera position startup settings

> **⚠️ Important: Save Camera Pos On Quit** Enable **Save Camera Pos On Quit** temporarily when you want to capture your final camera position. Once you've set your permanent startup position, **disable this setting** to prevent it from overwriting your preset every time you exit Play mode. Leave it enabled only if you want the camera position to dynamically update between sessions. Result: Scene always starts from the same professional overview position. **Pattern 4: Combined Approach** Combine all methods for maximum flexibility: 1. Configure startup position on SceneMouseNavigation (Pattern 3) 2. Add UI buttons for common views (Pattern 1) 3. Add keyboard shortcuts for power users (Pattern 2) 4. Optional: Add double-tap gestures for mobile (configure Touch Interaction) Result: Complete navigation system supporting multiple user preferences and devices. > **⚠️ Important: Avoiding Conflicts Between Camera Systems** > > When combining multiple camera control approaches (CameraPosition, CameraFollowObject, and SceneMouseNavigation settings), be careful to avoid conflicts: > > * **Only ONE "Activate On Start"**: Enable "Activate On Start" on only ONE CameraPosition component. Multiple components with this enabled will conflict. > * **Don't set positions in parallel**: Avoid triggering multiple camera position changes at the same time (e.g., starting follow mode while a camera position is animating). > * **SceneMouseNavigation vs CameraPosition startup**: If using CameraPosition with "Activate On Start", disable "Set Camera Pos On Start Play" on SceneMouseNavigation to avoid both systems trying to set the startup position. > * **Following mode takes priority**: When CameraFollowObject is actively following an object, camera position changes are blocked until following stops. > * **Sequential transitions**: If you need to combine different camera movements (e.g., load position, then start following), use scripting or Events to trigger them sequentially with proper delays. ### Camera Position vs CameraFollowObject **Use CameraPosition when:** * You want predefined static camera views * Creating navigation between fixed viewpoints (e.g., different areas of a factory) * Setting up startup camera position * Building multi-view dashboards * No coding required **Use CameraFollowObject when:** * You need to track moving objects (AGVs, robots, conveyors) * Creating dynamic camera that follows motion * Focusing attention on specific components during demonstrations * Combining following with user control (rotation/zoom during tracking) Both systems can be used together in the same scene for comprehensive camera control. *** ## CameraFollowObject Component The **CameraFollowObject** component controls camera behavior for both continuous following and one-time focus operations. Unlike CameraPosition which loads static preset views, CameraFollowObject creates dynamic camera behavior that tracks moving objects in real-time or smoothly transitions to focus on specific components.
CameraFollowObject Inspector with follow settings

CameraFollowObject component configured to follow a robot TCP with rotation and zoom control enabled

### Adding CameraFollowObject 1. Add the component to any GameObject in your scene (commonly attached to UI buttons) 2. Assign the **Object To Follow** property to your target GameObject 3. Configure distance and angle settings as needed 4. Connect to buttons or PLC signals for triggering ### Properties #### Target Object **Object To Follow** (GameObject) - The GameObject to track or focus on. This can be any object in your scene including MUs, robots, conveyors, or machine components. The camera will automatically calculate the object's bounding box center from all child renderers. #### Camera Distance **Use Custom Distance** (boolean) - Controls whether to use a manually specified distance or auto-calculate the optimal viewing distance. When disabled, the camera automatically calculates the distance needed to fit the object at approximately 1/3 of screen space, providing a comfortable viewing size that shows the object clearly without filling the entire frame. **Distance** (float, meters) - Camera distance from the object center when Use Custom Distance is enabled. Adjust this value to control how close or far the camera appears from the target. Typical values range from 2 meters for small objects to 20 meters for large equipment. #### Camera Angle **Use Custom View Angle** (boolean) - Controls whether to use a manually specified camera rotation or auto-select the optimal angle. When disabled for FocusOnObject, the camera calculates an optimal viewpoint slightly above and to the side of the object. When disabled for StartFollowing, the current camera angle is maintained. **View Angle** (Vector3, degrees) - Camera rotation in Euler angles (X, Y, Z) when Use Custom View Angle is enabled. Use this to set precise camera orientations such as top view (90, 0, 0) or side view (0, 90, 0). #### User Control Options **Allow Rotation** (boolean) - When enabled during following mode, users can orbit the camera around the object using mouse or touch input while the object remains centered. This is useful for inspection scenarios where operators need to examine moving equipment from different angles. **Allow Zoom** (boolean) - When enabled during following mode, users can adjust the camera distance from the object using scroll wheel or pinch gestures while maintaining focus on the target. Combine with Allow Rotation for full user control during tracking. #### Smoothness **Lerp Speed** (float, 0.1-10.0) - Controls camera tracking smoothness during following mode. Lower values (0.1-0.5) create smooth cinematic motion, medium values (0.5-2.0) provide balanced tracking, and higher values (2.0-10.0) create tight, responsive tracking. Default: 1.0 **Smooth Start** (boolean) - When enabled, the camera smoothly transitions to the object when starting to follow. When disabled, the camera jumps immediately to the following position. Enable for professional presentations, disable for instant response in monitoring scenarios. #### Stop Button UI **Show Stop Button** (boolean) - When enabled, displays a UI button during camera follow mode that allows users to stop the camera tracking. The button appears automatically when following starts and disappears when following stops. This provides users with a clear, visible way to exit follow mode without requiring keyboard shortcuts or external buttons.
Stop Camera Focus button appears during following mode

The "Stop Camera Focus" button automatically appears during camera follow mode when Show Stop Button is enabled

**Stop Button Prefab** (GameObject) - Optional custom prefab for the stop button UI. If null, uses the default rvUICameraFocusButton prefab from Resources. Assign a custom prefab here if you want to customize the button's appearance, position, or text. The custom prefab must have an rvUICameraFocusButton component. **Stop On Mouse Click** (boolean) - When enabled, following stops automatically if the user clicks any mouse button. This provides an alternative way to exit follow mode by simply clicking anywhere in the viewport. #### Follow Mode **Auto Start Following** (boolean) - Automatically begins following the target object when the scene starts or when the component is enabled. Enable this for scenarios where tracking should start immediately, such as startup demonstrations or monitoring views. #### PLC Signal Control **PLC Signal Start Following** (PLCInputBool) - PLC signal that controls following mode. When the signal transitions to true, following begins. When the signal returns to false, following stops automatically. Use this for automated sequences controlled by your PLC logic. **Follow Active** (boolean) - Public boolean property that can be controlled externally by scripts or PLCOutputBool components. Set to true to start following, false to stop. This provides an alternative to PLC signals for scripting scenarios or UI toggle buttons. > **💡 Hint**\ > PLC signal monitoring uses FixedUpdate timing to ensure synchronization with PLC communication cycles. Either the PLC signal or Follow Active bool can trigger following - both do not need to be true simultaneously. ### Control Methods The CameraFollowObject component provides three main methods that can be triggered from UI buttons, scripts, or other events: #### StartFollowing() Begins continuous camera tracking of the target object. The camera will smoothly move to the configured viewing position and then continuously update its position to keep the object centered as it moves. Following continues until explicitly stopped by calling StopFollowing() or by setting control signals to false. **Use Cases:** * Track AGVs moving through warehouses * Follow robotic arms during operation sequences * Monitor conveyor transport of critical products * Automated camera sequences in demonstrations **Button Setup:** Add a button to your UI and connect its OnClick event to CameraFollowObject.StartFollowing(). For toggle behavior, use ToggleFollowing() instead. #### StopFollowing() Ends continuous camera tracking and returns the camera to normal user-controlled navigation mode. The camera remains at its current position and rotation, allowing users to navigate freely. **Use Cases:** * End automated tracking sequences * Return control to operators * Switch between tracked objects #### FocusOnObject() Performs a one-time smooth camera movement to view the target object without continuous tracking. The camera will interpolate to the optimal viewing position, but will not continue following if the object moves afterward. This is ideal for guided tours or drawing attention to specific components. **Use Cases:** * Highlight specific machines during presentations * Create waypoint-based guided tours * Quick navigation to specific areas * Operator attention management in training scenarios #### ToggleFollowing() Switches between following and not following states. If currently following, this method stops tracking. If not following, it starts tracking. Useful for toggle buttons in your UI. ### Inspector Buttons The component provides three buttons directly in the Inspector for testing during development: * **Start Following** - Test continuous tracking * **Stop Following** - End tracking * **Focus On Object** - Test one-time focus These buttons work in both Edit mode and Play mode, allowing you to preview camera behavior during scene setup. ### Distance and Angle Auto-Calculation When custom distance or angle options are disabled, the camera uses intelligent auto-calculation: **Auto Distance Calculation:** * Analyzes all renderers on the target object and its children * Calculates combined bounding box dimensions * Determines distance to fit object at 1/3 screen space * Adds safety margin based on object size * Ensures object is clearly visible without being too close or far **Auto Angle Calculation:** * **FocusOnObject**: Calculates optimal viewpoint slightly elevated and offset from object center for best visibility * **StartFollowing**: Maintains current camera angle to avoid disorienting users during tracking > **💡 Hint**\ > Auto-calculation works best with objects that have MeshRenderer or SkinnedMeshRenderer components. For objects without renderers, the camera uses the object's transform position and a default distance of 5 meters. *** ## Setting Camera Positions via Code For advanced scenarios, you can control camera positions programmatically using the **SceneMouseNavigation** public API. This is useful for creating custom camera sequences, automation logic, or dynamic camera movements based on simulation events. ### Accessing SceneMouseNavigation The SceneMouseNavigation component is located on the Main Camera. There are several ways to get a reference to it: **Method 1: FindObjectOfType (Recommended - Simple and Reliable)** ```csharp using realvirtual; // Find the SceneMouseNavigation component in the scene SceneMouseNavigation sceneNav = FindObjectOfType(); ``` **Method 2: Via Main Camera GameObject** ```csharp using realvirtual; // Get reference via specific GameObject path GameObject mainCamera = GameObject.Find("/realvirtual/Main Camera"); SceneMouseNavigation sceneNav = mainCamera.GetComponent(); ``` **Method 3: Using Camera.main** ```csharp using realvirtual; // Get reference via Unity's main camera SceneMouseNavigation sceneNav = Camera.main.GetComponent(); ``` > **💡 Tip** Use `FindObjectOfType()` for the simplest and most reliable approach. It works regardless of the camera's exact hierarchy path. ### SetNewCameraPosition Method The primary method for programmatic camera control: ```csharp public void SetNewCameraPosition(Vector3 targetPos, float camDistance, Vector3 camRotation, bool noInterpolate = false) ``` **Parameters:** * **targetPos** (Vector3) - The world position the camera looks at (orbit center point) * **camDistance** (float) - Distance from target to camera in meters * **camRotation** (Vector3) - Camera rotation as Euler angles (X, Y, Z) in degrees * **noInterpolate** (bool) - If true, jump immediately; if false, smoothly interpolate to position (default: false) **Example - Move Camera to Specific Position:** ```csharp using UnityEngine; using realvirtual; public class CameraController : MonoBehaviour { private SceneMouseNavigation sceneNav; void Start() { // Get SceneMouseNavigation reference sceneNav = FindObjectOfType(); } public void MoveCameraToStation1() { // Define target position, distance, and rotation Vector3 targetPosition = new Vector3(10f, 0f, 5f); // Look at point float distance = 8f; // 8 meters from target Vector3 rotation = new Vector3(30f, 45f, 0f); // Camera angle // Move camera with smooth interpolation sceneNav.SetNewCameraPosition(targetPosition, distance, rotation, noInterpolate: false); } public void JumpCameraToOverview() { // Jump instantly without interpolation Vector3 targetPosition = new Vector3(0f, 0f, 0f); float distance = 15f; Vector3 rotation = new Vector3(45f, 90f, 0f); sceneNav.SetNewCameraPosition(targetPosition, distance, rotation, noInterpolate: true); } } ``` **Example - Camera Sequence with Coroutines:** ```csharp using System.Collections; using UnityEngine; using realvirtual; public class CameraTour : MonoBehaviour { private SceneMouseNavigation sceneNav; void Start() { GameObject mainCamera = GameObject.Find("/realvirtual/Main Camera"); sceneNav = mainCamera.GetComponent(); } public void StartTour() { StartCoroutine(CameraTourSequence()); } IEnumerator CameraTourSequence() { // Position 1: Overview sceneNav.SetNewCameraPosition(new Vector3(0, 0, 0), 20f, new Vector3(45, 0, 0)); yield return new WaitForSeconds(3f); // Position 2: Station A sceneNav.SetNewCameraPosition(new Vector3(10, 0, 5), 8f, new Vector3(30, 45, 0)); yield return new WaitForSeconds(3f); // Position 3: Station B sceneNav.SetNewCameraPosition(new Vector3(-10, 0, -5), 8f, new Vector3(30, -45, 0)); yield return new WaitForSeconds(3f); } } ``` ### Using with CameraPos Assets You can also load CameraPos assets programmatically: ```csharp using UnityEngine; using realvirtual; public class LoadCameraPreset : MonoBehaviour { public CameraPos overviewPosition; // Assign in Inspector private SceneMouseNavigation sceneNav; void Start() { GameObject mainCamera = GameObject.Find("/realvirtual/Main Camera"); sceneNav = mainCamera.GetComponent(); } public void LoadPreset() { if (overviewPosition != null) { sceneNav.SetNewCameraPosition( overviewPosition.TargetPosition, overviewPosition.Distance, overviewPosition.Rotation, noInterpolate: false ); } } } ``` ### Interpolation Control Control smooth camera transitions using the SceneMouseNavigation properties: * **InterpolateToNewCamerapoitions** (bool) - Enable/disable smooth interpolation * **CameraInterpolationSpeed** (float) - Speed of camera transitions (default: 0.1) ```csharp // Disable interpolation for instant jumps sceneNav.InterpolateToNewCamerapoitions = false; sceneNav.SetNewCameraPosition(targetPos, distance, rotation); // Re-enable with custom speed sceneNav.InterpolateToNewCamerapoitions = true; sceneNav.CameraInterpolationSpeed = 0.05f; // Slower transitions sceneNav.SetNewCameraPosition(targetPos, distance, rotation); ``` ### Following Objects Programmatically For continuous object tracking via code, use the **StartFollowing** method in SceneMouseNavigation: ```csharp public void StartFollowing(GameObject targetObject, float? distance = null, Vector3? viewAngle = null, bool allowRotation = false, bool allowZoom = false, float lerpSpeed = 1.0f, bool smoothStart = true, bool stopOnMouseClick = false) ``` **Parameters:** * **targetObject** (GameObject) - The object to follow * **distance** (float?, optional) - Camera distance in meters. If null, auto-calculates based on object bounds * **viewAngle** (Vector3?, optional) - Camera rotation in Euler angles. If null, uses current angle (StartFollowing) or optimal angle (FocusOnObject) * **allowRotation** (bool) - If true, user can orbit camera while following * **allowZoom** (bool) - If true, user can zoom in/out while following * **lerpSpeed** (float) - Smoothness factor (0.1 = cinematic, 10.0 = instant) * **smoothStart** (bool) - If true, smoothly transitions to object. If false, jumps immediately * **stopOnMouseClick** (bool) - If true, stops following when user clicks any mouse button **Example - Follow Moving AGV:** ```csharp using UnityEngine; using realvirtual; public class AGVTracker : MonoBehaviour { public GameObject agv; private SceneMouseNavigation sceneNav; void Start() { sceneNav = FindObjectOfType(); } public void StartTrackingAGV() { // Follow AGV with auto-calculated distance, allowing user rotation and zoom sceneNav.StartFollowing( targetObject: agv, distance: null, // Auto-calculate optimal distance viewAngle: null, // Maintain current camera angle allowRotation: true, // User can orbit around AGV allowZoom: true, // User can zoom in/out lerpSpeed: 0.3f, // Smooth cinematic tracking smoothStart: true, // Smooth transition to AGV stopOnMouseClick: false // Continue following even if user clicks ); } public void StopTracking() { sceneNav.StopFollowing(); } } ``` **Example - Focus on Machine with Custom Settings:** ```csharp public void FocusMachineOnError(GameObject machine) { SceneMouseNavigation sceneNav = FindObjectOfType(); // Focus on machine with specific distance and angle sceneNav.FocusOnObject( machine, distance: 8f, // 8 meters from machine viewAngle: new Vector3(30, 45, 0) // View from 30° up, 45° around ); } ``` > **💡 Tip** For button-triggered following, use the **CameraFollowObject** component which provides Inspector configuration without coding. For dynamic code-based tracking (e.g., follow different objects based on events), use SceneMouseNavigation.StartFollowing() directly. *** © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Importing and exporting Assets and models importing and exporing {% hint style="info" %} This page covers **realvirtual-specific** import and export features. Unity itself supports a wide range of standard file formats including FBX, OBJ, 3DS, DXF, and many more. For information about Unity's general import and export capabilities, please refer to the [Unity Documentation on Importing Assets](https://docs.unity3d.com/Manual/ImportingAssets.html). {% endhint %} ## Overview realvirtual provides specialized import and export workflows for industrial automation applications: **Importing:** * [**CAD Files**](#cad-import) - STEP, IGES, JT formats via Unity Pixyz or realvirtual CADLink * [**GLB Assets**](#importing-glb-assets) - Industry-standard 3D format with full metadata preservation (Professional) **Exporting:** * [**GLB Assets**](#exporting-glb-assets-beta) - Export models with realvirtual components and properties preserved (Professional, Beta) * [**Unity Packages**](#exporting-unity-packages) - Export projects, scenes, or selected assets with all dependencies All realvirtual-specific properties (drives, sensors, IK configurations) are fully preserved when exporting and importing GLB files in Professional version. ## Importing Assets ### CAD Import For importing CAD files (STEP, IGES, JT, etc.) into Unity, realvirtual supports two primary methods: {% hint style="info" %} For detailed information about CAD import workflows, see the [CAD Import](https://github.com/game4automation/doc/blob/doc/basics/cad-import.md) documentation. {% endhint %} **Unity Pixyz Plugin** (Recommended) Unity Industry includes the Pixyz Plugin, which provides native CAD import capabilities directly within Unity. Pixyz supports a wide range of CAD formats and offers advanced features like tessellation control, hierarchy preservation, and optimization tools. **realvirtual CADLink** The realvirtual CADLink feature provides automated CAD import workflows with additional automation-specific optimizations for virtual commissioning scenarios. ### Importing GLB Assets **Prerequisites** For GLB import functionality, the UnityGLTF package is required. To install it: 1. Open Unity's Package Manager (Window → Package Manager) 2. Click the **+** button in the top-left corner 3. Select **Add package from git URL** 4. Enter: `https://github.com/KhronosGroup/UnityGLTF.git` 5. Click **Add** **How to Import:** Unity automatically imports GLB files placed in the Assets folder. The imported GLB files appear as prefabs in the Project window and can be used like any other Unity prefab. 1. Place the GLB file in your Assets folder (Unity will automatically import it) 2. The GLB file will appear as a prefab in the Project window 3. Drag and drop the prefab into your scene like a normal Unity prefab {% hint style="info" %} In realvirtual.io Professional, all realvirtual-specific properties (drives, sensors, IK configurations) are fully preserved when importing GLB files that were exported from realvirtual. {% endhint %} ## Exporting Assets ### Export Menu Overview The realvirtual.io menu includes several functions for exporting assets located under **realvirtual → Export**:

realvirtual Export Menu

* **Export realvirtual GLB Asset** - Export selected GameObject as GLB file with realvirtual metadata (Beta) * **Full project as package** - Export entire project as Unity package * **Current scene as package** - Export active scene with dependencies as Unity package * **Selected as package** - Export selected asset with dependencies as Unity package * **Full project as ZIP** - Export entire project as ZIP file ### Exporting Unity Packages For Unity packages, all references are automatically included in the export. To import exported packages, drag them into another project or select *Assets → Import Package* in the Unity Menu. ### Exporting GLB Assets (Beta) **Prerequisites** For GLB export and import functionality, the UnityGLTF package is required. To install it: 1. Open Unity's Package Manager (Window → Package Manager) 2. Click the **+** button in the top-left corner 3. Select **Add package from git URL** 4. Enter: `https://github.com/KhronosGroup/UnityGLTF.git` 5. Click **Add** **About glTF and GLB** **glTF** (GL Transmission Format) is an open-standard 3D file format developed by the Khronos Group (the same organization behind OpenGL and Vulkan). It is designed as an efficient, interoperable format for transmitting and loading 3D content across applications, often referred to as the "JPEG of 3D" due to its widespread adoption and efficiency. **GLB** is the binary variant of glTF that packages all assets (geometry, textures, materials, animations) into a single binary file, making it easier to share and distribute 3D content. **Key characteristics:** * **Industry Standard**: Widely supported across 3D applications, web browsers, game engines, and AR/VR platforms * **Compact and Efficient**: Optimized for fast transmission and loading * **Complete Asset Storage**: Includes geometry, materials, textures, animations, and scene hierarchy in one file * **Extensible**: Supports custom extensions for application-specific data **Common Use Cases:** * Web-based 3D viewers and configurators * AR/VR applications and experiences * Asset exchange between different 3D software tools * 3D model libraries and marketplaces * Digital twin visualization in external applications **realvirtual GLB Export** realvirtual extends the standard GLB format by serializing automation-specific properties (drives, sensors, inverse kinematics configurations, etc.) into the GLB file. This allows you to export complete automation assets that can be: * Viewed in any standard glTF/GLB viewer (geometry and materials) * Re-imported into realvirtual.io Professional with full functionality preserved {% hint style="warning" %} **Important**: Full functionality of exported GLB files (including realvirtual-specific properties) is only preserved when importing back into realvirtual.io Professional. {% endhint %} **How to Export:** 1. Select the GameObject you want to export in the Hierarchy 2. Go to **realvirtual → Export → Export realvirtual GLB Asset** 3. A dialog will appear showing the default export path 4. Click **OK** to export to the default location, or **Browse** to choose a different folder 5. The export supports both internal (Assets/) and external folders {% hint style="info" %} GLB export is a beta feature available in realvirtual.io Professional version 6.0.7 and above. {% endhint %} **Viewing GLB Files** To preview and inspect exported GLB files, you can use free online viewers such as the [Babylon.js Sandbox](https://sandbox.babylonjs.com/). Simply drag and drop your GLB file into the browser window to view the 3D model with its geometry, materials, and textures. ### Exporting as ZIP File #### Manual ZIP Export To share or save the entire project, you can save the entire project folder as a ZIP file. The advantage is that in this case everything, including all settings, will be saved and you can be sure that the recipient will receive exactly the same project. You can do this manually with your prefered ZIP file tool. Before creating the ZIP file, it is best to delete the *Library* folder, this will significantly reduce the size and no information will be lost. The *Library* folder will be created automatically if it is missing. #### Automated ZIP Export You find within the realvirtual.io main menu (`realvirtual → Export → Full project as ZIP`) a fully automated solution for exporting the project as a ZIP file without the `Library` and `Temp` folders. {% hint style="warning" %} With very large projects the integrated ZIP export function might fail and crash Unity because the full operation is handled within the main memory. If it fails please use the manual method outside the Unity editor with a ZIP file of your choice. {% endhint %} ### Publishing Applications {% hint style="info" %} To export your project as a fully running application (executable), see [Publishing the Digital Twin](/basics/publishing-the-digital-twin) documentation. This allows you to build standalone applications for Windows, Mac, Linux, WebGL, and other platforms. {% endhint %} © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Folder structure Package and folder structure of realvirtual {% hint style="info" %} Starting with version **6.3**, realvirtual is distributed as **UPM (Unity Package Manager) packages**. The folder structure changed significantly from the previous `Assets/realvirtual/` layout used in 6.0 and earlier. {% endhint %} ## Package Overview

realvirtual UPM package structure

realvirtual is split into two UPM packages: | Package | Location | Description | | ------------------------------- | --------------------------------------- | --------------------------------------------------------------------- | | **io.realvirtual.starter** | `Packages/io.realvirtual.starter/` | Core framework — drives, sensors, signals, transport, gripping, logic | | **io.realvirtual.professional** | `Packages/io.realvirtual.professional/` | Professional add-on — IK, CADLink, interfaces, multiplayer, and more | {% hint style="warning" %} UPM packages are **read-only** in Unity. You cannot edit files inside `Packages/`. Place your own scenes, scripts, and assets in the `Assets/` folder. {% endhint %} ## Starter Package Layout The Starter package (`Packages/io.realvirtual.starter/`) contains: | Folder | Description | | ----------------------- | ------------------------------------------------------------------------------------------------------------- | | **Assets/** | User-facing assets you drag into scenes | | Assets/3DPrefabs/ | Industrial 3D models (conveyors, robots, boxes, fences) | | Assets/Materials/ | Industrial materials (plastics, metals, lamp indicators) | | Assets/Prefabs/ | Core functional prefabs (realvirtual.prefab, signal prefabs, interfaces) | | Assets/UIPrefabs/ | Runtime UI overlay prefabs | | Assets/Settings/ | Editor gizmo options, camera presets | | Assets/RenderPipelines/ | URP pipeline configuration and settings | | **Runtime/** | All runtime C# scripts (components, behaviors, interfaces) | | **Editor/** | Editor tools, inspectors, and toolbar | | **Samples\~/** | Demo scenes — import via [Demo Scenes Browser](/basics/user-interface/demo-scenes-browser) or Package Manager | ## Professional Package Layout The Professional package (`Packages/io.realvirtual.professional/`) contains: | Folder | Description | | ------------------------ | -------------------------------------------------------------------------------------------------- | | **Runtime/** | Pro features organized by domain | | Runtime/IK/ | [Robot Inverse Kinematics](/components-and-scripts/robot-inverse-kinematics) + robot prefabs | | Runtime/Interfaces/ | All Pro [interfaces](/components-and-scripts/interfaces) (OPC-UA, TwinCAT, KUKA, UR, Modbus, etc.) | | Runtime/CADLink/ | [CAD file import](/basics/cad-import) | | Runtime/PathTracer/ | Motion trail visualization | | Runtime/Statistics/ | Simulation statistics | | Runtime/Multiplayer/ | Multi-user networking | | Runtime/HighlightSystem/ | Object highlighting and selection | | Runtime/DistanceSystem/ | Distance measurement and connectable objects | | **Editor/** | Pro editor tools | | **Samples\~/** | Pro demo scenes (PLC Interfaces, Robotics, Robot Interfaces, Advanced Features) | ## Key Asset Locations When setting up scenes, you will frequently need these assets: | What you need | Where to find it | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Main framework prefab | `Packages/io.realvirtual.starter/Assets/Prefabs/realvirtual.prefab` | | Industrial 3D prefabs | `Packages/io.realvirtual.starter/Assets/3DPrefabs/` | | Materials library | `Packages/io.realvirtual.starter/Assets/Materials/` | | PLC signal prefabs | `Packages/io.realvirtual.starter/Assets/Prefabs/` | | Interface prefabs (Pro) | `Packages/io.realvirtual.professional/Runtime/Interfaces//` | | Robot prefabs (Pro) | `Packages/io.realvirtual.professional/Runtime/IK/` | | Demo scenes | Import via [Demo Scenes Browser](/basics/user-interface/demo-scenes-browser) or **Window > Package Manager > Samples** | ## Your Project Content Place all your project files in `Assets/`: * **Scenes** — your simulation scenes * **Scripts** — custom C# scripts and behaviors * **Prefabs** — your own reusable prefabs * **Materials** — custom materials * **Imported CAD data** — files imported via CADLink ## Previous Folder Structure (6.0 and earlier) {% hint style="info" %} In versions before 6.3, realvirtual was distributed as a `.unitypackage` installed into `Assets/realvirtual/`. This folder no longer exists in UPM-based installations. See the [Upgrade Guide](/advanced-topics/upgrade-guide) for migration instructions. {% endhint %} # Tutorial Create a first Digital Twin with a conveyor, a source and a sensor {% embed url="" %} Build your first digital twin: a conveyor that moves parts (realvirtual Know-How) {% endembed %} In this short tutorial we are creating a small Digital Twin model with a source, a conveyor and a light barrier. The needed 3D components are already available. If you would like to use own 3D data, you would need to import the 3D data from your CAD system using [CADLink](/basics/cad-import/cadlink) (included in realvirtual.io) or another suitable solution like for example [Unitys PIXYZ](https://unity.com/de/products/pixyz). ### Create a new scene You should always create your models outside the *realvirtual* folder. This is because if you import a new Version of realvirtual.io, you would not like to destroy what you did. If you keep your scripts outside the realvirtual.io folder this will enable you to update your model with new releases of realvirtual.io without problems. First create a new folder. We will call this folder *Tutorial*. Select assets and right click *Create > Folder*. Select the folder, hit F2 and name it to *Tutorial*.

Create a new Tutorial folder

For creating a new scene, select *Tools > realvirtual > Create new realvirtual scene*

Create a new scene

After the scene is created, please save it with *File > SaveAs* in your Tutorial folder with the name *tutorialmodel*:

Saved new scene in the Tutorial folder

You should now have an empty scene with a base plate and some lights:

Empty scene

{% hint style="info" %} You can hide the big lights and camera gizmos by setting the Gizmo size to 0 (see above picture). {% endhint %} You could also create a totally empty standard Unity scene and add the realvirutal component(before 2022 game4automation component) by *Tools > realvirtual > Add Object > realvirtual* in the Main menu. {% hint style="info" %} The realvirtual component provides some basic lights, mouse navigation in the deployed Digital Twin (Game view) as well as all standard settings and the standard [Runtime UI](/basics/runtime-ui). {% endhint %} ### Starting your first scene You can now start your first scene by pressing on Play in the top of the Unity UI. Game view will automatically open and you can see the RuntimeUI as well as an empty model with just the base plate:

Playing the empty model

### Insert the conveyor Next we insert a 3D component. For the tutorial we use a prepared one, which is already used by the demo model. Select the conveyor under *Assets > realvirtual> 3DPfefabs > ConveyorSmall* and drag it into the scene. Place it somewhere in the middle of the base plate. You can move the conveyor with the gizmo, which is visible as long as the conveyor is selected. Or you put in 0,0,0 into the Transform Position property. This will place the zero point of the conveyor onto the world zero point (which should be also the middle of the base plate):

Placed conveyor into the empty scene

### Unpacking the Prefab The conveyor belt that you have inserted into the scene is what is called a *prefab*. A *prefab* is a type of template and can be a very simple or a very complex component. A *Prefab* can be used multiple times in one or more scenes. As long as the embedded instances of the prefabs are not "unpacked" in the scene, they are still associated with the *Prefab* and inherit any changes to the prefab itself. For more information on the Unity Prefab System, see the Unity documentation here: . For the Tutorial, we should Unpack the *Prefab* instance completely and cut all dependencies to the original *Prefab*. Please select *ConveyorSmall* in the scene and with the context menu select *Prefab > Unpack Completely:*

Unpacking a prefab

### Delete realvirtual.io components from conveyor {% hint style="success" %} This step is optional. The conveyor prefab is already equipped with some realvirtual.io components. But we would like to show you in this tutorial the full workflow. Like it would be without anything prepared - based on imported 3D objects. This is why we are deleting the components and add them later on again. You could also skip this step if wished and continue with Insert a source. {% endhint %} Remove the component *Drive* on the object *ConveyorSmall* and also remove afterwards the *Rigidboy* on the object *ConveyorSmall*:

Remove the component Drive

\ Next delete *Transport Surface*, *Box Collider* and *Rigidboy* on *ConveyorSmall.Conveyor.Conveyor.* \ You learned how to remove scripts from objects ;-). **You now removed everything what is prepared and we will add these needed scripts again in this tutorial.** ### Define the transport surface {% hint style="success" %} We now have an empty 3D component. No kinematic and physical behavior is defined yet. This is what a component would look like after the CAD import. CAD systems do not contain any information other than the structure and geometry. This means that we have to define all mechatronic behaviors like drives and sensors in realvirtual.io. Unfortunately, until now there is no standard format for exporting extended information from the CAD system. However, our [Open Digital Twin Interface](/advanced-topics/page-5) allows you to develop your own exporter for the CAD system.t. {% endhint %} First we need to add a *Transport Surface* to the conveyor. For doing that we select the component *ConveyorSmall.Conveyor.Conveyor*. We select in the main menu *Tools > realvirtual > Add Script > Transport Surface* or we drag and drop the script *TransportSurface* under *Assets>realvirtual* onto *ConveyorSmall.Conveyor.Conveyor*. A very easy way is, to use the [QuickEdit](/basics/user-interface#quickedit) for adding the [*TransportSurface*](/components-and-scripts/motion/transportsurface)*:*

Adding a TransportSurface to the conveyor with QuickEdit

{% hint style="info" %} The Quick Edit overly buttons can be opened by pushing **F1** inside the scene view. {% endhint %} ### Insert a Drive We now insert a [Drive ](/components-and-scripts/motion/drive)on the Conveyor. We place it on the same component as the [*TransportSurface* ](/components-and-scripts/motion/transportsurface)before. Select the *ConveyorSmall.Conveyor.Conveyor* component in your Scene and select in the main menu *Tools > realvirtual > Add Script > Drive* : Alternatively you can also drag and drop the *Drive* Script under *Assets > realvirtual> Drive* onto the Inspector window of *ConveyorSmall.Conveyor.Conveyor*. Or as before you can also use the QuickEdit Overlay Window. And as a 3rd option you could also use *Add Component* on the Inspector window and than type in [*Drive* ](/components-and-scripts/motion/drive)and select the filtered script to assign it to the 3D component. Your model should now look like this:

Added Drive and TransportSurface to the conveyor

{% hint style="info" %} Please remember. Most times you can add scripts on 3D components in 4 ways * With the main menu * By dragging and dropping it from the Assets folder *Assets>game4automation* * by using *Add Component* in the *Inspector window* * *or by using the QuickEdit overlay* {% endhint %} ### Defining the transport direction and turning the Drive on Next we define some properties of the [Drive ](/components-and-scripts/motion/drive)within the Inspector window. Please also check if the Direction is set to *Linear X* (so that the shown transport direction is forward). Please check, that the [*TransportSurface* ](/components-and-scripts/motion/transportsurface)is assigned to the [Drive](/components-and-scripts/motion/drive), which usually is done automatically. Set ***JogForward*** to ***True*** and ***TargetSpeed*** to ***300***.

Changing the inspector properties of the Drive

This settings will automatically start the [Drive ](/components-and-scripts/motion/drive)when the simulation is starting. ### Insert a source A Source is automatically creating new components based on itself (what is called "spawning" in Unity). Please select *Assets > realvirtual> 3DPrefabs > Can* and drag and drop it into the scene. Place the can at the beginning and on top of the conveyor. Another way for creating the "standard" can source is to select the *TransportSurface* within the scene and to press **INS** on the keypoard. Your model now looks like this:

Added source to the conveyor

Please move the source to the beginning of the conveyor. ### Test the conveyor Now we can test the conveyor. Start the simulation with the Unity *Play* button.

Your first Digital Twin - a conveyor with the source

You might see that the texture on the conveyor is not moving in the right relation and the right direction. You need to set the texture scale yourself. Please select the *TransportSurface* and enter a *-2* into property *Texture Scale.* ### Insert a Sensor As a last step we would like to place a [*Sensor* ](/components-and-scripts/sensors/sensor)(light beam) at the end of the conveyor. Please create an empty *GameObject* into the Scene by selecting *GameObject > Create Empty* or by selecting ![](/files/V7yTeMKKx0zRqL597civ)on the QuickEdit overlay. If your new GameObject is added as a child please drag and drop it to the top level in your model. Rename the new GameObject to *Sensor*. Next select *Tools > realvirtual > Add Component > Add Sensor* or select *Sensor* on the QuickEdit overlay. Last but not least you need to move the *Sensor* GameObject to the end of the *TransportSurface*. Your model now looks like this:

Added Sensor to the end of the TransportSurface

Now you can start again the simulation and you will see, that the Sensor is getting occupied (red):

Sensor in the Digital Twin during simulation

{% hint style="warning" %} Don't forget to save your model by selecting *File > Save* {% endhint %} ### Summary and what's next This is just a first quick starter. Please check the [Demo model](/basics/demo-model) and learn how the functions are realized. Also check the section [Physics ](/basics/physics)to learn more about the physics simulations, collision detection and kinematic movements. Based on that you should check the whole section [Components & Scripts](https://github.com/game4automation/doc/blob/doc/basics/broken-reference/README.md) to learn more about the details. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Physics Simulating real world physics One of the great advantages of Unity is the very well-functioning physics simulation. It is based on the [NVIDIA ](https://nvidia.com)PhysX engine, which has been extended with the Unity API. The Unity engine is able to simulate very large systems with many meshes and moving objects. This is combined with a very realistic and good real-time rendering. The approach of realvirtual.io is based on a combination of physical and kinematic motion capabilities. In some cases it is advantageous to use physical movements, in other cases it is recommended to use purely kinematic movements. The strength of Unity and realvirtual.io is that we can combine both worlds to get very realistic, powerful, but also stable and accurate models. {% hint style="info" %} If you need very high quality physics simulation with multi contact simulation and high accurate dynamics, you can also use [AGX Dynamics for Unity](/extensions/agx-physics), which is supported by realvirtual.io {% endhint %} ## Physical and kinematic movements ### Free physical movements of movable units In automation systems, freely movable objects are very often required. We call this kind of objects in realvirtual.io [MU ](/components-and-scripts/mu-movable-unit)(movable unit). [`MUs` ](/components-and-scripts/mu-movable-unit)are goods on a conveyor belt or objects on a workpiece carrier, in general the products moving in a Digital Twin of a production system. Physical movements means that these MUs move due to physical collisions, forces and gravity. Just like in the real world. This allows for very realistic behavior and takes into account all collisions between MUs and the environment without having to program any special motion or behavior logic. In Unity, everything simulated via the Unity Physics Engine must hava a RigidBody component attached to. In realvirtual.io, Sources (see the [Source](/components-and-scripts/mu-movable-unit/source) section) create [MUs](/components-and-scripts/mu-movable-unit). After a MU is created, the physical properties look like this:

MU with gravity turned on and IsKinematic turned off

As you can see *Use Gravity* is enabled and the *Is Kinematic* property is turned off. {% hint style="success" %} *Is Kinematic* turned off (false) means, that the object is freely moving based on collisions and physical forces. {% endhint %} ### Stability of TransportSurfaces Normal transport on conveyor systems is modelled by [TransportSurfaces. ](/components-and-scripts/motion/transportsurface)If your transport system is very complex and you have a lot of colliders you should consider the following things: * use the simples colliders possible (best is box collider) * put the colliders on the standard layers (see [#colission-matrix](#colission-matrix "mention")) * You can limit the freedom of the RigidBodies with a setting on the [TransportSurface:](/components-and-scripts/motion/transportsurface)

Limiting the freedom of movement on enter and exit onto a TransportSurface

### Kinematic movements For parts that do not move freely physically like MUs are defined as kinematic parts. This applies, for example, to the motion of the machines themselves. For example, motor-driven axes, such as those found in robots and machines, are all represented with kinematic motion. Kinematic means that the position of the drive and the kinematic chain for multiple axes is precisely defined by their geometric parent - children relationship, excluding any application of force. Forces and the possibility that the kinematic chain may break are not considered in purely kinematic simulations. The engine calculates the exact current position of a part based on the different drive positions. We call this the kinematic motions. {% hint style="warning" %} Trying to represent e.g. a robot via PhysX joints (i.e. not kinematic) is often problematic, because the PhysX physics solver has a kind of "spring effect" in the axes themselves so that exact positioning is not possible. Therefore we use kinematic movements for this purpose. {% endhint %} Kinematic movements are realized based on the GameObject hierarchy. This means that when a parent object moves, the child object also moves. This is Unity's default behavior for non-physical objects. These objects must still have a *RigidBody* to allow accurate position and sensor collision detection, but the *Use Gravity* property must be turned off and the *IsKinematic* property turned on. {% hint style="success" %} *IsKinematic* turned on (true) means, that the GameObject moves based on the parent child relation and the local transform positions. There is no spring effect in the joints and there are no forces calculated. {% endhint %} This is how a moving arm of a robot looks like:

Robot arm, kinematic chain and IsKinematic turned on

If you attach a Drive to a hierarchy level, realvirtual.io automatically adds a RigidBody and handles property settings for Kinematic movements. ## Articulation Body With Unity 2020.1 the physics was upgraded to PhysX4.0. Unity introduced the new concept of articulation: a set of bodies organized in a logical tree, where a parent-child relation expresses the idea of mutually constrained motion. There is always a single root body, and there can be no loops. The transform hierarchy is used to express articulations. The amount of degrees of freedom in a given parent-child relationship depends on the actual joint type used. For more information please check {% hint style="info" %} To use Articulation Bodies is just an option. We still recommend to use standard realvirtual.io Kinematic definitions based on drives and transforms. {% endhint %} If you would like to use Articulation Bodies you must attach the realvirtual.io Drive to the Articulation Body. The Drive position will now be transformed to the Articulation Body. The Drive direction needs to be set to "virtual" because the Direction of the Joint (and the connected drive) will be defined by the Articulation Body. You can check an example on realvirtual.io Community Github

Robot arm with Articulation Body and a Drive (Direction set to "virtual").

## Collision Matrix To deliver fast collision detection, realvirtual.io uses an individual collision matrix. This matrix is automatically generated when you select *Tools > realvirtual > Apply standard settings*. \ realvirtual.io is using the following special collision layers:

Physics - realvirtual.io collision matrix (up to version 2021)

Physics - realvirtual.io collission matrix (version 2022 and above)

| Layer (until 2021) | Layer (2022 and above) | Description | | -------------------- | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | g4a SensorMU | rvMUSensor | Layer for the collision body of moving units () that should interact with sensors such as light barriers. Due to the limitations with the Mesh Collider this collision body should be a Box Collider. | | g4a TransportMU | rvMUTransport | Layer for the transport collision body of an. This can be a mesh collider to provide realistic collisions. | | g4a Sensor | rvSensor | Layer for detection areas such as light beams and so on. Usually this should be a box collider. | | g4a Transport | rvTransport | Layer for the collision body of transport surfaces or for placing objects onto a plate. | | g4a MU | rvMU | Layer for MUs where one box collider is sufficient for transport collisions and sensor detections. | | g4a Snapping | rvSnapping | Only used in Simulation Library - Layer for snapping detection | | g4a CollisionDynamic | rvSimDynamic | Only used in Simulation Library - Layer for moving Transportables on path system | | g4a CollissionSatic | rvSimStatic | Only used in Simulation Library - Layer for detecting Transportables on path system, used by Workstations | | g4a Postprocessiong | deleted | not used - for future usage | | g4a Lamps | deleted | not used - for future usage | | g4a Debug | deleted | not used - for future usage | ## Physic solver settings Physics settings are described in detail on the Unity webpage but we would like give you some hints based on our experience. First of all you should only change something in the Physics settings, if you are not happy with stability and performance. Usually the standard settings work quite well. ### Physics Step Time Unity is calculating physics in a fixed steptime. This is when the FixedUpdate methods are getting called. You can change the time steps by selecting `Edit > Project Settings > Time:`

Changing the fixed timestep

The standard setting is 20ms. You can decrease it e.g. to 5ms. This will increase physical calculation quality but also increase your processor load. If your processor load is getting to high you well see that screen update rates are getting low (e.g. 60ms and less). ### Solver Iterations Another possibility to generate better physics simulation is to increase the solver iterations. You can increase solver iterations to generate better quality but this will increase also your load. Typically, it’s used to reduce the jitter resulting from joints or contacts.

Solver iterations and solver type

### Physics Solver Another setting which usually generates better physics is to change the solver type from standard (`Projected Gauss Seidel`*)* to `Temporal Gauss Seidel.` It usually helps when you experience some erratic behavior during simulation with the default solver. We recommend to use this setting. For more information check the Unity documentation: {% embed url="" %} © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # CAD import (Pro) Importing 3D data from mechanical design systems Unity is able to process standard mesh-based file formats such as fbx, obj and collada. Mechanical design systems (CAD systems) are usually not able to process these game-oriented 3D data. realvirtual.io Professional includes [CADLink (Pro)](/basics/cad-import/cadlink)for importing CAD data. CADLink allows you to import CAD files from any CAD system that can export step or 3MF files. Another option for importing 3D data is to use the PIXYZ plugin, see [https://unity.com/de/products/pixyz.](https://unity.com/de/products/pixyz) © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # CADLink (Pro) Importing Step, JT and 3MF files from CAD systems {% hint style="warning" %} CAD Import for Step and JT files works only in Unity-Editor (not in Unity Builds) and only on Windows systems (not with OSX or Linux Unity Editors). I {% endhint %} CADLink is available as a separate asset in the Unity Asset Store and it is included in the realvirtual.io Professional package. CADLink is able to import 3MF files, STEP and JT files into Unity. STEP is a de facto standard for 3D CAD data and more or less all CAD Systems are able to export STEP files. {% hint style="info" %} Advanced tools for working with large assemblies like [Selection Window](/basics/user-interface/selection-window), [CAD Checker](/basics/cad-import/cad-checker) or [CAD Updater](/basics/cad-import/cad-updater) are only included in realvirtual.io Professional. CADLink as a standalone solution only supports what is described on this page. {% endhint %} Please check also the Youtube video, which demonstrates CADLink and working with large mesh data: {% embed url="" %} Large CAD data and Unity {% endembed %} After installation, you will find CADLink under `Assets>CADLink`, if you are using it as a stand-alone asset or you will find it under `game4automation>private>CADLink` The folder structure looks like this:

CADLink folder

In the main folder you will find sample scenes for each import type, e.g. as a 3MF file and another scene based on a STEP file. To import 3D data into your scene you need to drag and drop the CADLink prefab into your scene or you can use in realvirtual.io Professional the Menu realvirtual`> Add CADLink (Pro)` You are now able to import your CAD assembly as a sub-hierarchy into the CADLink top node. It is possible to include in one scene multiple CADLink interfaces if needed. {% hint style="warning" %} Please make sure that the name of your import file only consists of letters from the latin alphabet. {% endhint %} The import is always done into the scene itself as meshes in child objects under the CADLink top node. No prefab is created and the meshes are only present in the scene itself. If you would like to create a prefab you could use Unity’s FBX exporter (see ) after importing into the scene. ## CAD Updater (only included in realvirtual.io Professional) With CAD Updater you can update your scene data based on a new version of the CAD file without losing anything that you added to the Gameobjects inside the scene. This is a semi-automated process. Before updating you can check changes that are going to be performed by the update. CAD Updater is attached and started automatically if there is already something existing under CADLink when you start the CADImport. If you don’t want to perform an update you must manually delete all Data which have been imported before. For more information please read the section [CAD Updater (Pro)](/basics/cad-import/cad-updater). ## Importing STEP/JT files To import STEP /files is the recommended way for reading data of CAD Systems. When importing Step files the tessellation is done within Unity. {% hint style="info" %} Please note that the import of large CAD files (e.g. 1.5 GB) can take up to 30 to 45 minutes. {% endhint %} ### STEP Import Settings The STEP import settings are very simple:

Importing CAD data in Step format

#### File The file (\*.jt,\*.stp or \*.step) to import. #### Import Scale Factor The scale factor of the import. 0.001 corresponds to one Unity Unity equals 100mm. #### Quality You can select 6 different quality modes for the mesh tessellation (very low, low, middle, high, very high, ultra). {% hint style="info" %} Please always **use lowest quality level** which is giving you the needed visual quality in a normal camera distance. Importing components in to high quality levels might impact perfromance in very large models. Specially if you would like to create reusable components you should take care about a suitable quality level. Usually you should use **low**, **middle** or **high** quality level. {% endhint %}

Low, Middele and Very High Quality level

#### Z is Up-Vector If you set this parameter true, your import data will be rotated so that the Z-axis points upwards. #### Create Prefab Generates a reusable [prefab](/basics/reusable-components-prefabs#creating-prefabs-in-realvirtual) from the imported data, saved in the Assets folder. #### Set and create materials If `false`, the Step import applies a standard material with an Albedo value corresponding to the color in the Step file. This material will be attached to the mesh and is not an instantiated shared material which is available in the Assets folder. {% hint style="info" %} For reusable components, for better visual quality and for better performance it is recommended to assign instantiated shared materials and to import with `Set and create materials = true` {% endhint %} If `true`, for all imported materials where no material mapping is defined, automatically a standard material is created with the name `Col#[Hexcode]`. This material is placed into the given standard folder (realvirtual`> CADLink > Materials`).

Created material with import option "Set and create Materials"

If a Material mapping is defined, during Import CADLink is trying to map the colors defined in the Step files to Unity Materials. To do this it is necessary to define a Material mapping where you need to select the color value of the Step color and the corresponding Material. A material mapping scriptable asset is created by `Create >` realvirtual`> Add material mapping`.

Mapping Step import colors and Unity materials

## Importing 3MF files Some CAD Systems like Solidworks, Solidedge, ProE / Creo and NX are able to write 3MF Files. Please check your CAD System documentation to see if your system is also able to write 3MF Files. The advantages of 3MF files are: * The tessellation is done by the CAD System which provides usually a very good quality * It is the modern tessellation 3D-printing standard - which fits perfect to Unity * Assembly structure is included * Color and material information is included * It is zipped and low sized * It includes multiple occurrences only one time - which reduces the file sized ### Known Limitations with 3MF files #### Solidworks (Dassault) No known limitations. Solidworks exports everything correct (assembly structure, colors and materials). #### Solidedge (Siemens PLM) No known limitations. Solidedge exports everything correct (assembly structure, colors and materials). Please use this export options: ![](https://realvirtual.io/documentation/current/images/cadlink-solidedge.png) #### Fusion360 (Autodesk) You can use this solution to write 3mf files:\ Colors and assembly structure is not exported correct (flat structure without colors). #### ProE / Creo No known limitations #### NX (Siemens PLM) NX is exporting currently no assembly structure. Colors are exported. ### 3MF Import Settings In the Inspector you can check and change the CADLink settings:

Importing 3MF data

#### Import CAD **File** You can type in the relative or absolute File path or you can select the file path by pushing on the button `Select CAD Import File` **Delete before importing** This deletes the old imported data automatically when importing once again. **Remove top assembly node** Removes the top assembly node when importing the CAD data. This means that CADLink object is acting like the top assembly node. **Name Clones Identical** If clones (multiple occurrences of an identical part in the assembly structure) you can name all of the same or you can let the importer add a number in brackets to the imported name. **Import scale factor** The scale factor for the import. Normally, if one unit in Unity means for you 1 meter and you are exporting the 3mf file in millimeters this should be 0.001. #### Advanced Settings **This should be normally turned on. Even if the exporter is combining vertices at the same position into one vertex, CADLink is separating them. This makes usually the rendering much nicer if this is combined with *****Advanced recalculate normals*****.** **Unity recalculate normals** Defines that Unity should recalculate the normals. We recommend to turn that off. **Advanced recalculate normals** Lets the importer to recalculate the normals and - if needed - to combine the separated vertices again to one. The calculation is done based on the angel between the triangle surfaces. If the angle is above the defined angle (in Degrees) an edge is created (with separated vertices). This gives a sharp edge shading. If the angle is below the vertices are combined and a normal is calculated which gives a smooth edge. See the difference in this pictures.\ With recalculated normals: ![](/files/M2sVkzmEAGN9IjfYr83S) Without recalculated normals: ![](/files/6GjD9dEZNpPX7OrjSa0s) **Calculate UVs** This option takes some time when importing. So please just turn it on when needed. You can calculate UVs automatically for mapping material textures on the surface. You can change the UV scale factor. With scale factor 0.01:

UV scale factor 0.01

With scale factor 1:

UV scale factor 1

#### Materials Usually during the import new materials are created - if not existing - based on the naming of the imported color. You can change these materials if needed. Another option is to define a Material Mapping. This will map a given material to a certain imported material and color name combination. You can start the material assignment independent from the import by pushing the button “Update Materials”. In the import process the materials are automatically updated. **Set and Create Materials** If turned of no materials are created during import. **Overwrite Existing Materials** If a material which is currently imported already exists it will be overwritten. **New Material Path** Defines the path where the new imported materials should be created. **Material Mapping** Defines the Material mapping table. You can have in your project multiple material mapping tables. To create a new one and to automatically assign the new one to the CADLink object just press the button `Create New Material Mapping` In the Material Mapping settings you can define a color and/or a material name and assign this to a Unity material. CADLink checks the assignment in the following order: * First, assign materials if the Material name and Color name are defined in the table (and if they are not empty). * Second, assign materials if the Material name is in the table and the Color name is empty. * Third , assign if the Color name is in the table and the Material name is empty. ### Import 3MF during runtime You can import 3MF files also during runtime. During runtime import materials are not created in the Material Assets. For changing materials you must provide before importing during runtime all materials with a corresponding Material Mapping. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # CAD Checker (Pro) Analyzing large CAD data for performance bottlenecks With CAD Checker an imported CAD file can be checked. This is mainly usefull for verly large assemblies for detecting performance bottlenecks. This includes * calculation of triangles, static meshes, and non-static meshes * detection of the largest meshes for further optimization * detection of unnecessary mesh duplicates for performance optimization ## **CAD Checker Window** To open the CAD Checker window please select `Tools > realvirtual > CAD Checker (Pro)` in the realvirtual.io menu. This will open this window: \\

Checking the meshes in large CAD data with CAD Checker window

In the window, you can get a quick overview of the triangles in the model and the optimization possibilities.\ First, you will need to select the level of the model you want to check under `Check this`. If you select `upper part naming` the name displayed in the first column of the mesh list is the name of the Gameobject one level above the mesh itself. This is the usual setup for most imported CAD data.\ Next, you should select if you want to see all occurrences in the model (what means all identical meshes) in one line or as separate lines. To detect duplicates you should select `Show Occurencies`.\ Now you can see the total number of meshes and triangles in the model. The list is displaying you all meshes sorted by the total number of polygons. This means that `_CarrierA` in the model has in total 372912 Polygons with 34 occurrences. That means that 34 identical meshes are in the model. These meshes make 372912 Polygons. But there are also 10 Duplicates in the model. Duplicates are identical meshes with identical positions. Usually, you should prevent to have duplicates in the model because they are normally unnecessary. {% hint style="info" %} The statistics also show the number of static meshes. Please take care, for performance reasons, that all components that don’t move inside your model should be marked as “static”. {% endhint %} With `Show` you can Ping the object and with `Filter` you can display all the components isolated. With *Select* you can select all components and with `Duplicates` only the duplicates are selected. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. \\ # CAD Updater (Pro) Updating (reimporting) CAD Data With CAD Updater you can compare a newly imported CAD file with the current CAD file in your Unity project. For comparison, both CAD data are imported into different sub-game-objects into the same scene. The CAD Updater supports imports from CADLink and custom sources like PIXYZ. Note that part IDs for comparison are automatically generated based on the CAD design path (e.g., 'Assembly2|Subassembly3|Part1'). For successful CAD updates, ensure that part names remain unchanged and the part structure is not reordered. ## CAD Updater based on custom imports For custom imported data, the CAD Updater must be applied to the top level of the existing CAD data. Specify both the Current CAD Data (CAD Current) and the Update Data (CAD Update). It's crucial that the structure and naming below CADCurrent and CADUpdate remain identical (except for added or deleted parts). Once set up, click "Compare Current with Update" to review detected changes. Use the "Isolate Buttons" to inspect changes in detail. If everything checks out, select "Update" to apply the changes. Please refer to the section below for more detailed information about CADUpdater.

CADUpdater Settings for custom imports

## CAD Updater based on CADLink imports If you are using [CADLink ](/basics/cad-import/cadlink)for reading in the CAD Data the CAD Updater component will be attached automatically to the parent Gameobject of CADLink as soon as you are updating your CAD data. All properties and options of CAD Updater are set automatically. Update means that there are already CAD data underneath CADLink and you import new CAD data. If you don’t want to perform an update you should delete all data underneath CADLink before importing a new CAD file. {% hint style="info" %} For Step and 3MF data there are some limitations with the CAD Update. Each mesh is defined by an ID and compared with the newly imported mesh. Because there are no special ID and revision properties inside the Step or 3MF data (like with JT), the ID of each part is defined by its location in the hierarchy and an occurrence number if there are two identical names at the same hierarchy level. This means that you should not rearrange elements (changing parents) under the CADLink object. Instead, you should use the [Kinematic ](/components-and-scripts/motion/kinematic)script for rearranging the kinematic parents and children. {% endhint %} ## Comparing CAD files CAD Updater is automatically added to the CADLink component as soon as you import a CAD file a second time. After the second import the following message will pop up:

Update check finished

CAD Updater script is automatically added:

CAD updater inspector

After the update import, the comparison between the current and the new CAD data is started automatically. You can restart it manually with the Button `Compare Current with Update`. The Isolate Buttons allow you the see in detail what has been changed in the Update. On the left-hand side of the Unity Hierarchy View, you can see a status icon that is informing you about the status of the CAD component.

CAD Updater status icons

| Icon | Description | | ------------- | ----------------------------- | | Green Hook | No changes | | Red Cross | Is deleted in Update | | Blue Plus | Is added in Update | | Orange ! | Mesh is changed | | Orange Arrows | Position is changed in Update | After the update check, you can update your current CAD data by selecting `Update`. All changes will be performed on the current CAD data and the update import will be deleted. Your current CAD data will now be like the Update but all changes that you performed within Unity/realvirtual.io will remain. ## Manual Control Each component in the CAD design will have automatically added a CAD script. This script takes care of the current status and you can control exactly the Update behavior. By selecting `Keep` or `Keep Including Children` you can Keep the current object (including the children if selected) and it will not be touched by the Update process. If there is no relation found between the Current and the Update CAD data it could be that something is marked as to be deleted but you want to keep and update this. You can manually generate a relation by dragging an Update CAD Script into `Keep` *and* `Replace by Update`. This will manually set the IDs of the Update and the Current Identical and the Update will be performed.

CAD script for manual update control

© 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Reusable Components (Prefabs) How to build up your own reuse library. Only available with the professional version. ## Overview Prefabs are powerful assets that allow developers to create, store, and reuse preconfigured game objects and their components. When creating optimal prefabs for your project, keep the following best practices in mind: 1. **Simplify GameObject Structure**\ Ensure the hierarchy is as simple as possible. Avoid unnecessary nesting or components to improve performance and maintainability. The realvirtual tool "[Clean Up Hierarchy](/components-and-scripts/performance-tools/combine-meshes-pro#hierarchy-clean-up)" supports this. 2. **Use Instantiated Materials**\ All materials should be instantiated. This helps reduce memory usage and allows efficient batching during rendering. You can use the option "Set and Create Materials" in the [CAD link](/basics/cad-import/cadlink#step-import-settings) component and create instantiated materials when importing your data. 3. **Use Instantiated Meshes**\ Ensure that meshes are unique instances to avoid conflicts and improve compatibility when creating prefabs. 4. **Combine Meshes**\ If components consists of several meshes use the [**Mesh Combine**](/components-and-scripts/performance-tools/combine-meshes-pro) to merge multiple meshes into a single mesh. 5. **Share Materials Where Possible**\ Use shared materials across multiple objects to minimize the number of draw calls. The fewer unique materials, the better the performance. By adhering to these principles, you can create prefabs that are efficient, scalable, and ready for integration into complex projects. ## Creating Prefabs in realvirtual (Pro) The `PrefabGenerator` is a utility designed to simplify the creation of prefabs. It operates in the Unity Editor and automates the process of generating prefabs, including handling sub-assets such as dynamically created meshes within child objects. It also considers Drives, Kinematics, and Group definitions, preserving their structure when creating the prefab. The PrefabGenerator also includes instantiated meshes in the scene (e.g., from previous combining), resulting in lighter scenes. {% hint style="warning" %} Combine Meshs and Create Prefab are only included in realvirtual.io Professional version Please also check detailled documentation here: [Combine Meshes](/components-and-scripts/performance-tools/combine-meshes-pro) [Create Prefab](/components-and-scripts/performance-tools/create-prefab-pro) {% endhint %} ### Usage * Select the GameObject in the Scene Hierarchy that you want to convert into a prefab. * Right-Click in the hierarchy area and select realvirtual/Create Prefab * A prefab will be created in the `Assets/` folder with the same name as the selected GameObject. ### Example For the example, we start with a CNC machine where components like "Drives" are already defined, along with some group definitions.

Game Object structure after import: starting point

To prepare this GameObject as a prefab, follow these steps: * Clean up the hierarchy: realvirtual/Clean up Hierarchy * using realvirtual/Combine Meshes for every main Game Object After these steps the structure look like this:
Now your Game Object is prepared and ready to create a prefab:
# Cadenas parts4cad Standard industrial 3D components for Unity {% hint style="info" %} Parts4cad is removed from realvirtual.io Starter and Professional 2022 and above. You can still download it from the Asset Store. You can use the new online solution instead of Parts4CAD {% endhint %} parts4cad offers access to millions of parametric 3D CAD models from over 500 parts catalogs for free. The original data of the manufacturers is based on the eCATALOG solutions technology by CADENAS ().\ The data is imported into Unity as Collada. All imported parts are still connected to the CADENAS database so that you can change later on parameters and update the part in Unity.\ parts4cad is a pure Unity Editor utility. {% hint style="warning" %} Parts4cad requires the parts4cad client software. If you use parts4cad the first time the parts4cad client will be downloaded automatically into the `StreamingAssets` folder inside of your project. {% endhint %} ## Installation and first usage {% hint style="info" %} Parts4CAD only works on Windows system. **In your project folder path no "Spaces" are allowed** Parts4CAD is already included in Starter and Professional version and does not needs to be installed separately. {% endhint %} After installing parts4cad from Unity’s Asset Store or after manual installation from an asset package you can start parts4cad by selecting `Tools > realvirtual > CADENAS parts4cad` in the main menu bar.
If you use parts4cad the first time a message will ask you to allow the download of the parts4cad client to the `StreamingAssets` folder:

Message before installing parts4cad

After selecting OK it will take some while to download a ZIP-file with the client and to unzip it into the `StreamingAssets` folder of your project:
## parts4cad client After installation the parts4cad client is started.

parts4cad client

You can now select a catalog from a provider or you use the search to search in all catalogs for a certain name or description of the wished part.

parts4cad searching for parts

After selecting a part a preview of the part is displayed and you can change parameters of the part if needed.

parts4cad part properties

For transferring the selected part to Unity you need to push the button Transfer to CAD (realvirtual.io). ## parts4cad parts in Unity After selecting the part in the parts4cad client you get the part imported as an asset into `game4automation>parts4cad>Imported`.

Imported parts4cad part in Unity

Additionally the part is placed into the scene. If you have selected a Gameobject in the scene the part will be placed as a subcomponent to the selected Gameobject. The imported part gets a Parts4Cad script attached. This script holds some important information about the imported part. If you select `Show Attributes` all catalog attributes will be displayed in a text window.

parts4cad component

For Updating the part parameters you need to select the `Update Part` button. This will reopen the parts4cad client with the part and you can update the part. If you select `Create New Part` a new part will be inserted into the scene. ## parts4cad uninstallation For uninstalling parts4cad you need to delete in the *`StreamingAssets`* folder the folder *parts4cad*. Additionally you need to delete the folder *`game4automation\parts4cad`*. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Publishing the Digital Twin Distributing the Digital Twin to partners, customers and prospects You can run your Digital Twin simulation model in the Unity Editor by clicking the "Play" button. However, this requires the Unity Editor to be installed. Publishing the Digital Twin allows you to share it with customers, partners, and prospects without having the Unity Editor installed or the need of any license. Like publishing a "game". ## Build Settings For publishing you first need to define your build settings. Build settings is opened by `File > Build Settings...`

Build settings

In Build settings the destination platform (WebGL, Windows, Linux, Mac, Android, iOS and so on) and the scene (the model) which should be included into build needs to be defined. After selecting Build you are asked to define the destination folder of your build. For some destination platforms you need to install additional packages to your Unity installation. There are some limitations, specially with some interfaces, for some destination platforms, which are described in [Supported Platforms](/advanced-topics/supported-platforms) Please also check Unity Documentation for more information about making a build: {% embed url="" %} ## Publishing Platforms realvirtual supports multiple publishing platforms to distribute your Digital Twin: * [Windows](/basics/publishing-the-digital-twin/windows) - Standalone Windows executable builds * [WebGL](/basics/publishing-the-digital-twin/webgl) - Browser-based deployment * [CMC ViewR](/basics/publishing-the-digital-twin/cmc-viewr) - Integration with CMC ViewR platform * [Innoactive](/basics/publishing-the-digital-twin/innoactive) - Cloud hosting and VR streaming platform Select the platform that best fits your distribution needs. Each platform has specific requirements and optimizations detailed in their respective documentation pages. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Windows Building standalone Windows executables for your Digital Twin Building for Windows allows you to distribute your Digital Twin as a standalone executable that runs on Windows machines without requiring Unity Editor or any special licenses. ## Build Settings To build for Windows, select **Windows** as the target platform in Build Settings (`File > Build Settings...`). ## Player Settings For building on Windows, the following settings are recommended in Player Settings. ### Scripting Backend Mono compiles much faster than IL2CPP and is recommended for most Windows builds.

Mono and .Net Framework player build settings

### Scripting Define Symbols Please also make sure that Scripting Define Symbols are set as needed for your installation (see [Compiler Defines](/advanced-topics/compiler-defines)).

Scripting Define Symbols configuration

## Build Process 1. Open **File > Build Settings** 2. Select **Windows** as the target platform 3. Click **Add Open Scenes** to include your Digital Twin scene 4. Configure Player Settings as described above 5. Click **Build** and choose your destination folder 6. Unity will create an executable and data folder ## Distribution After building, you will have: * **YourProjectName.exe** - The executable file * **YourProjectName\_Data** folder - Required data and assets * **UnityPlayer.dll** and other DLL files - Required Unity runtime libraries Distribute all files together. The executable requires the data folder and DLLs to run properly. ## Performance Considerations * **Mono vs IL2CPP**: Mono compiles faster and has similar runtime performance for most scenarios * **Graphics API**: Windows supports DirectX 11 and DirectX 12 * **Architecture**: Target x86\_64 for modern 64-bit Windows systems * **Optimization**: Use IL2CPP for production builds if startup time is not critical ## Interface Support Windows builds support all realvirtual interfaces including: * OPC-UA * S7 TCP/IP * Modbus * TwinCAT ADS * MQTT * Shared Memory * And all other platform-specific interfaces For interface limitations on other platforms, see [Supported Platforms](/advanced-topics/supported-platforms). ## See Also * [WebGL Publishing](/basics/publishing-the-digital-twin/webgl) - Browser-based deployment * [Supported Platforms](/advanced-topics/supported-platforms) - Platform compatibility matrix * [Compiler Defines](/advanced-topics/compiler-defines) - Configuration symbols © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. # WebGL Browser-based deployment of your Digital Twin using WebGL WebGL builds allow you to run your Digital Twin directly in web browsers without any installation. This enables easy sharing and access through URLs, making it ideal for demonstrations and client presentations. ## Prerequisites WebGL build needs to be done with IL2CPP, and Windows DLLs which are used in some interfaces can't be used (only way to communicate from a browser is Websocket). ### Required Folder Deletions For building WebGL, you need to delete the following folders if they are in your project: * CADLink * SpaceNavigator * All Interfaces (besides MQTT and TwinCATHMI - these both are the only ones which are possible with WebGL) * parts4cad * RobotIK {% hint style="info" %} When building to WebGL the rotation of the scene is done with the left mouse button and not the middle mouse button because web browsers have a different mouse button behavior. {% endhint %} ## Build Configuration ### 1. Set WebGL Platform Set WebGL in Build Settings:

Setting WebGL in Build Settings

### 2. Scripting Define Symbols Make sure that in Player Settings Scripting Define Symbols you have the same settings as for Windows (e.g., `GAME4AUTOMATION` and `GAME4AUTOMATION_PROFESSIONAL`). ### 3. Graphics API Configuration Disable Auto Graphics API in Player Settings to use exclusively WebGL2 (recommended):

WebGL2 Graphics API configuration

### 4. Compression Settings In Publishing Settings set Decompression Fallback - this prevents problems with some web servers.

Decompression Fallback setting

## Build Process {% hint style="warning" %} WebGL builds take sometimes a very long time (up to 1 hour), specially for the first build. As soon as the build is successful Unity starts automatically a temporary web server and opens your browser with your WebGL build. For running the WebGL build you need to copy the result of the build (the content of your build folder) to a web server. {% endhint %} 1. Open **File > Build Settings** 2. Select **WebGL** as the target platform 3. Configure Player Settings as described above 4. Click **Build** and choose your destination folder 5. Wait for the build to complete (this may take 30-60 minutes) 6. Unity will automatically start a local web server and open your browser ## WebGL Template (realvirtual Professional) Enhance your Unity WebGL projects with the **realvirtual** WebGL Template, offering a full-screen, responsive design for an improved user experience compared to the standard Unity WebGL Template. ### Installation Steps 1. **Locate Template Files**: Find the template files in your Unity project at: ```bash Assets/realvirtual/Professional/WebGLTemplate/realvirtual ``` 2. **Copy Template Files**: Copy these files. 3. **Paste into WebGLTemplates**: Paste the copied files into: ```bash Assets/WebGLTemplates/realvirtual ``` ### Setting the Template 1. Open Unity. 2. Go to **Edit > Project Settings**. 3. In **Player** settings, find **Resolution and Presentation**. 4. Choose the **realvirtual** template from the "Template" dropdown menu. 5. Save your changes.

realvirtual WebGL Template selection

## Deployment ### Web Server Requirements To deploy your WebGL build: 1. Copy the entire build folder contents to your web server 2. Ensure your web server supports: * Proper MIME types for Unity files * Compression (gzip or Brotli) * HTTPS (recommended for full functionality) ### Common Web Servers * **Apache**: Add .htaccess with proper MIME types * **nginx**: Configure mime.types for Unity file extensions * **IIS**: Add MIME types in web.config * **Cloud platforms**: AWS S3, Azure Static Web Apps, GitHub Pages ## Interface Support WebGL builds have limited interface support due to browser security restrictions: **Supported Interfaces:** * MQTT (Pro) - Websocket-based messaging * TwinCAT HMI (Pro) - Websocket-based communication **Not Supported:** * OPC-UA * S7 TCP/IP * Modbus * TwinCAT ADS * Shared Memory * Any Windows DLL-based interfaces For full interface compatibility, use [Windows builds](/basics/publishing-the-digital-twin/windows). ## Performance Considerations * **Build Time**: First builds can take 30-60 minutes * **File Size**: WebGL builds are typically larger than native builds * **Runtime Performance**: 60-70% of native performance is typical * **Memory**: Browser memory limitations apply * **Mobile**: Limited support on mobile browsers ## Browser Compatibility Recommended browsers: * Chrome/Edge (Chromium-based) - Best performance * Firefox - Good compatibility * Safari - Basic support (may have limitations) ## Troubleshooting ### Build Fails * Ensure all incompatible folders are deleted * Check that IL2CPP is selected as scripting backend * Verify WebGL module is installed in Unity Hub ### Build Runs Locally But Not on Server * Check web server MIME type configuration * Verify compression settings match build settings * Ensure HTTPS is enabled if using certain features ### Performance Issues * Reduce scene complexity * Use texture compression * Optimize draw calls * Consider quality settings for WebGL ## See Also * [Windows Publishing](/basics/publishing-the-digital-twin/windows) - Full-featured native builds * [Supported Platforms](/advanced-topics/supported-platforms) - Platform compatibility matrix * [Improving Performance](/advanced-topics/improving-performance) - Optimization techniques © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. # CMC ViewR Integration with CMC ViewR platform for advanced visualization CMC ViewR is an advanced immersive viewing application specifically designed for visualizing CAD data. It supports a variety of immersive experiences, including use with VR glasses and large 3D projections, providing an enhanced and interactive environment for users. The application supports the import of scenes from **realvirtual**, allowing seamless integration and visualization of complex industrial digital twin scenes within the CMC ViewR platform. {% hint style="info" %} This feature requires **realvirtual Professional** license. {% endhint %} {% hint style="warning" %} **Beta Feature**: CMC ViewR integration is currently in Beta (available since release 6.0.7-beta). The functionality and workflow may change in future releases. Please report any issues or feedback to realvirtual support. {% endhint %} ## Restrictions and Limitations When exporting realvirtual scenes to CMC ViewR, please note the following restrictions: ### Unsupported Components The following components are not supported as CMC ViewR provides its own interaction and navigation systems: * **SceneSelectables** - Not working (CMC ViewR uses its own selection and interaction system) * **DebugConsole** - Not working (replaced by CMC ViewR's debugging and logging features) * **RealvirtualRuntimeUI** - Not working (replaced by CMC ViewR's interaction and scene navigation interface) ### Custom Scripts Requirement * **Custom scripts must be inside an Assembly Definition** - Any custom scripts you've created need to be organized within an Assembly Definition file (.asmdef) to be properly included in the AssetBundle export. See the [Preparing the Scripts](#2-preparing-the-scripts) section below for detailed instructions. {% hint style="info" %} **Automatic Deactivation**: When the AssetBundle is loaded in CMC ViewR, all components except **realvirtualController** are automatically deactivated. The realvirtualController remains active to maintain core simulation functionality, while CMC ViewR handles all user interaction, scene navigation, and UI presentation through its native platform features. {% endhint %} ## Overview CMC ViewR is an XR (extended reality) platform designed specifically for industrial applications, enabling professionals to work with digital twins in the industrial metaverse built directly from 3D data. The platform excels at real-time 3D visualization of CAD data and supports both VR headsets and large 3D projections. ### Key CMC ViewR Capabilities **Virtual Engineering:** * Concept evaluation and validation on digital prototypes * Virtual commissioning and industrial engineering * Error reduction through early validation * Digital twin applications for plant coordination **Virtual Showroom:** * Immersive product demonstrations without physical prototypes * Reduced logistics and exhibition costs * Maximum product customization flexibility * Independent of physical product availability **Collaboration:** * Multi-user virtual project rooms * Supports both VR headsets and desktop participants * Real-time collaboration across distributed teams * Point cloud integration with 3D data ### Hannover Fair 2024 Demonstration Here is a presentation of CMC ViewR and realvirtual on Hannover Fair 2024: {% embed url="" %} ## Integrating realvirtual AssetBundles into CMC ViewR The CMC AssetBundleBuilder enables the visualization of realvirtual Unity scenes in CMC ViewR with full functionality. This guide explains the necessary steps to export a Unity scene as an AssetBundle and load it into CMC ViewR. ### Download CMC AssetBundleBuilder Download and import the CMC AssetBundleBuilder Unity package into your realvirtual project: {% file src="/files/wqpXWCvlV6J6cpWIiF5m" %} CMC AssetBundleBuilder Unity Package {% endfile %} To install: 1. Download the Unity package file using the download button above 2. In Unity, go to **Assets > Import Package > Custom Package...** 3. Select the downloaded `CMC_AssetBundleBuilder.unitypackage` 4. Import all files in the package ### 1. Preparing the Unity Scene CMC ViewR uses its own user interface (UI) within the scene. You can keep your Unity cameras and UI elements active - CMC ViewR will handle the viewing environment. ### 2. Preparing the Scripts To ensure all scene functionalities are successfully transferred into the AssetBundle, the required scripts need to be placed in a specific directory and associated with an **Assembly Definition**. For more information about Unity Assembly Definitions, see the official Unity documentation: {% embed url="" %} Unity Assembly Definition Files Documentation {% endembed %}

Unity context menu to create an Assembly Definition

All realvirtual scripts are already equipped with Assembly Definitions. However, if you have additional functionality, it's important to include these in a corresponding Assembly Definition. The following figure shows an example.

Example of an Assembly Definition for additional functionality

### 3. Creating the AssetBundle Once the scene is prepared, the AssetBundle can be built. For this, the **CMC AssetBundleBuilder** is used. The main function of the AssetBundleBuilder is to convert the objects in the currently loaded scene, along with their scripts, into an AssetBundle, which can then be loaded into CMC ViewR. To do this, open the AssetBundleBuilder window via the toolbar under the **CMC** tab. In this window, you need to provide two inputs: * The storage location for the AssetBundle * The name of the AssetBundle After setting these values, click the **Generate AssetBundle** button to build the AssetBundle.

CMC AssetBundleBuilder window

### 4. Importing the AssetBundle into CMC ViewR In CMC ViewR, Unity AssetBundles with the `.unity3d` format can be imported. To load an AssetBundle, open the **Start** tab and select the **Import** function.

Import function in CMC ViewR

### 5. Using ViewR After successfully importing the AssetBundle, the scene can be viewed in CMC ViewR.

Loaded realvirtual AssetBundle in CMC ViewR

CMC ViewR launches with a default desktop configuration. You can rotate the camera using the right mouse button and navigate through the scene with the middle mouse button. More features of ViewR can be explored in the **ViewR Manual**, which is available at: [ViewR Manual](https://www.cmc-viewr.de/de/downloads). ## CMC ViewR Resources For more information about CMC ViewR: * [CMC ViewR Official Website](https://www.cmc-viewr.de/en) * [CMC ViewR Manual (Downloads)](https://www.cmc-viewr.de/de/downloads) * [CMC ViewR Features](https://www.cmc-viewr.de/en/features) ## Related Publishing Options * [Windows Publishing](/basics/publishing-the-digital-twin/windows) - Create the Windows build first as a prerequisite * [WebGL Publishing](/basics/publishing-the-digital-twin/webgl) - Browser-based deployment alternative * [Innoactive](/basics/publishing-the-digital-twin/innoactive) - Cloud streaming platform * [Mixed Reality with Meta Quest3](/advanced-topics/mixed-reality-with-meta-quest3) - Direct VR/AR deployment ## See Also * [VR Builder](/extensions/vr-builder) - Alternative VR development tools * [Industrial Metaverse](https://github.com/game4automation/doc/blob/doc/extensions/realvirtual.io-industrial-metaverse) - Multi-user VR/AR solutions © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. # Innoactive Cloud hosting and streaming platform for Windows builds The realvirtual Streaming Platform (powered by Innoactive technology) enables you to publish and stream your Digital Twin to desktop browsers and VR headsets without requiring users to download or install anything. Users simply access a URL to interact with your simulation in real-time.
realvirtual Demo Scene streaming in Innoactive

realvirtual industrial simulation running in Innoactive cloud streaming platform

## Overview The realvirtual Streaming Platform hosts your Windows builds in the cloud and streams them to end users via their browser or VR headset. All compute processing happens on the cloud servers, so users can access complex industrial simulations even on lightweight devices. The platform provides a complete content management system for uploading, organizing, and sharing your digital twins. ### How It Works 1. **Upload** - Build your Digital Twin as a Windows executable and upload it to the realvirtual Streaming Platform 2. **Host** - Your application runs on cloud servers with full processing power 3. **Stream** - Users access your simulation through a simple URL in their browser or VR headset 4. **Interact** - Real-time interaction with mouse, keyboard, touch, or VR controllers The streaming platform shows your uploaded applications in a gallery view where users can browse and launch different scenes and experiences.
Innoactive Streaming Platform gallery view

Innoactive Streaming Platform showing uploaded applications including realvirtual demos, 3D HMI, and other Unity projects

### Key Innoactive Capabilities **Windows Build Hosting:** * Upload and host your Windows builds in the cloud * No installation required for end users * Automatic updates and version management * Enterprise-grade content management system (CMS) **XR Cloud Streaming:** * Stream to Meta Quest, Vive Focus, Apple Vision Pro * Desktop browser access without plugins * Remote compute processing for complex simulations * Low-latency streaming technology **Enterprise Deployment:** * Training deployment to employees, customers, and suppliers * Product showrooms and sales demonstrations * Industrial design reviews and planning * Scalable cloud infrastructure **Industry Applications:** * Manufacturing process training and visualization * Equipment operation simulation * Facility planning and digital twin reviews * Remote collaboration and demonstrations ### realvirtual Integration realvirtual Professional integration with Innoactive enables: * Upload Windows builds of your Digital Twin to the cloud * Stream interactive simulations to VR headsets and browsers * Remote access to complex industrial models without local installation * Multi-user collaborative experiences * Easy distribution to customers and partners worldwide ## Innoactive Resources For more information about Innoactive, visit: * [Innoactive Official Website](https://www.innoactive.io/) - XR Streaming platform * [Innoactive Portal](https://www.innoactive.io/) - Enterprise XR CMS documentation ## Alternative VR Solutions While Innoactive documentation is being prepared, consider these VR development options: * [VR Builder](/extensions/vr-builder) - Open-source VR training creation * [Mixed Reality with Meta Quest3](/advanced-topics/mixed-reality-with-meta-quest3) - Direct Meta Quest integration * [Industrial Metaverse](https://github.com/game4automation/doc/blob/doc/extensions/realvirtual.io-industrial-metaverse) - Multi-user VR/AR solutions ## Related Publishing Options * [Windows Publishing](/basics/publishing-the-digital-twin/windows) - Standalone Windows executables * [WebGL Publishing](/basics/publishing-the-digital-twin/webgl) - Browser-based deployment * [CMC ViewR](/basics/publishing-the-digital-twin/cmc-viewr) - Advanced 3D visualization platform ## See Also * [VR Modules](/extensions/realvirtual.io-industrial-metaverse/vr-modules) - VR interaction components * [AR Modules](/extensions/realvirtual.io-industrial-metaverse/ar-modules) - Augmented reality features * [Scene Interaction](/components-and-scripts/scene-interaction) - Interactive elements © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. # Revision management Controlling your development realvirtual.io (Unity) projects can be controlled by a revision management system. A revision management system is providing several big advantages: * You always know how has changed what in your project * You can always step back to all versions of your project * You can separate developments into different branches * You can merge branches back into your main branch A revision management is very usefull when you are working on big projects with a bigger team. There are several revision management systems available which can work with Unity. For example you could work with [Subversion](https://subversion.apache.org) or [GIT](https://git-scm.com). Even if GIT is in very widely used in IT development, our experience is, that Plastic SCM is the best working revision management system. Plastic SCM was acquired by Unity some time ago and is very well integrated into Unity. On our point of view it is much easier to use than GIT.

Plastic SCM

Please check the Plastic SCM Website for more information about plastic. {% embed url="" %} {% embed url="" %} # Login & Download Updates (Pro) Customers using the **Professional version** of realvirtual can access the **User Hub**, an in-app tool to manage your license, download updates, and activate the UPM registry. The User Hub has four tabs: **News**, **Login**, **Downloads**, and **Packages**. ## Opening the User Hub Access the User Hub from the Unity main menu:\ **`Tools > realvirtual > User Hub`** Or via the realvirtual toolbar dropdown in the editor toolbar. ## Login The **Login** tab offers two login methods, selectable at the top: ### Invoice + ZIP Use this method if you purchased realvirtual directly or via the Unity Asset Store: 1. Select **Invoice + ZIP** as the login method 2. Enter your **Invoice Number** — a realvirtual invoice or Unity Asset Store invoice number 3. Enter your **Billing ZIP Code** — required for realvirtual invoices, leave empty for Unity Asset Store invoices 4. Enter your **Email** address 5. Check the **License Agreement** checkbox 6. Click **Login** ### Temporary License Key Use this method if you received a **Partner Key** (`PK-XXXX-XXXX-XXXX`) or a **Temporary Code** (`SUB-XXXX-XXXX-XXXX-XXXX`) from your sales partner or license administrator: 1. Select **Temporary License Key** as the login method 2. Enter your key or code in the **Code** field 3. Enter your **Email** address 4. Click **Login** Your license activates immediately. Keys and codes track concurrent sessions — when you close Unity, your seat is freed for others. {% hint style="info" %} Temporary codes are generated by your license administrator via the [Customer Portal](/basics/customer-portal). Partner Keys are provided by your sales partner. {% endhint %} Once logged in, the **Account Status** shows **You are logged in** in green.

User Hub — Login tab with Invoice + ZIP method

## Downloads The **Downloads** tab lists all packages available for your license. Click **Refresh** to update the list. Available packages include: * **UPM packages** (`.tgz`) — For Unity 6 projects (e.g., `io.realvirtual.professional`, `io.realvirtual.starter`) * **Legacy packages** (`.unitypackage`) — For older Unity versions * **Archived versions** — Previous releases for backward compatibility Click **Download** next to any package to download it. ### One-Click Install {% hint style="info" %} This feature was added in realvirtual **6.3.5** (Professional). {% endhint %} UPM packages (`.tgz`) additionally show an **Install** button. Click it to download the package and install it directly into the open project — no manual **Package Manager → Add package from tarball** step needed. The status line below the file list shows the download progress and the installation result. The package is installed as a local tarball in your project's `Packages` folder. If you use the UPM registry (see below), activating the registry switches the package back to registry-based updates. When installing realvirtual for the first time into a project, install `io.realvirtual.starter` before `io.realvirtual.professional`.

User Hub — Downloads tab with available packages

## Packages {% hint style="info" %} This feature was added in realvirtual **6.3**. {% endhint %} The **Packages** tab manages the realvirtual UPM scoped registry for automatic package updates. ### UPM Registry After logging in, click **Activate Registry** to configure the realvirtual scoped registry in your project. Once active, the status shows **Active** in green along with the current channel. Select a **Channel**: * **Stable** — Production-ready releases * **Beta** — Early access to upcoming features ### Installed Packages Click **Check for Updates** to see if newer versions are available on the registry. ### What's New Shows the latest package versions available on the registry. Click **Release Notes** to open the full release notes in your browser.

User Hub — Packages tab with UPM registry and channel selection

Once the registry is activated, realvirtual packages also appear in **Window > Package Manager** under "My Registries" and can be updated like any other UPM package. ### Updates Behind Corporate Proxies {% hint style="info" %} This feature was added in realvirtual **6.3.5** (Professional). {% endhint %} Some corporate networks use TLS-inspection proxies that replace server certificates with a company-internal certificate. The Unity Package Manager validates certificates against its own certificate store, so registry updates can fail with a certificate error even though the realvirtual registry certificate is valid. The User Hub handles this automatically: when a package update fails with a certificate or network error, it downloads the package directly using the operating system trust store, saves it as a tarball in your project's `Packages` folder, and installs it from there. The status line shows the download progress. No manual steps are required — just click **Update** as usual. After a fallback installation, the package is referenced as a local tarball in your `manifest.json`. As soon as the registry is reachable again (for example after your IT adds an exception), click **Activate Registry** to switch the package back to registry-based updates. For a permanent solution, ask your IT department to exclude `download.realvirtual.io` from TLS inspection — the same exception commonly configured for npm or NuGet registries. ## News The **News** tab displays release notes and information about new features for each version. It appears automatically once when you start the Unity Editor. Each release entry includes a summary of new features, improvements, and bug fixes along with a **Release Notes** button linking to the full documentation.

User Hub — News tab with release information

## See Also * [Customer Portal](/basics/customer-portal) — Web-based license management, temporary code generation, and invoice access at [download.realvirtual.io](https://download.realvirtual.io) # Customer Portal The **realvirtual Customer Portal** at [download.realvirtual.io](https://download.realvirtual.io) is the central web platform for managing your realvirtual licenses, downloading packages, generating temporary access codes for your team, and viewing invoices. ## Getting Started Open [download.realvirtual.io](https://download.realvirtual.io) in your browser. You will see two options: * **Downloads** — Download realvirtual Unity packages * **Customer Portal** — Manage licenses, codes, and invoices

Customer Portal landing page at download.realvirtual.io

## Downloads Click **Downloads** to access your available realvirtual packages. You need to log in with your invoice credentials first (Invoice Number, Billing ZIP Code, Email). {% hint style="warning" %} **First Installation?** You must download the `.tgz` package files from this page before you can install realvirtual in Unity. Download all `.tgz` files to a local folder, then import them in Unity via **Package Manager → Add package from tarball**. See [Installation](/basics/installation) for step-by-step instructions. {% endhint %} After login, you see all packages available for your license: * **UPM packages** (`.tgz`) — For Unity 6.3+ projects using the Package Manager * **Legacy packages** (`.unitypackage`) — For older Unity versions Each file shows its size and upload date. Click the download icon to download.

Downloads page showing available packages

{% hint style="info" %} Current version is **realvirtual Professional 6.3** for **Unity 6 LTS (6000.3)**, provided as UPM packages. Import them via Unity Package Manager → Add package from tarball. {% endhint %} ## Customer Portal Login Click **Customer Portal** to access license management. The portal uses passwordless **magic link** authentication: 1. Enter the **email address** from your invoice 2. Click **Request Login Link** 3. Check your email for the login link 4. Click the link to access your portal

Customer Portal login with magic link

{% hint style="warning" %} Use the email address associated with your invoice. If you are unsure which email was used, check your original purchase confirmation or contact support. {% endhint %} ## Portal Dashboard After logging in, the portal dashboard shows your complete account overview:

Customer Portal dashboard with license entitlements and code management

### Your License Entitlements The **License Entitlements** section shows all products associated with your account: * **Product name** and edition (e.g., realvirtual.io Professional 6.3) * **License type** — perpetual, subscription, or monthly * **Total licenses** and **seats** available ### CONNECT license limits realvirtual CONNECT licenses issued by the portal carry their usage limits inside the signed license token. CONNECT reads them locally — nothing about your signals or CAD files is ever sent back to the portal. | Limit | Community (free registration) | Annual / Lifetime | | -------------------------- | ----------------------------- | ----------------- | | PLC signals | 20 | Unlimited | | CAD import (STEP) per file | 25 MB | Unlimited | | CAD import (JT) per file | 12 MB | Unlimited | The CAD limits apply **per file**, so importing several files in one session is fine as long as each one is under the limit. An oversize import is rejected by CONNECT before conversion starts, not after — you never wait through a long conversion just to be turned away at the end. {% hint style="info" %} CAD import limits take effect from the CONNECT build that supports them. An older CONNECT installation accepts the same license token but does not apply the limit. Update CONNECT to see the current behaviour. {% endhint %} The JT limit is issued today but not yet applied — JT import is not available in CONNECT yet. ### Temporary Codes / Seats Temporary codes let you distribute access to your team members. The overview shows: * **Total Seats** — Your total seat pool across all products * **In Codes** — Seats currently allocated to generated codes * **Available** — Seats still available for new codes * **Active Codes** — Number of currently active codes Click **Manage Temporary Codes** to create and manage codes. ### Invoices & Billing Click **View Invoices** to see and download your invoices as PDF. ## Temporary Code Management The code management page lets you generate, track, and revoke temporary access codes for your team.

Temporary Code Management with code generation and status overview

### Generating a New Code 1. Select the **Product** from the dropdown 2. Set the number of **Seats** (how many users can use this code simultaneously) 3. Set the **Days** until expiration (max 365) 4. Optionally add a **Label** for identification (e.g., "Summer 2026" or "Team Berlin") 5. Click **Generate** The generated code will appear in the **Existing Codes** list below. ### Managing Existing Codes Each code shows: | Column | Description | | --------------- | -------------------------------------------- | | **Code** | The access code to share with users | | **Product** | Which product the code grants access to | | **Label** | Your custom label for identification | | **Nutzung** | Current usage: active sessions / total seats | | **Valid Until** | Expiration date | | **Status** | Active, Expired, or Revoked | You can **revoke** active codes by clicking the delete button. Unused seats are returned to your pool immediately. ### Using a Temporary Code Share the generated code with your team member. They enter the code in the Unity **User Hub** (`Tools > realvirtual > User Hub`) to activate their seat. See [Login & Download Updates (Pro)](/basics/login-and-download-updates-pro) for details on the Unity-side setup. ## Partner Keys If you received a **Partner Key** (in the format `PK-XXXX-XXXX-XXXX`) from your sales partner, you can use it to activate your realvirtual license directly in Unity. ### Activating a Partner Key in Unity 1. Open the Unity **User Hub** via `Tools > realvirtual > User Hub` 2. Enter the Partner Key (`PK-XXXX-XXXX-XXXX`) in the **Code** field 3. Enter your **Email** address 4. Click **Login** Your license activates immediately. You can start using realvirtual Professional right away. {% hint style="info" %} Partner Keys track concurrent sessions — when you close Unity, your seat is freed for others. If your organization also has a direct license (via invoice), the Partner Key seats are tracked separately. {% endhint %} {% hint style="warning" %} If you see a "No seats available" error, all seats on the Partner Key are currently in use. Contact your sales partner to request additional seats or wait for a seat to become available. {% endhint %} ## See Also * [Login & Download Updates (Pro)](/basics/login-and-download-updates-pro) — Managing licenses from within Unity * [Installation](/basics/installation) — Installing realvirtual packages # Realvirtual (before 2022: Game4automation) ### Introduction Every scene which is using realvirtual.io functions needs to include the *realvirtual.io* asset (before 2022 Game4automation) on the top hierarchy level of the scene. You need to keep the name and the location. If you create a new scene with the *realvirtual* menu, the *realvirtual.io a*sset is automatically included. You can also add the *realvirtual.io* asset by manually adding it to an existing scene:

The realvirtual.io Asset includes the RealvirtualController (see below) as well as a standard scene navigation, standard lights, the Runtime UI as well as a base plate.

### realvirtual.io Controller The most important part of the *realvirtual.io* Asset is the RealvirtualController Script. This asset keeps the scene settings. Most realvirtual.io objects will call this controller or get some settings from it. This is, why the RealvirtualController is a must for all scenes with realvirtual.io functions.
## General Options **Connected** Setting for defining, if the simulation is starting in “Connected” mode. If true, this will set the global connecting status to connected (see also [Connection-Status](/basics/runtime-ui#connection-status)). **Model Checker Enabled** Enables the model checking when simulation starts (see[ Model Checker](/basics/user-interface/model-checker)) **Validate Before Start** Enables pre-play validation that checks for common configuration issues before starting the simulation. When enabled, realvirtual performs automatic validation of your scene setup and displays warnings in the console for issues that should be resolved before running the simulation. **Validation On Components Added** Enables validation checks when components are added to GameObjects during Editor mode. This provides immediate feedback when adding components that might have configuration conflicts. For complete documentation of the validation system, see [Pre-Play Validation](/components-and-scripts/game4automation/pre-play-validation). **Stop Physics when Paused** Starting from release 2022.15, physics simulations do not stop when the simulation is paused in RuntimeUI. This allows you to continue navigating the scene with the mouse even while the simulation is paused. However, if you need to fully stop the simulation, including all physics calculations, you can enable the "Stop Physics When Paused" option. This will ensure that both the simulation and physics are completely paused. **Scale** Defines how many millimeters fits into one Unity Unit. If, as usual, one Unity unit is considered as one Meter, the Scale should be set to 1000. The Scale is used for all input fields of Behavior components whith distance or length properties. {% hint style="info" %} As a standard in all Behavior components the values for distances and lengths are always considered as Millimeters. {% endhint %} **Speed Override** Overrides the speed of all drives. You can slow down or speed up all drives in the scene by selecting another value for the speed override. A value of two means doubled speed. {% hint style="info" %} Please consider, that this value also influences the physical behavior of the model. For example if a Value of 10 is selected the bottles in the demo model will tumble around. {% endhint %} **Time Scale** Speeds up the simulation. This also speeds up the physics so that the simulation is just running faster but internally in the calculations running in real time. {% hint style="info" %} If the time scale is to hight it might happen that sensors are not getting active any more because the products are passing to fast the sensors. {% endhint %} **Hide Groups** Hides the defined Groups when the simulation is started. Groups can be defined manually by adding the Group component to any gameobject or - in a more comfortable way - by using the [Selection Window](/basics/user-interface/selection-window) (This is only available in Professional Version). **Restart** In certain scenarios, such as fairs or demonstration models, you may need the simulation to automatically start and stop after a specific duration. By enabling the restart function, you can set a predefined time interval for the scene to restart. This ensures that your simulation runs continuously without manual intervention, making it ideal for presentations or automated demos. **Additive Scene Loading** {% hint style="warning" %} **Deprecated since realvirtual 6.3.4.** Additive scene loading is no longer the recommended approach for structuring larger models. We recommend composing your model from **prefabs** within a single **master scene** instead. Additive scene loading remains available for backward compatibility but may be removed in a future release. {% endhint %} With realvirtual.io 2021.06, we have added support for additive scene loading. With additive scene loading, multiple individual scenes can form an entire model. More about the basics of additive scenes is described here in the Unity documentatio(). When using additive scene loading, the Game4automationController is automatically disabled in the additive scenes. All [MUs](/components-and-scripts/mu-movable-unit) created by [Soruces](/components-and-scripts/mu-movable-unit/source) are automatically created within the main scene. Within AdditiveScenes the path (Assets/….) can be defined within the Unity project to all scenes that should be loaded additively. It can be defined separately whether the scene should only be loaded in Edit Mode or also in Play Mode. ## UI Options **Hierarchy Update Cycle** Cylcle for updating the icons and signal values in the hierarchy view during runtime. **Scale Handles** The scale size of the realvirtuil.io Gizmos. **Standard Source** The standard Source that should be inserted into the model when Hotkey Source (Ins) is pressed. **Editor Gizmo Settings** The color settings for Editor Tools like[ Kinematic Tool.](/basics/user-interface/kinematic-tool-pro) **UI Enabled On Start** Enables and disables the full UI on simulation start (runtime inspector and runtime menu bar). **Runtime Inspector Enabled** Enables and disables the runtime inspector. **Object Selection Enabled** Enables the object selection and highlighning of components in the scene. See also [RuntimeUI](/basics/runtime-ui). **Hide Info Box** Hides the info box at simulation start. **Runtime Application UI** A pointer to the Application UI (menu, runtime inspector and so on). **Runtime Automation UI** A pointer to the Automation UI (the buttons and lights which are controlling the automation) ## Skin Controller The `Skin Controller` is a component of the realvirtual prefab that configures the UI settings for realvirtual.
The Skin Controller customizes button and window colors, font size, and font color. It includes two predefined settings. To create a custom definition, right-click in the project panel and select **Create > realvirtual > Create realvirtual UI Skin**.\ Within the Skin definition are several sections. Relevant for the basic in realvirtual are the marked areas in the picture below.
## Visual Settings (deprecated) {% hint style="info" %} In realvirtual.io Version 6, the management of visual settings has been updated, particularly with the new [EnvironmentController ](/components-and-scripts/game4automation/environment-controller)component. The [EnvironmentControlle](/components-and-scripts/game4automation/environment-controller)r is responsible for configuring environmental aspects such as lighting, skyboxes, and ambient settings within your digital twin projects.\\ {% endhint %} **Enable Visual Settings** If set to false the realvirtual.io controller will not change anything from its own on lightning, camera and so on so all settings below will not be applied. **Standard Base Plate And Lights** You can turn of with this the standard base plate and the lights which are included in the *game4automation* Asset. **Base Plate Dimensions** The dimensions of the base plate in meters. **Sun Light intensity** Sets the intensity of all sun lights (which are all lights market with the tag *g4a sun*) **First Light intensity** Sets the intensity of all first lights (which are all lights market with the tag *g4a firstlight*).\ This lights are usually used for the light which is lightning the scene like the big light in a building. **Second Light intensity** Sets the intensity of all second lights (which are all lights market with the tag *g4a secondlight*)\ This lights are usually used mainly for decoration purposes, like small spot lights in a building. **Quality Level** Sets the overall visual quality. This has impact on the render performance and screen update rate. Ultra is the best. Unity is very good performing so Ultra is OK for most use cases. In lower settings for example shadows and reflections are turned off. **Hierarchy Icons** Settings for the Hierarchy Icons and annotations in the Hierarchy view **Hotkeys** Hotkey settings. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Environment Controller Starting from **realvirtual.io Version 6**, the EnvironmentController leverages Unity's **Universal Rendering Pipeline (URP)** to provide enhanced visual fidelity and customization options. You can find the **EnvironmentController** in **Tools > realvirtual > Environments** as part of the **realvirtual Prefab** in your scene. *** ### Overview The EnvironmentController provides three preset visual modes: * **Default**: A balanced environment for general use. * **Dark**: Suitable for low-light or nighttime scenarios. * **White**: Ideal for bright, minimalistic environments. The component allows adjustments to floor size, fade effects, and toggling advanced features with straightforward controls.

Environment - Default Mode

Environment - Dark Mode

Environment - White Mode

*** ### Runtime Lighting (No Baking Required) {% hint style="info" %} Improved in realvirtual \*\*6.3.4\*\* (Starter & Professional) {% endhint %} The EnvironmentController computes the **skybox ambient light and environment reflection live at runtime** (using `DynamicGI.UpdateEnvironment`). This runs once when the scene starts, in both Edit and Play mode, so your scenes are correctly lit **without baking lighting**. The cost is a one-time calculation at scene start with no per-frame impact. Because the ambient and reflection are generated from the skybox at runtime, the per-scene **baked lighting folder** Unity otherwise stores next to a scene (with `LightingData.asset`, `ReflectionProbe-*.exr` and lightmaps) is **no longer required** for skybox-lit scenes. Removing it slims down your project and stops these binary files from reappearing as changes in version control after every bake. #### Removing baked lighting folders Use **Tools > realvirtual > Settings > Remove Baked Lighting Folders…** to clean up the active scene or your whole project. The tool disables Baked Global Illumination on each scene, clears the scene's Lighting Data reference, and deletes the per-scene baked lighting folder. You choose the scope in the confirmation dialog: **Active scene only** or **All scenes**. {% hint style="warning" %} This permanently deletes baked lighting data and cannot be undone except through version control. \*\*Commit or back up your project first.\*\* Scenes that rely on \*\*real baked lightmaps\*\* (baked shadows / ambient occlusion) will look different afterwards — only skybox-lit scenes are visually identical. {% endhint %} *** ### Properties **Mode** * Dropdown to select the desired environment mode: `Default`, `Dark`, or `White`. When **Advanced Mode** is enabled: * A hidden Skybox is activated, creating a more immersive environment by enhancing lighting and shadows. * A sphere is added to hide the skybox and to show a uni-color background.

Environment - Advanced Mode deactivated

Environment - Advanced Mode activated

#### Floor * **Size**: * Numeric input to specify the floor size in Meter. * **Fade**: * Checkbox to enable or disable the fading effect on the floor. *** ### Customizing the Environment The recommended way to customize the Environment Controller is by **overwriting the values of the real irtual prefab** in your scene. This approach ensures that your changes are scene-specific while maintaining compatibility with the RealVirtual framework. #### Prefab Structure Each visual setup is organized as a **sub-gameobject** within the prefab. These sub-gameobjects are activated dynamically based on the current **visual mode setting**. The three primary modes included are: * **Dark Mode** * **Default Mode** * **White Mode** Each mode contains the following key components: **1. Sun** * Represents the primary directional light source for the scene. * Customize the **intensity, color, and angle** of the light for desired effects. **2. Floor** * Defines the material and rendering properties for the ground plane. * Update the floor's texture, material properties, or color to match your scene's aesthetics. **3. Sky** * Manages the skybox or atmospheric effects. * Customize the sky material to change the overall ambiance of the environment. #### Effects and Post-Processing Under the **Effects** section of each sub-gameobject, you will find settings related to **post-processing**. These can be tailored to adjust the mood, tone, and visual clarity of the scene. Common properties include: * **Bloom**: Adjust intensity and threshold for glow effects. * **Color Grading**: Modify contrast, saturation, and color tones. * **Ambient Occlusion**: Enhance shadow details for better depth perception. * **Motion Blur**: Add a sense of motion for dynamic scenes. * **Vignette**: Focus viewer attention by darkening edges.
# Pre-Play Validation The Pre-Play Validation system automatically detects and resolves common configuration issues before simulation startup, reducing debugging time and ensuring reliable automation system behavior. ## Overview Pre-Play Validation proactively identifies potential problems in your scene configuration and either automatically fixes them or provides clear guidance for resolution. This validation system catches issues early in the development process, preventing runtime failures and unexpected behavior during virtual commissioning. Key benefits include: * **Automated Problem Detection**: Identifies configuration conflicts before they cause runtime issues * **Intelligent Auto-Fixes**: Automatically resolves common problems like conflicting component settings * **Clear Diagnostic Messages**: Provides specific, actionable feedback for manual fixes * **Development Workflow Integration**: Runs seamlessly during normal development activities * **Reduced Debugging Time**: Catches issues before they become complex runtime problems > **💡 Hint** Enable validation early in your project development to establish good configuration practices and catch issues as they develop rather than during final testing.

Enable Pre-Play Validation in RealvirtualController settings

## Quick Start ### Enable Validation (1 minute) 1. **Locate RealvirtualController** in your scene (usually on a "Controller" GameObject) 2. **Check Validation Settings** in the Inspector: * **Validate Before Start**: ✅ Enable for pre-simulation checks * **Validation On Components Added**: ✅ Enable for real-time component validation 3. **Test the System**: Start Play mode and check Unity Console for validation messages ### Understanding Validation Output Validation messages appear in Unity Console with this format: ``` [Validation] RuleName: Description of issue and action taken Context: GameObject "ObjectName" → Component type ``` ## Configuration Options ### RealvirtualController Settings **Validate Before Start** Runs comprehensive scene validation when entering Play mode. * **Type**: Boolean * **Default**: true * **Use case**: Catch configuration issues before simulation starts * **Performance**: Minimal impact on startup time **Validation On Components Added** Validates components immediately when added in Editor mode. * **Type**: Boolean * **Default**: true * **Use case**: Prevent invalid configurations during scene building * **Performance**: Real-time validation with no runtime impact ### Development Workflow Integration **Recommended Settings for Different Phases**: **Early Development**: Both validations enabled * Helps establish proper configuration patterns * Catches issues as components are added **Production/Testing**: Pre-play validation enabled, component validation optional * Ensures scene integrity before critical testing * Reduces validation interruptions during rapid development **Final Release**: Validation can be disabled for performance * Remove validation overhead in final builds * All configuration issues should be resolved by this stage

Validation warnings displayed in Unity Console

{% hint style="info" %} **Best Practice**: Keep both validations enabled during development. The system is designed to be non-intrusive while providing valuable feedback for scene configuration quality. {% endhint %} ## Validation Rules Reference The validation system includes specialized rules that target common configuration problems in industrial automation setups. ### Control System Validation #### BehaviorInterface Jogging Conflict Resolution **Problem Detected**: Drive components with both BehaviorInterface control and manual jogging enabled **Why This Matters**: * BehaviorInterface components provide programmatic drive control for automation sequences * Manual jogging controls (JogForward/JogBackward) are intended for manual testing and debugging * Having both active creates conflicting control signals and unpredictable behavior **Automatic Resolution**: * Disables `JogForward` and `JogBackward` properties on affected Drive components * Preserves BehaviorInterface control for proper automation operation * Maintains drive functionality while eliminating control conflicts **Example Scenario**: ``` Conveyor System with BehaviorInterfaceConveyor component: ✅ Before: Drive has jogging enabled + active BehaviorInterface ❌ Problem: Conflicting control signals cause erratic movement ✅ After: Jogging disabled, BehaviorInterface maintains full control ``` **Console Message**: ``` [Validation] BehaviorInterfaceJoggingRule: Disabled jogging on Drive. Active BehaviorInterface will control drive position and conflicts with manual jogging. Context: GameObject "ConveyorDrive" → Drive component ``` #### Multiple BehaviorInterface Prevention **Problem Detected**: GameObjects with multiple active BehaviorInterface components **Why This Matters**: * Each GameObject should have only one active control interface * Multiple interfaces create ambiguous control authority * Can cause timing conflicts and synchronization issues **Automatic Resolution**: * Keeps the first active BehaviorInterface component * Disables additional BehaviorInterface components * Preserves the primary control interface functionality **Example Scenario**: ``` Robot Arm with multiple control interfaces: ✅ Before: BehaviorInterfaceRobot + BehaviorInterfaceSequence both active ❌ Problem: Conflicting position commands from two controllers ✅ After: Primary interface remains active, secondary disabled ``` ### Motion System Validation #### Single Drive Component Enforcement **Problem Detected**: Multiple Drive components on the same GameObject **Why This Matters**: * Unity GameObjects support only one primary motion controller * Multiple Drive components create conflicting transform updates * Can cause jittery movement, position fighting, or complete motion failure **Immediate Resolution**: * Removes duplicate Drive components as soon as they're added * Preserves the original Drive component configuration * Triggers immediately during component addition (not just pre-play) **Prevention Strategy**: ``` Hierarchy Design: ✅ Correct: One Drive per GameObject ├── ConveyorSystem (Drive component) ├── RobotArm (Drive component) └── ElevatorPlatform (Drive component) ❌ Incorrect: Multiple Drives on same GameObject ├── ComplexMachine (Drive + Drive) ← Second Drive removed ``` #### Transport Surface Hierarchy Validation **Problem Detected**: Improper Drive-TransportSurface hierarchy configurations **Critical Physics Requirements**: * TransportSurface components need Drive control for proper operation * Unity physics constraints prevent certain Drive-TransportSurface arrangements * Missing Drive references cause non-functional conveyor systems **Validation Logic**: **✅ Valid Configurations**: * TransportSurface with explicit DriveReference assigned * TransportSurface with exactly one Drive in parent hierarchy * TransportSurface as child of Drive GameObject **❌ Invalid Configurations**: * TransportSurface without Drive and no DriveReference * TransportSurface with multiple Drives above it in hierarchy * Drive component positioned above TransportSurface violating physics **Practical Examples**: ``` ✅ Correct Hierarchy 1: Direct Reference Conveyor ├── Belt (TransportSurface + DriveReference to Drive) └── Motor (Drive component) ✅ Correct Hierarchy 2: Parent-Child Relationship ConveyorSystem (Drive component) └── Belt (TransportSurface component) ❌ Problematic Hierarchy: Missing Drive Control Conveyor └── Belt (TransportSurface only) ← No drive control ❌ Physics Violation: Drive Above TransportSurface FactoryFloor (Drive component) └── ConveyorSection (TransportSurface) ← Physics conflict ``` **Console Messages**: ``` [Validation] TransportSurfaceDriveHierarchyRule: TransportSurface requires a Drive component in the hierarchy to function properly. Please add a Drive component or assign DriveReference. Context: GameObject "ConveyorBelt" → TransportSurface component ``` ## Validation Triggers ### Pre-Play Validation Automatically runs when entering Play mode (if enabled): * **BehaviorInterface Jogging Conflicts**: Drive components with conflicting control methods * **Multiple BehaviorInterface Detection**: GameObjects with multiple active interfaces * **TransportSurface Hierarchy**: Drive-TransportSurface relationship validation ### Component Addition Validation Runs immediately when components are added in Editor: * **Multiple Drive Prevention**: Blocks duplicate Drive components on same GameObject ## Practical Usage Examples ### Common Development Scenarios #### Scenario 1: Building a Conveyor System **Step-by-step with Validation Feedback**: 1. **Create Conveyor GameObject**: ``` Hierarchy: ConveyorSystem ``` 2. **Add Drive Component**: ``` ✓ Drive added successfully ``` 3. **Add Second Drive (Mistake)**: ``` ⚠ [Validation] PreventMultipleDrivesRule: Only one Drive component allowed per GameObject. Removing duplicate Drive component. ✓ System prevents configuration error ``` 4. **Add TransportSurface**: ``` ConveyorSystem (Drive) └── Belt (TransportSurface) ✓ Hierarchy validated - proper Drive-TransportSurface relationship ``` #### Scenario 2: Robot Arm with Automation Control **Development Progression**: 1. **Initial Setup**: ``` RobotArm (Drive + manual jogging enabled) ✓ Manual testing configuration ``` 2. **Add Automation Control**: ``` RobotArm (Drive + BehaviorInterfaceRobot + jogging enabled) ⚠ [Validation] BehaviorInterfaceJoggingRule: Disabled jogging on Drive. Active BehaviorInterface will control drive position. ✓ System resolves control conflict automatically ``` 3. **Final Configuration**: ``` RobotArm (Drive + BehaviorInterfaceRobot) ✓ Ready for automated operation ``` ### Manual Validation Control #### Runtime Control ```csharp // Dynamic validation control during development public class ValidationController : MonoBehaviour { public RealvirtualController realvirtualController; public void EnableValidation() { realvirtualController.ValidateBeforeStart = true; Debug.Log("Validation enabled for next Play mode start"); } public void DisableValidationTemporarily() { realvirtualController.ValidateBeforeStart = false; Debug.Log("Validation temporarily disabled"); } public void RunManualValidation() { if (realvirtualController != null) { realvirtualController.RunValidation(); } } } ``` #### Editor Integration ```csharp // Custom editor integration for validation [CustomEditor(typeof(RealvirtualController))] public class RealvirtualControllerEditor : Editor { public override void OnInspectorGUI() { DrawDefaultInspector(); EditorGUILayout.Space(); EditorGUILayout.LabelField("Validation Tools", EditorStyles.boldLabel); if (GUILayout.Button("Run Validation Now")) { ((RealvirtualController)target).RunValidation(); } if (GUILayout.Button("Reset Validation Settings")) { ((RealvirtualController)target).ValidateBeforeStart = true; ((RealvirtualController)target).ValidationOnComponentsAdded = true; } } } ``` ### Custom Validation Rules #### Extending the Validation System The validation system supports custom rules for project-specific requirements: ```csharp // Custom validation rule example public class CustomComponentValidationRule : PrePlayRule { public override string RuleName => "CustomComponentValidationRule"; protected override bool IsValid(CustomComponent component) { // Custom validation logic return component.RequiredReference != null; } protected override void FixComponent(CustomComponent component) { // Automatic fix if possible if (component.RequiredReference == null) { component.RequiredReference = component.GetComponent(); } } protected override string GetWarningMessage(CustomComponent component) { return "CustomComponent requires a valid reference for proper operation."; } } ``` ## Troubleshooting ### Validation Not Running **Symptoms**: No validation messages appear in Unity Console when starting Play mode or adding components **Diagnostic Steps**: 1. **Verify RealvirtualController Configuration**: ```csharp // Check controller setup var controller = FindObjectOfType(); if (controller == null) { Debug.LogError("RealvirtualController not found in scene"); } else { Debug.Log($"Validation enabled: {controller.ValidateBeforeStart}"); } ``` 2. **Check Console Filter Settings**: * Ensure Unity Console shows "Info" level messages * Look for "\[Validation]" prefix in console messages * Check Console collapse setting doesn't hide validation messages 3. **Verify Component Targets**: * Validation only runs on components with active validation rules * Test with known validation scenarios (add second Drive component) **Common Solutions**: * Enable "Validate Before Start" in RealvirtualController Inspector * Ensure RealvirtualController GameObject is active in scene * Check that validation target components exist in scene ### Understanding Validation Messages **Message Format Analysis**: ``` [Validation] RuleName: Action taken and reason Context: GameObject "Name" → Component Type ``` **Example Interpretation**: ``` [Validation] BehaviorInterfaceJoggingRule: Disabled jogging on Drive. Active BehaviorInterface will control drive position and conflicts with manual jogging. Context: GameObject "ConveyorDrive" → Drive component Translation: - Rule: BehaviorInterface jogging conflict detection - Action: Automatically disabled jogging properties - Reason: Prevent control conflicts - Location: ConveyorDrive GameObject's Drive component ``` ### Validation Conflicts and False Positives **When Validation Seems Wrong**: 1. **Understand the Rule Logic**: * Review rule documentation to understand why it triggered * Consider if your configuration follows realvirtual best practices * Check if special use case requires different approach 2. **Legitimate Special Cases**: ```csharp // Temporary validation disable for special configurations public class SpecialCaseController : MonoBehaviour { void Start() { var controller = FindObjectOfType(); if (controller != null) { // Disable for specific scenario controller.ValidateBeforeStart = false; Debug.Log("Validation disabled for special case scenario"); } } } ``` 3. **Configuration Review**: * Verify component hierarchy matches realvirtual patterns * Check component references and dependencies * Consider refactoring to standard configurations ### Performance and Integration Issues **Editor Performance Impact**: **Symptoms**: Noticeable delays when adding components or starting Play mode **Optimization Approaches**: * Disable component addition validation during rapid prototyping * Use pre-play validation only for final testing phases * Consider scene complexity and number of validation targets **Multi-Scene Validation Issues**: **Symptoms**: Validation inconsistencies across different scenes **Solutions**: * Ensure each scene has its own RealvirtualController * Validate scene-specific component configurations * Use prefabs for consistent validation setups across scenes ## See Also * [RealvirtualController](https://github.com/game4automation/doc/blob/doc/components-and-scripts/basics/realvirtual-controller.md) - Main controller component configuration * [Drive Component](/components-and-scripts/motion/drive) - Core motion component affected by validation * [BehaviorInterface](https://github.com/game4automation/doc/blob/doc/components-and-scripts/behavior-interfaces/README.md) - Automation control components * [TransportSurface](/components-and-scripts/motion/transportsurface) - Conveyor system components * [Development Best Practices](https://github.com/game4automation/doc/blob/doc/components-and-scripts/advanced-topics/best-practices.md) - Scene configuration guidelines *** © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # MU, Source and Sink (Movable Unit) Movable Units (MUs) are objects that move freely around in the scene. They can be picked or loaded and they can be placed on Transport Surfaces.[ MUs](https://game4automation.com/documentation/current/mu.html) are created by a [Source](/components-and-scripts/mu-movable-unit/source) and deleted by a [Sink](/components-and-scripts/mu-movable-unit/sink). The MU script is automatically attached to all objects created by a [Source](/components-and-scripts/mu-movable-unit/source). As a user, you don’t need to interact with the MU script at all, except when the script itself publishes information or requests some input. This is the Inspector Window for an MU script:
### Properties **ID, GlobalID (Readonly)** Each MU automatically receives a global ID (this is globally unique) and a source ID (this is only unique to the Source). **MU Appearance** List of differnt MU appearances, used by the [Part Changer](/components-and-scripts/changing-mus/partchanger). **Fixed By (Readonly)** Fixer/Gripper which is currently fixing the MU. **Last Fixed By (Readonly)** Fixer/Gripper which has been fixing the MU last time. **Loaded On (Readonly)** MU where this MU is loaded on. **Standard Parent (Readonly)** Parent Gameobject before MU has been loaded. **Parent before Fix (Readonly)** Parent Gameobject before MU has been Gripped / Fixed. **Collided with Sensors (Readonly)** Current Sensors which are colliding with this MU. **Loaded MUs (Readonly)** Current loaded MUs on this MU. **Surface Align Smoothment** Smoothment parameter for aligning MU with Transport Surface - only used by realvirtual.io Simulation. **Unfix Speed Interpolate** Normally, if a Gripper is opening, an MU will directly fall down without a horizontal movement, even if the Gripper has a speed when opening. With this speed interpolate, the speed of movement before opening the Gripper is interpolated and transfered to the MU when opening the Gripper. With this it is possible to “throw” objects. ### Events Events can be used if your are programming your own scripts and you want to be notified about certain events. **Event MU Deleted** Event when the MU is going to be deleted. **Event MU Is Loaded** Event when the MU is loaded on another MU. **Event MU Gets Load** Event when an MU is loaded on this MU. **Event MU Sensor** Event if the MU is colliding with a Sensor. \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Source
By using a Source script, new movable units [(MUs)](/components-and-scripts/mu-movable-unit) can be generated. MUs can be generated in intervals or automatically generated once the last generated [MU](/components-and-scripts/mu-movable-unit) has travelled a certain distance away from the source. This is useful to automatically generate[ MUs](/components-and-scripts/mu-movable-unit) on a conveyor. The object with the Source script attached to, is like a template. Each time a [MU](/components-and-scripts/mu-movable-unit) is created, the Source creates a new instance of the object under the defined root `Destination` in the scene hierarchy. This tutorial shows how to create a custom source: {% embed url="" %} Tutorial custom sources {% endembed %} The source can also manually create [(MUs)](/components-and-scripts/mu-movable-unit) when you press "C". The source will delete all generated [(MUs)](/components-and-scripts/mu-movable-unit) when you press "D" on the keyboard. This is the property window of the source:
### Properties #### This Object as MU Defines which part should be generated. Should normally point to the same GameObject where the source component itself is attached to. This is also the standard setting. **Note:** Collider enabled/disabled states are preserved from this template when generating MUs. To disable specific colliders on generated MUs, simply disable them in the template prefab before starting the simulation. #### Destination When the source is generating a new MU it can be placed as a sub Gameobject under the defined Destination Gameobject. #### Enabled Must be set to true for the source to work. #### Freeze Source Position Should be usually set to true - the source will not change its position. #### Don’t Visualize Hides the source so that only the created MUs are visible. #### Mass Sets the Mass of the created MUs. #### Set Center of Mass Sets the Center of Mass of the created MUs. #### Center of Mass The Center of Mass. #### Generate on Layer Unity Layer where the MU should be placed to after creation. #### On Create Destroy Components Maybe some scripts on the MU, which is a copy of the source, should be destroyed when the MU is created. You can define here the components to be destroyed. #### Create in Interval Creates MUs in a constant interval in seconds. If the value is 0 this option is not used. #### Automatic Generate On Distance Automatically creates new MUs when the distance of the last created MU is greater than the defined value. Optionally the distance can be also randomly (equally distributed) between the defined Distance (“Generate if Distance”) plus / minus the “Range Distance”. #### Number of MUs Limits the number of generated MUs. #### SourceIOs Gernarate MU - should be turned on for making the source work. #### Source Signals PLCOutputBool Signal (e.g. from a PLC) for generating MUs. #### Events Unity Event which can be used for custom scripts which are called when an MU is created. ### Template Behavior The Source GameObject acts as a non-physical template during simulation: **Collider Handling:** * All colliders on the template are automatically disabled when the simulation starts * The initial enabled/disabled state of each collider is preserved from your prefab configuration * When MUs are generated, each collider's original state is restored * This includes colliders on inactive child GameObjects **Practical Use:** * To have a collider disabled on generated MUs, simply disable it in the template prefab before simulation starts * To have a collider enabled on generated MUs, ensure it's enabled in the template prefab * Inactive child GameObjects maintain their hierarchy state and collider configurations **Visibility:** * The template's visual representation can be hidden using the **Don't Visualize** property * Even when hidden, the template remains in the scene as the blueprint for MU generation **Physics:** * The template does not participate in physics simulation * Generated MUs have full physics interaction (collisions, rigidbodies, etc.) * Use **Freeze Source Position** to prevent the template from moving #### Public Interfaces If script is attached to the Gameobject of the MU, which implements the Interface “ISourceCreated” a Method “OnSourceCreated” is called on the MU when it has been created by the MU. #### Public properties and methods Please check the [Realvirtual.io Class Reference](https://realvirtual.io/apidoc/classrealvirtual_1_1_source.html) for more information about the properties and methods of this component. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Sink A Sink is responsible for deleting [MUs](/components-and-scripts/mu-movable-unit). Using a Box Collider, the Sink deletes all colliding ([MUs](/components-and-scripts/mu-movable-unit)):
If needed, the Sink can be controlled by a Signal *Delete*. This will activate and deactivate the Sink. The same can be done with the setting *Delete Mus*. If you define a Tag under *Delete Only Tag* only [MUs](/components-and-scripts/mu-movable-unit) with the specific Tag will be deleted. > Please take care that the Sink is situated on the correct layer, to enable collision detection. Usually the sink should be placed on the rvSensor Layer (before 2022 g4aSensor Layer). Please check the [Realvirtual.io Class Reference](https://realvirtual.io/apidoc/classrealvirtual_1_1_sink.html) for more information about the properties and methods of this component. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher.\\ # Motion and Kinematic Motion axes are modeled by connecting [Drives](/components-and-scripts/motion/drive) to GameObjects. The [Drive](/components-and-scripts/motion/drive) will move the GameObject, including its sub-components, along a defined rotational or linear axis. The [Drive](/components-and-scripts/motion/drive) is a base component with some generic [Drive](/components-and-scripts/motion/drive) behavior but it does not expose a Signal interfaces to a PLC. For this a [Drive Behavior](/components-and-scripts/motion/drive-behavior) script is added in addition to the [Drive](/components-and-scripts/motion/drive) script for the GameObject. The [Drive Behavior](/components-and-scripts/motion/drive-behavior) includes special behaviors (such as pneumatic cylinders or position controlled drives) including any signals supporting the special behavior. {% hint style="info" %} The standard units for drive positions in all realvirtual.io components are millimeters for linear drives and degrees for rotational drives. The standard units for speeds are millimeters per second and degrees per second. In Unity, each millimeter is represented as one Unity unit (which means what you see in the Transform component in Unity is in meters). You can adjust the scale in **realvirtualController**, but this is generally not recommended. {% endhint %} ## Choosing a Motion Approach realvirtual offers several complementary ways to move geometry. Pick the one that matches how your mechanism is built: * [**Drive**](/components-and-scripts/motion/drive) **+ hierarchy** — the standard, and the right choice for the vast majority of axes. A Drive moves a GameObject and all its children along one linear or rotational axis. Chain Drives through the Transform hierarchy to build serial kinematics (a stacked XYZ gantry, a conveyor, a simple robot wrist). Add a [Drive Behavior](/components-and-scripts/motion/drive-behavior) for PLC signals and special behaviors (pneumatic cylinders, position control). * [**Kinematic Joints**](/components-and-scripts/motion/kinematic-joints) ***(Professional)*** — a position-based constraint solver for **closed kinematic chains** that a parent/child hierarchy cannot express, because one link has to satisfy more than one constraint at once. Use it for Delta robots, four-bar linkages, scissor lifts and parallel grippers. Drives still drive the active joints; the solver positions every passive link each FixedUpdate, without physics, jitter or drift. Its `KinematicTarget` companion adds inverse (Cartesian-target) control to the same mechanism. Runs in a native, multi-threaded solver that scales to hundreds of mechanisms. * [**Joint**](/components-and-scripts/motion/joint) — a PhysX-based joint. Physics joints are force-driven and iterative, so they tend to **jitter, sag and drift**: a closed loop never settles perfectly, springs and dampers have to be tuned, and the same input can give slightly different results from run to run. Use PhysX joints only when you genuinely want dynamic behaviour (falling parts, collisions, compliance) — not when you need an exact, repeatable mechanism pose. * [**Kinematic**](/components-and-scripts/motion/kinematic) — a CAD import helper that groups parts and corrects pivots; despite the similar name it is unrelated to Kinematic Joints. * **Robot IK *****(Professional)*** — dedicated inverse kinematics for standard serial 6-axis and collaborative robots, with path planning and blending (see [Robot Inverse Kinematics](/components-and-scripts/robot-inverse-kinematics)). {% hint style="success" %} **Accuracy over physics for mechanisms.** For any mechanism where the pose has to be *correct* — a Delta robot picking to an exact point, a linkage indexing to a fixed stop, a gripper closing to a precise width — prefer [**Kinematic Joints**](/components-and-scripts/motion/kinematic-joints) over PhysX joints. The constraint solver satisfies the geometry exactly every FixedUpdate with no jitter, no drift and fully deterministic, repeatable results, while a physics joint only ever approximates the constraint and needs tuning to stay stable. In realvirtual, physics is mainly used for the **parts (MUs) themselves** — parts falling, colliding, singulating and accumulating on [transport surfaces](/components-and-scripts/motion/transportsurface), in chutes and in bins — where the dynamic, force-driven behaviour is exactly what you want. Use physics for the material flow; use Drives and Kinematic Joints for the machine's own moving structure. {% endhint %} The rest of this page focuses on the standard [Drive](/components-and-scripts/motion/drive). This Youtube tutorial shows how to define [Drives](/components-and-scripts/motion/drive) {% embed url="" %} Tutorial Adding Drives {% endembed %} > We supply seveal standard Behavior models, but due to the large variety of automation devices and functionality, it is most likely you will need to add your own behavior models. The next image gives a good overview of [Drives](/components-and-scripts/motion/drive) moving GameObjects. The [Drive](/components-and-scripts/motion/drive) is contolled by a special Drive Behavior which is connected to one or more Signals. The Signals are then connected to a PLC (using an [Automation Interface](https://game4automation.com/documentation/current/interface.html))
© 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Drive **Drives** control the movement of GameObjects along a defined axis. They are used for any moving component in the scene—except for freely moving [MUs](/components-and-scripts/mu-movable-unit) (Movable Units), which are handled differently. A Drive itself does *not* provide signal interfaces for PLC communication. To enable PLC interaction, you must attach a [**DriveBehavior**](/components-and-scripts/motion/drive-behavior) component to the same GameObject that contains the Drive script. This separates the motion logic from the signal interface logic, keeping the system modular and flexible. > **💡 Hint**\ > The Drive direction for a **linear axis** is always defined based on the **local coordinate system** of the GameObject the Drive is attached to.\ > For a **rotational axis**, the **origin of the local coordinate system** acts as the center of rotation, and the object rotates around the defined axis.\ > A Drive can also be connected to a **Transport Surface**—in this case, only **MUs on the Transport Surface** will be moved by the Drive. > **💡 Hint**\ > The standard units for Drive positions in all **realvirtual** components are:\ > • **Millimeters** for linear Drives\ > • **Degrees** for rotational Drives > > Corresponding speed units are:\ > • **Millimeters per second** for linear movement\ > • **Degrees per second** for rotation > > In Unity, **1 millimeter equals 1 Unity unit**, meaning that **1 meter = 1000 Unity units** in realvirtual.\ > While you can change this scaling in the [realvirtualController](/components-and-scripts/game4automation), doing so is **not recommended**, as it may lead to inconsistencies in physics and interaction. {% embed url="" %} Youtube tutorial about creating a first model and adding drives {% endembed %} This picture shows how two drives are connected to the axis of the handling system in the [Demo Model](/basics/demo-model):

Drives in the Demo model

In the demo cell, **Drives** are responsible for moving the different parts of the CNC machine. The motion structure is defined by the **parent-child hierarchy** of GameObjects in Unity, which establishes the **kinematic chain** of the machine. > **💡 Hint**\ > If the imported CAD data does not match the required **kinematic hierarchy**, you can use the **Kinematic** component to define a **separate motion hierarchy** that references the original CAD parts.\ > This allows you to build a clean and functional motion structure without modifying the original CAD GameObject hierarchy. The **Drive component** in the Unity Inspector includes several properties that control motion behavior and configuration. These properties are explained in detail below.

Drive Inspector

## Drive handles in editor mode ### Modern Drive Gizmos (Updated in 6.0.3) When you select a Drive in the Unity Editor, enhanced visual handles and real-time feedback are displayed to help you configure and monitor drive behavior:
Modern Drive Handles and Gizmos

Modern Drive gizmos showing rotational handles, real-time position (137.2°), and speed display (26.5°/s)

### Interactive Handle Features #### Visual Elements * **Blue Circular Handle**: Interactive rotation control for rotational drives * **Green/Yellow Directional Arrows**: Show drive direction and movement indicators * **Real-time Position Display**: Shows current drive position (e.g., "137.2°" for rotational drives) * **Speed Indicator**: Displays current movement speed (e.g., "26.5°/s") #### Handle Interaction * **Direction Control**: Click directional arrows to change drive axis direction * **Visual Feedback**: Current direction highlighted with distinct colors * **Real-time Updates**: Position and speed values update continuously during movement * **Precision Control**: Interactive handles allow precise drive configuration ### Changing Drive Directions #### Visual Direction Selection * **Active Direction**: Currently selected axis shown with prominent visual indicators * **Alternative Directions**: Other available axes shown in secondary colors * **Direction Inversion**: Click the current direction arrow to invert positive/negative orientation * **Axis Switching**: Click alternative direction arrows to change drive axis ### Linear Drive Handles For linear drives, the modern gizmo system displays directional arrows for all three axes:
Linear Drive Handles

Linear drive handles showing X (red), Y (green), and Z (blue) directional arrows for precise axis selection

#### Linear Drive Features * **Color-Coded Axes**: Red (X), Green (Y), Blue (Z) following Unity's standard color scheme * **Direction Arrows**: Clear visual indicators for each possible movement direction * **Axis Selection**: Click any arrow to set the drive's primary movement axis * **Visual Clarity**: Clean, modern appearance integrated with Unity's gizmo system #### Gizmo Visibility Settings Drive handles are only displayed if the **Drive Gizmo** is enabled in Unity's gizmo settings. You can control gizmo visibility through Unity's Preferences:
Drive Gizmo Settings

Unity Preferences showing Drive gizmo visibility controls in the Scripts section

**Gizmo Controls:** * **Drive Gizmo Toggle**: Enable/disable drive handle visibility globally * **Icon Display**: Show/hide drive component icons in Scene view * **Recently Changed**: Quick access to recently modified gizmo settings * **Per-Component Control**: Individual visibility settings for different drive types {% hint style="info" %} Alternatively you can change the drive directions with hotkeys. By pressing on **SPACE** you invert the direction of the currently selected Drive.\ By pressing **TAB** you iterate through all 6 possible directions (3 linear and 3 rotational). {% endhint %} ### Drive limits You can define upper and lower limits for drives. These limits are only used when driving the drive with the **Jog Forward** and **Jog Backward** signals. The modern limit display shows precise values and visual indicators:
Modern Drive Limits Display

Modern drive limits showing lower limit (-500 mm) and upper limit (1000 mm) with directional handles

#### Modern Limit Display Features * **Precise Value Display**: Shows exact limit values (e.g., "-500 mm" for lower, "1000 mm" for upper) * **Visual Range Indicators**: Clear visual representation of the allowable movement range * **Integration with Handles**: Limit display works seamlessly with directional handle system * **Real-time Updates**: Limit values update immediately when changed in the Inspector #### Limit Behavior For linear axes, the limits define the exact positions where the drive will stop when using jog commands. The drive can only move within the defined range between the lower and upper limits. For rotational axes, the limit is displayed by a trimmed circle. The drive can only rotate in the white area. #### Practical Usage Example When setting up a linear conveyor, you might configure: * **Lower Limit**: 0 mm (start position) * **Upper Limit**: 2000 mm (end of conveyor) This prevents the drive from moving beyond the physical conveyor length during jog operations. > **💡 Hint**\ > Avoid using **position limits** on Drives that are connected to a **motion or robot controller**.\ > These controllers usually handle motion constraints internally. Enabling limits in this case might **hide incorrect target positions**, making it harder to detect configuration or control errors. ## Troubleshooting ### Drive Not Moving * **Check Active Setting**: Ensure "Active" is set to "Always" or appropriate condition * **Verify Target Speed**: Confirm Target Speed > 0 for movement * **Limit Conflicts**: Check if limits are preventing movement * **Drive Behavior**: Ensure proper DriveBehavior is attached for PLC control ### Jerky or Erratic Motion * **Enable Acceleration**: Turn on "Use Acceleration" for smoother starts/stops * **Acceleration Values**: Set appropriate acceleration values (typically 10-50% of target speed) * **Speed Override**: Check if global speed override is affecting motion * **Physics Issues**: Verify proper collision detection and Rigidbody settings ### Performance Issues * **Multiple Drives**: For many drives, consider using Drive Behaviors for optimized control * **Complex Hierarchies**: Use Kinematic component for complex motion chains * **Update Frequency**: Check FixedUpdate frequency for smooth motion > ⚠️ **Attention**\ > **Jogging with acceleration** and **Drive limits** is currently **not supported**.\ > If you enable both features, the Drive behavior may not function as expected. ## Drive handles in simulation mode During Play Mode, drive handles provide real-time monitoring and manual control capabilities. The modern interface displays live position and speed information directly in the Scene view:
Drive Handles in Simulation Mode

Drive handles during simulation showing real-time position (-327.8 mm), speed (620.0 mm/s), and QuickEdit integration

### Real-Time Display Features * **Live Position Display**: Shows current drive position floating near the drive (e.g., "-327.8 mm") * **Speed Monitoring**: Displays current movement speed (e.g., "620.0 mm/s") during motion * **QuickEdit Integration**: Drive selection and control through the realvirtual QuickEdit panel * **Visual Feedback**: Clear identification of active drives with highlighted information ### Manual Control During Simulation * **Direction Control**: Cannot change drive directions (set in Edit Mode) * **Jog Mode**: Use QuickEdit controls or handles to manually jog drives * **Limit Respect**: Manual jogging respects defined drive limits * **Real-time Updates**: Position and speed values update continuously ### Alternative Control Methods **Keyboard Shortcuts:** * **Key 1**: Move drive in negative direction * **Key 3**: Move drive in positive direction **QuickEdit Panel:** * **Back/Forward buttons**: Manual jog control for selected drive * **Target Speed**: Adjust movement speed in real-time * **Drive Selection**: Shows active drive name (e.g., "GantryZ") ### Rotational Drive Simulation For rotational drives, the simulation interface provides specialized circular gizmos and angular position display:
Rotational Drive in Simulation Mode

Rotational drive during simulation showing circular rotation gizmo, real-time angle display (0.0°), and Axis1 drive control

**Rotational Features:** * **Circular Rotation Gizmo**: Blue circular handle indicating rotation axis and range * **Angular Position Display**: Real-time angle shown in degrees (e.g., "0.0°") * **Direction Indicators**: Color-coded arrows showing rotation directions * **Axis Identification**: Drive name displayed in QuickEdit (e.g., "Axis1") * **Precise Control**: Manual rotation control through handles or QuickEdit interface ## Drives and Unity Physics By default, **linear** and **rotational Drives** operate **without using Unity's PhysX Rigidbody system**. This approach is generally **more stable and predictable**, especially for automation and simulation scenarios. In some cases, however—such as when interacting with physical objects or colliders—it may be necessary to move the **Rigidbody** component directly. To do this, you must enable the **"Move This Rigid Body"** option in the Drive component. > **💡 Hint**\ > Only enable **"Move This Rigid Body"** if you explicitly need Drive motion to affect Unity physics.\ > In most use cases, this setting should remain **disabled** to ensure optimal simulation stability and performance.
## Drive properties ### Settings * **Active**: Defines whether the Drive is active. Usually this should be set to Always. For more information please check **ConnectionStatus** in [Runtime UI](/basics/runtime-ui) * **Direction**: Selects the movement axis. Choose from linear (`X`, `Y`, `Z`) or rotational (`Rotation X`, `Rotation Y`, `Rotation Z`). Movement is always defined in the local coordinate system. * **Reverse Direction**: Inverts the movement direction along the selected axis. * **Offset**: Applies an offset to the Drive's position. This value is **added to the internal position** during simulation.\ For example, if the `Offset` is set to **100** and the `Current Position` is **50**, the resulting position in the simulation is **150**.\ This is useful when aligning Drive values with external systems, such as PLCs, where a consistent value shift is required for coordination. * **Start Position**: The Drive's starting position when the scene starts or the Drive is reset. * **Speed Override**: Multiplies the base speed to dynamically adjust how fast the Drive moves. * **Speed Scale Transport Surface**: Scales the speed if connected to a Transport Surface (default: 1). * **Move This Rigid Body**: Enables the Drive to move the attached Rigidbody (not recommended unless Unity physics interaction is required). * **Transport Surfaces**: Allows linking [Transport Surfaces](/components-and-scripts/motion/transportsurface) to the Drive. Only [MUs](/components-and-scripts/mu-movable-unit) on linked surfaces are moved. ### Drive IOs The **Drive IOs** section contains input and output fields that allow you to interact with the Drive during simulation. * **Jog Forward**\ Boolean input to jog the Drive forward as long as the signal is active.\ Uses the set **Target Speed** without acceleration smoothing. * **Jog Backward**\ Boolean input to jog the Drive in the opposite direction.\ Also uses **Target Speed** and ignores acceleration settings. * **Target Position**\ A numeric input defining the desired position (in millimeters or degrees) that the Drive should move to.\ Can be controlled via script or PLC. * **Target Speed**\ Defines the maximum speed the Drive can reach when moving toward the **Target Position**.\ Value is in mm/s (for linear) or deg/s (for rotational). * **Target Start Move**\ Boolean input signal to start the move toward the **Target Position** using the defined **Target Speed**.\ Only starts the motion; does not affect target value. * **Reset Drive**\ Resets the Drive position to the configured **Start Position**.\ Can be triggered manually or via a PLC signal. * **Stop Drive**\ Immediately stops the Drive's motion, overriding current target or jogging input. * **Is At Upper Limit**\ Boolean output indicating whether the Drive has reached its defined **Upper Limit** (if limits are enabled). > **💡 Hint**\ > The **Drive IOs** can be accessed and controlled via **custom scripts**, making them flexible for user-defined behaviors.\ > In most cases, they are used by [**Behavior components**](/components-and-scripts/motion/drive-behavior) which handle the connection between the Drive and external systems such as **PLC signals**.\ > This setup separates physical motion from control logic, allowing clean integration with automation environments. ### Limits The **Limits** section allows you to define positional constraints for the Drive. These are useful for preventing movements beyond mechanical boundaries or for guiding logic in manual or automated scenarios. * **Use Limits**\ Enables or disables the use of movement boundaries. When enabled, the Drive will be restricted to the range defined by the **Lower Limit** and **Upper Limit**. * **Lower Limit / Upper Limit**\ Define the minimum and maximum allowed positions for the Drive.\ Values are in millimeters (for linear Drives) or degrees (for rotational Drives). * **Jump to Lower Limit on Upper Limit**\ If enabled, once the Drive reaches the **Upper Limit**, it immediately jumps to the **Lower Limit** and continues motion.\ This is useful for circular or rotary indexing systems, e.g., turntables. * **Limit Ray Cast**\ Optional field for assigning a **sensor GameObject** (typically a virtual proximity sensor).\ This allows detection of the limit not only by position but also via **raycast-based sensor feedback**. > **💡 Hint**\ > Avoid enabling **Limits** when the Drive is controlled by an external **motion or robot controller**.\ > The controller may send positions outside the defined range, and the limits could silently clip or block the motion—making it harder to detect misconfiguration or errors. ### Acceleration The **Acceleration** section allows you to simulate smooth motion profiles by controlling how the Drive accelerates and decelerates. * **Use Acceleration**\ Enables acceleration-based motion. When disabled, the Drive moves at constant speed directly toward the target. * **Smooth Acceleration (only Professional Version)**\ Activates smoothing of acceleration and deceleration using a jerk-controlled motion profile.\ This results in more realistic movement, particularly for robotics and high-speed systems. * **Acceleration**\ Maximum allowed acceleration in mm/s² (linear) or deg/s² (rotational).\ This value defines how quickly the Drive can ramp up or down in speed. * **Jerk (only Professional Version)**\ Maximum rate of change in acceleration (mm/s³ or deg/s³).\ Helps to create **soft starts and stops** by avoiding abrupt changes in force or torque. > **💡 Hint**\ > Avoid using acceleration together with **Jogging**, as they are not compatible. ### Smooth Motion (only Professional Version) The **Smooth Motion** section is available exclusively in the **Professional edition** of realvirtual.io. It provides detailed visualization and control of the motion profile calculated for the Drive based on the configured **Acceleration** and **Jerk** settings.

Smooth Motion Inspector properties

Smooth motion - velocity detail view

**Profile** This subsection visualizes the generated motion curves for the current move: * **Position** – The Drive's motion over time. * **Velocity** – The rate of change of position. * **Acceleration** – The rate of change of velocity. * **Jerk** – The rate of change of acceleration. * **Duration** – Total time (in seconds) required to complete the current motion based on the active profile. These curves are generated in real time and give insights into how the Drive will behave during its movement. 🔗 For more information about **jerk** in physics, see: **State** * **Position / Velocity / Acceleration** – The current state of the Drive in simulation time. **Target State** * **Position / Velocity / Acceleration** – The values the Drive is targeting. These update based on user input or external control signals. ### Drive Status The **Drive Status** section provides real-time diagnostic information about the current motion and condition of the Drive. These values are continuously updated during simulation and are useful for debugging, monitoring, and interfacing with automation systems. **Fields** * **Current Speed**\ Displays the Drive's current speed in mm/s (linear) or deg/s (rotational). * **Current Position**\ The current absolute position of the Drive, including offset and any external overrides. * **Position Overwrite Value**\ Shows a temporary value applied when overriding the position manually or via external control logic. * **Is Position**\ Displays the final calculated position of the Drive after applying offset and override. This is the effective position used in simulation. * **Is Stopped**\ True if the Drive is currently not moving and not jogging. * **Is Running**\ True while the Drive is in motion, either toward a target position or while jogging. * **Is At Target Speed**\ Indicates whether the Drive has reached the defined **Target Speed**. * **Is At Target**\ True when the current position equals (within tolerance) the **Target Position**. * **Is At Lower Limit**\ True when the Drive has reached or exceeded the defined **Lower Limit** (if limits are enabled). * **Is Sub Drive**\ Marks whether this Drive is being controlled as a sub-drive in a more complex motion chain (e.g., a multi-axis system). ### Drive Events The **Drive Events** section provides Unity Events that are triggered at specific points during the Drive's simulation cycle. These are intended for **expert users** who want to attach **custom logic** directly to the Drive's behavior. **Available Events** * **On Before Drive Calculation (Drive)**\ Called **before** the Drive calculates its movement each frame.\ This is useful for injecting custom control logic or modifying inputs before the Drive updates. * **On After Drive Calculation (Drive)**\ Called **after** the Drive completes its motion logic for the frame.\ Useful for monitoring state, triggering custom events, or applying additional logic. > **💡 Hint**\ > **Drive Events** are intended for advanced users who need **low-level access** to the Drive's behavior.\ > For typical applications and PLC connections, it is recommended to use **Behavior components** such as `DriveBehavior`. > 🔗 For more information about the Drive update cycle, please refer to **Section: Motion for Developers** in this documentation. Please check the [Realvirtual.io Class Reference](https://realvirtual.io/apidoc/classrealvirtual_1_1_drive.html) for more information about the properties and methods of this component. \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Drive behavior The Drive Behavior provides a detailed behavior to a [Drive](/components-and-scripts/motion/drive). This gives the flexibility to model all variety of ways to move objects. In realvirtual.io a few standard Drive Behaviors are included and you can extend them based on the components you are using in real life.\ Here is a list of the included Drive Behaviors. All Drive Behaviors are named with a prefix *Drive\_* from better clarification. {% hint style="info" %} The generic drive behaviors (Cylinder, Simple, Destination Motor, Follow Position, Gear, Continuous Destination, Speed, …) are part of every realvirtual edition. The detailed drive-profile / fieldbus behavior models that mirror the exact control-word / status-word interface of a real drive - PROFIdrive (Speed / Pos), CiA 402, Festo FHPP, SEW MOVILINK, UniDrive and the proportional valve - are part of realvirtual **Professional**. {% endhint %} ## Adding Drive Behaviors Drive behaviors can be added to a GameObject with a Drive component in two ways: 1. **Add Component Menu**: Select the GameObject with the Drive component, then use *Component > realvirtual > Motion > Drive Behaviors* to choose the desired behavior 2. **QuickEdit Overlay** (Professional): Use the QuickEdit overlay buttons to quickly add drive behaviors directly in the Scene view

QuickEdit overlay showing drive behavior buttons for quick access

This tutorial explains the relation between Signals and Behavior Models: {% embed url="" %} ### Drive\_Cylinder This is the model of a simple cylinder movement. The cylinder is defined by a maximum (*MaxPos*) and minimum (*MinPos*) position in millimeters in relation to a zero position. The speed of the cylinder to move in and out is defined by the time in seconds *TimeOut* and *TimeIn*. **Settings:** * **One Bit Cylinder**: When enabled, uses single signal for control. Out=false moves cylinder in, Out=true moves cylinder out. * **Invert Output Logic** (new in 6.0.9-beta): Inverts the control logic. When enabled, Out=false extends the cylinder, Out=true retracts it. Useful for normally-closed valve configurations or inverted signal requirements. * **Min Pos / Max Pos**: Define the cylinder stroke in millimeters. * **Time Out / Time In**: Extension and retraction times in seconds. * **Stop When Driving To Min/Max**: Optional sensors to stop the cylinder before reaching end positions. The cylinder can be controlled manually by setting the booleans under *Behavior Signals*. Under *PLC IOs* PLC signals can be connected to the cylinder.
### Drive\_Simple The Simple Drive is controlled by boolean values for forward and backward movement with configurable speed and acceleration. **Settings:** * **Scale Speed**: Scale factor for input/output speed and acceleration values * **Current Position Scale** (new in 6.0.9-beta): Scale factor for position feedback transformation * **Current Position Offset** (new in 6.0.9-beta): Offset in millimeters applied to position feedback * **Scale Feedback Position** (new in 6.0.9-beta): When enabled (default), applies scale and offset to position feedback. Disable to receive raw position values. The scale and offset enable symmetric transformations for proper closed-loop control: position feedback uses the inverse transformation of position commands.
### Drive\_DestinationMotor The Destination Motor is a drive controlled by target positions and target speeds. After setting the target speed and target position, the movement can be started by a boolean Signal *StartDrive*. After the drive reaches its target position the Signal *IsAtDestination* is set high. This is a **generic** positioning model with simple boolean and value signals. If you need to mirror the exact control-word / status-word interface of a real positioning drive, use one of the dedicated behaviors instead - see [Drive\_UniDriveMotor](#drive-unidrivemotor) (generic control-word / status-word positioning controller), [Drive\_ProfidriveSpeed](#drive-profidrivespeed) and [Drive\_ProfidrivePos](#drive-profidrivepos) (Siemens PROFIdrive). **Scale/Offset Properties** (new in 6.0.9-beta): * **Current Position Scale**: Scale factor applied to both position commands and feedback * **Current Position Offset**: Offset in millimeters applied to both position commands and feedback * **Scale Feedback Position**: When enabled (default), applies symmetric scale/offset transformations for proper closed-loop control
### Drive\_FollowPosition This is the behavior model of a drive where the drive exactly follows the current provided position of the PLC. This is especially useful for connecting motion controllers and robot controllers to realvirtual. **Settings:** * **Offset**: Position offset in millimeters added to input signal * **Scale**: Scale factor applied to position input signal * **Current Position Scale** (new in 6.0.9-beta): Additional scale factor for position feedback * **Scale Feedback Position** (new in 6.0.9-beta): When enabled (default), applies symmetric transformation: feedback = ((CurrentPosition - Offset) / Scale) \* CurrentPositionScale The symmetric transformation ensures that the PLC receives properly scaled feedback values that match the coordinate system of the commanded positions.
### Drive\_Gear This behavior model is useful for connecting two drives together. The master drive will control the position of the drive that the gear is attached to. This is useful for two gripper fingers where only one is controlled by a pneumatic model and the second one follows correspondingly. The formula for the position of a gear controlled drive is: *CurrentPosition = MasterDrive.CurrentPosition x GearFactor + Offset*.
### Drive\_ContinousDestination This drive is continuously trying to follow the given destination with the given speed. Unlike *Drive\_FollowPosition*, this Drive is not following exactly the given position because it might need some time to reach the destination. You don't need to set a start signal to start to drive like with *Drive\_DestinationMotor*. This drive is always starting to drive to a different destination as soon as the SignalDestination is changed. Please note, that you need to turn on *UseAccelearation* in the connected drive to use acceleration values.\ This Drive is specially useful for users who are reusing Simit models which are connected to NX Mechatronics Concept Designer. In NX Mechatronics Concept Designer this type of Drive is called *PositionControl*. **Scale/Offset Properties** (new in 6.0.9-beta): * **Current Position Scale**: Scale factor applied to both position commands and feedback * **Current Position Offset**: Offset in millimeters applied to both position commands and feedback * **Scale Feedback Position**: When enabled (default), applies symmetric scale/offset transformations
### Drive\_Speed Drive\_Speed is controlling a drive by a speed. You can't control directly the position. The drive is always driving in the given speed. Positive speed values means forward direction. Negative speed values means backward direction. Please note, that the smooth acceleration is not working with this drive. If you want to stop the drive the speed needs to be set to zero.\ This Drive is specially useful for users who are reusing Simit models which are connected to NX Mechatronics Concept Designer. In NX Mechatronics Concept Designer this type of Drive is called *SpeedControl*. **Position Feedback Properties** (new in 6.0.9-beta): * **Current Position Scale**: Scale factor for position feedback transformation * **Current Position Offset**: Offset in millimeters applied to position feedback * **Scale Feedback Position**: When enabled (default), applies scale and offset to position feedback. Disable to receive raw position values.
### Drive\_ErraticPosition This drive is only for test purposes. It is moves constantly to random positions between MinPos and MaxPos.
### Drive\_Sequence We recommend to not use DriveSequence any more and to use the new LogicStep visual programming which is simpler and gives you more flexibility. Please check [LogicSteps](/components-and-scripts/defining-logic/logicsteps). #### Starting a sequence step The Drive\_Sequence behavior allows to define simple sequences of motions. Each step in the sequence can set the Drive speed and the Drive Destination.\ The step is starting automatically after the step before. If a PLCSignal is defined in *Wait For Signal* the Step is not started before the Signal is set to true. #### Ending a sequence step In *Wait After Step* a time in seconds can be defined which should be waited after the drive is at its destination and before the next step is started. The *Finished Signal* is optionally and can be used to start external processes or Drive\_Sequences. This signal is set to true as soon as the step is finished
### Drive\_UniDriveMotor (Pro, Beta) {% hint style="warning" %} This behavior is part of realvirtual **Professional**, was added in realvirtual **6.3.4** and is currently in **beta**. The API and properties may still change. {% endhint %} Drive\_UniDriveMotor maps a UniDrive-style positioning controller onto a Drive, mirroring the typical control-word / status-word signal set of a parameterizable positioning drive. It combines a general release, a positioning start with integer setpoints (position, speed, acceleration and deceleration ramp) and manual jog bits with a setup/manual speed selection. Drive feedback (ready, referenced, in-position, actual position and actual speed) is written back to the PLC. This behavior is useful when connecting realvirtual to PLC blocks that drive a positioning axis through integer setpoints rather than physical units. Setpoints are transferred as integers and converted to the Drive's millimeter / degree units through the scaling properties. Signal directions follow the realvirtual PLC convention: PLC outputs are commands read by the behavior, PLC inputs are feedback written back to the PLC. **Scaling:** * **Position Scale**: Scale factor between integer position units (PLC) and millimeters / degrees (Drive). * **Position Offset**: Offset applied to position command and feedback in millimeters / degrees. * **Speed Scale**: Scale factor between integer speed units and mm/s. * **Acceleration Scale**: Scale factor between integer acceleration units and mm/s². **Jog:** * **Setup Speed**: Reduced jog speed in mm/s used when *Speed Selection* is false (setup / teach speed). **Status (Inspector controlled):** * **Ready**: Drive ready feedback (Betriebsbereit). Uncheck to simulate a not-ready drive. * **Referenced**: Encoder referenced feedback (Referenzieren OK). Uncheck to simulate a not-referenced drive. **PLC Outputs (commands from PLC):** * **Run**: General release of the drive. While low the drive is held stopped at its current position. * **Jog Plus / Jog Minus**: Manual jog forward / backward. Forward has priority if both bits are set. * **Speed Selection**: Jog speed selection - false uses *Setup Speed*, true uses the commanded *Set Speed*. * **Start Positioning**: Rising edge triggers a move to *Set Position* using *Set Speed* and *Set Acceleration*. * **Set Position / Set Speed / Set Acceleration / Set Deceleration**: Integer setpoints, converted with the scaling properties. * **Start Calibration / Reset Fault**: Present for interface completeness; signal only, no effect in the simulation. **PLC Inputs (feedback to PLC):** * **Is Ready / Is Referenced**: Driven by the *Ready* and *Referenced* settings. * **Is At Position 1**: True when the commanded position has been reached (and the drive is not jogging away from it). * **Actual Position / Actual Speed**: Current drive position and speed in integer units. {% hint style="info" %} The underlying Drive uses a single symmetric ramp for accelerating and braking. *Set Acceleration* drives the Drive acceleration; *Set Deceleration* is read and exposed (see the *Status* foldout) for transparency, but the drive brakes with the same ramp. Enable *Use Acceleration* on the Drive to apply the ramps. {% endhint %} The screenshot below shows the behavior as an example of a concrete drive implementation, mapping the control-word / status-word signals of a real positioning controller onto a Drive.

Drive_UniDriveMotor as an example of a concrete drive implementation

### Drive\_ProfidriveSpeed (Pro, Beta) {% hint style="warning" %} This behavior is part of realvirtual **Professional**, was added in realvirtual **6.3.4** and is currently in **beta**. The API and properties may still change. {% endhint %} Drive\_ProfidriveSpeed models a PROFIdrive speed-controlled drive (Siemens SINAMICS G120, S120, V90, …) using **standard telegram 1**. The PLC sends the control word **STW1** plus the normalized speed setpoint **NSOLL\_A**, and the drive returns the status word **ZSW1** plus the actual speed **NIST\_A**. The behavior runs the PROFIdrive state machine, so the drive only moves once the PLC has correctly enabled it - exactly like a real SINAMICS drive. This makes it possible to test the complete PLC enable sequence (ON/OFF1, OFF2, OFF3, enable operation, enable setpoint) against a realistic drive, without SIMIT or real hardware. **Setpoint normalization:** `NSOLL_A = 0x4000 (16384) = 100 %` of the reference speed (drive parameter p2000). Negative values reverse the direction. The actual speed is reported back with the same normalization. **Scaling:** * **Reference Speed**: Drive speed in mm/s (or °/s) at the full-scale setpoint (100 %). Corresponds to the drive reference speed p2000. * **Setpoint Scale**: Raw setpoint value that equals 100 %. Leave at 16384 (0x4000) for Siemens PROFIdrive NSOLL\_A. Set to 20000 to drive an **ABB** axis: the ABB Drives communication profile uses the same OFF1/OFF2/OFF3/Run/Reset state machine as PROFIdrive, only the reference REF1 is scaled to 20000 = 100 %. * **Acceleration**: Drive acceleration in mm/s² (or °/s²). Enable *Use Acceleration* on the Drive for a ramped speed follow. **Drive Status (Inspector controlled):** * **Simulate Fault**: Forces a drive fault (ZSW1.3). The PLC must acknowledge with STW1.7 (rising edge) to clear it. * **Simulate Warning**: Forces a drive warning (ZSW1.7). **PLC Outputs (commands from PLC):** * **Control Word**: PROFIdrive control word STW1. * **Speed Setpoint**: Normalized speed setpoint NSOLL\_A. **PLC Inputs (feedback to PLC):** * **Status Word**: PROFIdrive status word ZSW1. * **Speed Actual**: Normalized actual speed NIST\_A. The control word STW1 bits are interpreted as follows: bit 0 ON/OFF1, bit 1 OFF2 (1 = no coast stop), bit 2 OFF3 (1 = no quick stop), bit 3 enable operation, bit 4 enable ramp-function generator, bit 5 continue ramp-function generator, bit 6 enable setpoint, bit 7 acknowledge fault, bit 10 control by PLC, bit 11 setpoint inversion. The decoded bits and the current state machine state are shown read-only in the Inspector for transparent commissioning.

Drive_ProfidriveSpeed with control word STW1 / status word ZSW1 and the decoded STW1 bits

### Drive\_ProfidrivePos (Pro, Beta) {% hint style="warning" %} This behavior is part of realvirtual **Professional**, was added in realvirtual **6.3.4** and is currently in **beta**. The API and properties may still change. {% endhint %} Drive\_ProfidrivePos models a PROFIdrive basic positioner (Siemens SINAMICS **EPOS**) controlled through the **raw telegram 111 process data**, exactly as it appears in the PLC I/O area when realvirtual stands in for the drive. The PLC sends the control words **STW1**, **POS\_STW1**, **POS\_STW2**, the velocity override and the MDI setpoints (target position, velocity); the drive returns the status words **ZSW1**, **POS\_ZSW1**, **POS\_ZSW2** plus the actual position **XIST\_A** and actual speed **NIST\_B**. The behavior decodes the control word bits, runs the PROFIdrive state machine and performs the MDI (direct setpoint) positioning - bit-for-bit identical to a real S120 / G120 / V90 axis. This is the I/O-level (E/A) counterpart of the Siemens **SINA\_POS (FB284)** function block: SINA\_POS runs inside the PLC and packs / unpacks these telegram words, while this component models the drive side of the same telegram. The exact bit layout follows the SINAMICS function manuals (S120 / G120 / V90) and the SIMIT EPOS behavior library. **Supported MDI operations** (MDI mode, POS\_STW1.15 = 1): * **Absolute / relative positioning** (POS\_STW1.8) started by the rising edge of STW1.6 (activate traversing task) * **Setup mode** / endless travel at velocity (POS\_STW1.14) in the selected direction (POS\_STW1.9 / .10) * **Jogging** via STW1.8 / STW1.9 (jog 1 / jog 2) * **Homing** via STW1.11 and **set reference point** via POS\_STW2.1 (both mark the axis as referenced) Traversing-block mode (POS\_STW1.15 = 0) is not modeled, since block coordinates are drive parameters and not part of the telegram. The STW2/ZSW2 sign-of-life, MELDW and the fault/warning code words are not modeled. **Scaling:** * **Position Scale**: Drive millimeters / degrees per length unit (LU), used for MDI\_TARPOS and XIST\_A. * **Position Offset**: Offset in millimeters / degrees applied to position command and feedback. * **Velocity Scale**: Drive speed in mm/s per MDI\_VELOCITY unit (MDI\_VELOCITY is given in 1000 LU/min). * **Reference Speed**: Drive speed at NIST\_B = 0x40000000 (100 %), corresponds to reference speed p2000. * **Jog Speed**: Drive speed in mm/s used for jog mode (STW1.8 / STW1.9). * **Acceleration**: Drive acceleration in mm/s² (or °/s²) at 100 % override. **Drive Status (Inspector controlled):** * **Simulate Fault**: Forces a drive fault (ZSW1.3). The PLC must acknowledge with STW1.7 (rising edge) to clear it. * **Simulate Warning**: Forces a drive warning (ZSW1.7). **PLC Outputs (telegram 111 send words - commands from PLC):** * **Control Word**: STW1 (PZD1) - ON/OFF1, OFF2, OFF3, enable operation, reject/intermediate-stop, activate traversing task (edge), acknowledge fault, jog 1/2, control by PLC, start homing. * **Pos Control Word 1**: POS\_STW1 (PZD2) - MDI mode select (.15), absolute/relative (.8), direction (.9/.10), setup (.14), transfer type (.12). * **Pos Control Word 2**: POS\_STW2 (PZD3) - set reference point (.1), incremental jog (.5). * **Override**: OVERRIDE (PZD5), velocity override with 0x4000 = 100 %. * **Mdi Target Position**: MDI\_TARPOS (PZD6+7), target position in length units (LU). * **Mdi Velocity**: MDI\_VELOCITY (PZD8+9), velocity in 1000 LU/min. **PLC Inputs (telegram 111 receive words - feedback to PLC):** * **Status Word**: ZSW1 (PZD1) - ready / operation / inhibit / fault / warning / target reached / reference set / standstill / accelerating / decelerating. * **Pos Status Word 1**: POS\_ZSW1 (PZD2). * **Pos Status Word 2**: POS\_ZSW2 (PZD3) - axis forward (.4) / backward (.5) / traversing command active (.15). * **Position Actual**: XIST\_A (PZD6+7), actual position in LU. * **Speed Actual**: NIST\_B (PZD8+9), actual speed with 0x40000000 = 100 % of reference speed. The decoded STW1 / POS\_STW1 / POS\_STW2 control bits and the ZSW1 status bits are shown read-only in the Inspector for transparent commissioning.

Drive_ProfidrivePos with the raw telegram 111 control / status words and decoded bits

### Drive\_ProportionalValve (Pro, Beta) {% hint style="warning" %} This behavior is part of realvirtual **Professional**, was added in realvirtual **6.3.4** and is currently in **beta**. The API and properties may still change. {% endhint %} Drive\_ProportionalValve models a hydraulic (or electric) proportional directional valve that controls a Drive. It converts an analog command signal - the equivalent of a ±10 V, 4–20 mA or 0–100 % setpoint sent by a PLC through a valve amplifier - into a directional speed for the Drive. Unlike a plain speed setpoint, it reproduces the characteristics that make a real proportional valve behave differently from an ideal drive: a dead band around the neutral position, optional spool hysteresis, a configurable flow characteristic curve and a finite spool response time. The valve controls flow, which maps to the Drive speed; the motion direction follows the sign of the command, modelling a 4/3 directional valve with a neutral mid position. The signal chain per simulation step is: ``` Setpoint (±10V / 4-20mA / %) → normalize (Setpoint Zero / Setpoint Full) → command -1..+1 → dead band (spool overlap) → hysteresis (optional spool sticking) → response time (amplifier ramp + spool dynamics) → spool position → flow curve (linear or progressive) → flow -1..+1 → Drive.TargetSpeed = |flow| × Max Speed, direction = sign ``` **Setpoint Scaling:** * **Setpoint**: Analog command setpoint in raw signal units, used when no PLC signal is connected. * **Setpoint Zero**: Raw signal value that corresponds to zero flow / neutral position. Use `0` for ±10 V, `12` for 4–20 mA, `0` for 0–100 %. * **Setpoint Full**: Raw signal value that corresponds to 100 % flow in forward direction. Use `10` for ±10 V, `20` for 4–20 mA, `100` for 0–100 %. **Valve Characteristic:** * **Deadband** (0–0.9): Dead band around the neutral position modelling spool overlap. Below this fraction of the command no flow occurs. * **Enable Hysteresis**: When enabled, the spool sticks until the command change exceeds the hysteresis band. * **Hysteresis** (0–0.5): Hysteresis band as a fraction of the command. Changes smaller than this are ignored. * **Flow Curve**: Flow characteristic curve mapping the normalized command (X 0–1) to normalized flow (Y 0–1). Linear by default; can be made progressive for valves with a non-linear flow gain. * **Response Time**: Time in seconds for the spool to travel from neutral to full deflection (amplifier ramp plus spool dynamics). Set to `0` for instant response. **Flow / Speed Mapping:** * **Max Speed**: Drive speed at 100 % flow in mm/s (linear) or °/s (rotational). * **Acceleration**: Drive acceleration in mm/s² (or °/s²). Enable *Use Acceleration* on the Drive for a smooth speed follow. **PLC IOs:** * **Signal Setpoint**: PLC output carrying the analog valve setpoint. * **Signal Spool Position**: PLC input with the actual spool position (-1..1, where 1 = full forward flow). Models the LVDT feedback of closed-loop control valves. * **Signal Current Speed**: PLC input with the current Drive speed. * **Signal Current Position**: PLC input with the current Drive position. The *Valve Status* section shows the live **Command**, **Spool Position** and **Flow** values, which is useful for tuning the dead band, response time and flow curve.
### Drive\_CiA402 (Pro, Beta) {% hint style="warning" %} This behavior is part of realvirtual **Professional**, was added in realvirtual **6.3.4** and is currently in **beta**. The API and properties may still change. {% endhint %} Drive\_CiA402 models a CiA 402 / DS402 drive (IEC 61800-7) - the EtherCAT (CoE) and CANopen drive profile, and the counterpart to the PROFIdrive behaviors for the non-Siemens servo world. The master writes the **controlword** (object 6040h) and the setpoints; the drive returns the **statusword** (object 6041h) and the actual values. It works with virtually every CoE / CANopen servo: Beckhoff AX5000/AX8000, Kollmorgen AKD, Omron, Yaskawa, Schneider Lexium, Lenze i700, SEW MOVI-C in CiA402 mode, Bosch Rexroth ctrlX DRIVE and many more. The behavior runs the CiA 402 power state machine (Switch-On-Disabled → Ready-To-Switch-On → Switched-On → Operation-Enabled, plus Quick-Stop-Active and Fault), so the drive only moves once the master has stepped it through the standard **0x06 → 0x07 → 0x0F** enable sequence. **Supported modes of operation (object 6060h):** * **1 – Profile Position (PP):** move to *Target Position* (607Ah) at *Profile Velocity* (6081h), started by the rising edge of controlword bit 4 (new set-point), acknowledged by statusword bit 12. * **3 – Profile Velocity (PV):** run at *Target Velocity* (60FFh), direction follows the sign. * **6 – Homing (HM):** rising edge of bit 4 marks the axis as referenced (simplified homing). Cyclic synchronous modes (CSP/CSV/CST) and torque mode are not modeled. **Scaling:** * **Position Scale / Position Offset**: Drive millimeters / degrees per position increment, for Target Position (607Ah) and Position Actual (6064h). * **Velocity Scale**: Drive speed in mm/s per velocity unit (Profile Velocity 6081h, Target Velocity 60FFh). * **Acceleration**: Drive acceleration in mm/s² (or °/s²). **Drive Status (Inspector controlled):** * **Simulate Fault**: Forces a drive fault (statusword bit 3), cleared by controlword bit 7 (rising edge). * **Simulate Warning**: Forces a drive warning (statusword bit 7). **PLC Outputs (commands from master):** * **Control Word** (6040h), **Mode Of Operation** (6060h), **Target Position** (607Ah), **Profile Velocity** (6081h), **Target Velocity** (60FFh). **PLC Inputs (feedback to master):** * **Status Word** (6041h), **Mode Display** (6061h), **Position Actual** (6064h), **Velocity Actual** (606Ch). Pitfalls reproduced faithfully: controlword bit 2 (Quick Stop) and statusword bit 5 (Quick Stop) are **active low**; controlword bit 4 (new set-point) and bit 7 (fault reset) are edge-triggered. The decoded controlword / statusword bits and the state machine state are shown read-only in the Inspector.

Drive_CiA402 with the controlword 6040h / statusword 6041h interface and decoded bits

### Drive\_SEWMovilink (Pro, Beta) {% hint style="warning" %} This behavior is part of realvirtual **Professional**, was added in realvirtual **6.3.4** and is currently in **beta**. The API and properties may still change. {% endhint %} Drive\_SEWMovilink models a SEW-EURODRIVE drive using the **MOVILINK** unit profile (MOVIDRIVE B / MOVITRAC B / MOVIMOT). The PLC writes control word 1 (PO1) and the speed setpoint (PO2); the drive returns status word 1 (PI1) and the actual speed (PI2). This is the native SEW process image used across conveyor and intralogistics applications and is different from PROFIdrive, so it is modeled separately. {% hint style="info" %} MOVILINK is the legacy SEW unit profile. **MOVI-C** does not use MOVILINK - it uses the MOVIKIT process data profile or PROFIdrive / CiA 402. For a MOVI-C drive in CiA402 mode use [Drive\_CiA402](#drive-cia402) instead. {% endhint %} MOVILINK uses three priority-ordered low-byte command bits instead of a numbered state machine: **controller inhibit > rapid stop > stop > enable**. The enable path requires the control word low byte to be **0x06**. {% hint style="info" %} Key pitfall: control word bit 0 is the **inverted** controller inhibit (1 = inhibit / hold, 0 = released), and bits 1/2 are active low (0 = rapid stop / stop). The enable byte is **0x06, not 0x07** - 0x07 sets bit 0 = inhibit. A zeroed control word (0x0000) is the fail-safe "no enable" state. {% endhint %} **Scaling:** * **Max Speed**: Drive speed in mm/s (or °/s) at 100 % / maximum speed. * **Encoding**: Speed setpoint encoding - *SPEED\[%]* (0x4000 = 100 %) or *SPEED* (0.2 rpm per bit). * **Max Speed Rpm**: Maximum speed in rpm (nmax), used to convert the 0.2 rpm/bit encoding. * **Acceleration**: Drive acceleration in mm/s² (or °/s²). **Drive Status (Inspector controlled):** * **Simulate Fault**: Forces a fault (status word bit 5), cleared by control word bit 6 (rising edge). * **Fault Code**: Code reported in the status word high byte while a fault is active. **PLC Outputs (process output data):** * **Control Word 1** (PO1), **Speed Setpoint** (PO2). **PLC Inputs (process input data):** * **Status Word 1** (PI1, with the device-status digit / fault code in the high byte), **Speed Actual** (PI2).

Drive_SEWMovilink with the MOVILINK control word 1 / status word 1 interface and decoded bits

### Drive\_FestoFHPP (Pro, Beta) {% hint style="warning" %} This behavior is part of realvirtual **Professional**, was added in realvirtual **6.3.4** and is currently in **beta**. The API and properties may still change. {% endhint %} Drive\_FestoFHPP models a Festo drive using the **FHPP** (Festo Handling and Positioning Profile), the native profile of the Festo electric-handling family (CMMP-AS, CMMS-ST/AS, CMMD, CMMO-ST, CPX, CMMT in Festo-profile mode). FHPP is byte-oriented: the PLC writes the control bytes **CCON / CPOS** plus the setpoints, and the drive returns the status bytes **SCON / SPOS** plus the actual values. **Two operating modes** (selected via CCON bits 6/7): * **Record Select:** byte 2 selects a stored traversing record from the *Records* table (position, velocity, absolute/relative configured in the Inspector). * **Direct Mode:** the target position (bytes 4-7) and velocity (byte 3, 0-100 %) are sent inline. The positioning handshake follows the FHPP standard **START → ACK → MC**: the rising edge of CPOS.START latches the setpoints and begins the move, the drive answers with SPOS.ACK, and SPOS.MC (Motion Complete) goes high when the target is reached. Homing via CPOS.HOM marks the axis as referenced. {% hint style="info" %} Pitfalls reproduced faithfully: CCON.STOP (bit 1) and CPOS.HALT (bit 0) are **active low** (0 = stop / halt); CPOS.START / HOM and CCON.RESET are rising-edge; CPOS.TEACH is falling-edge; the velocity byte is unsigned %. {% endhint %} **Scaling:** * **Position Scale / Position Offset**: Drive millimeters / degrees per position increment (Direct mode target / actual position). * **Base Velocity**: Drive speed in mm/s at 100 % velocity (Direct mode velocity byte = 0-100 %). * **Jog Speed**: Drive speed in mm/s for CPOS.JOGP / CPOS.JOGN. * **Acceleration**: Drive acceleration in mm/s² (or °/s²). * **Records**: Traversing record table (position, velocity, absolute/relative) for Record Select mode. **PLC Outputs (FHPP output bytes):** * **Ccon** (byte 0), **Cpos** (byte 1), **Record Or Cdir** (byte 2), **Velocity Percent** (byte 3), **Target Position** (bytes 4-7). **PLC Inputs (FHPP input bytes):** * **Scon** (byte 0), **Spos** (byte 1), **Record Or Sdir** (byte 2), **Position Actual** (bytes 4-7). Force / torque mode and the FPC parameter channel are not modeled.

Drive_FestoFHPP with the FHPP CCON/CPOS and SCON/SPOS byte interface

© 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # CAM A CAM (Camshaft) is a connection mechanism between a master Drive and a slave Drive, often used in packaging machinery and other automation systems. CAMs allow the slave drive to move in relation to the master drive according to a predefined CAM profile. This is particularly useful for controlling complex motion profiles in automated systems. You can watch this tutorial video to learn more about CAMs:\ ### Defining CAMs CAM profiles can be defined and imported into Unity through various file types. The CAM component supports both Excel and CSV formats for defining these profiles.
## **File Types Supported:** * **Excel**: `.xlsx` files. * **CSV**: `.csv` files. ## **Public Properties** **MasterDrive**\ The master drive to which the slave drive is attached. The slave drive's position will be determined by the master drive's position according to the CAM profile. **MasterDriveAxisScale**\ A scale factor applied to the master drive position to get the value used in the CAM curve. **MasterDriveAxisOffset**\ An offset added to the master drive position to determine the value used in the CAM curve. **CAMAxisScale**\ The scale factor for the CAM axis. It scales the values of the CAM curve. **CAMAxisOffset**\ An offset added to the values of the CAM curve to determine the position applied to the CAM (slave) axis. **ExcelSheet**\ Name of the Excel sheet used when importing CAM data from an Excel file. **ExcelFile**\ Path to the Excel file used for importing CAM data. **CamDefintion**\ A text asset containing the CAM definition. This asset is a table with optional headers and columns describing the master axis position and the slave axis position. **UseColumnNames**\ Indicates whether column names are used to define the data to import. **MasterColumn**\ The name of the column in the text asset that contains the master axis position. **SlaveColumn**\ The name of the column in the text asset that contains the slave axis position. **UseColumnNumbers**\ Indicates whether column numbers are used to define the data to import. **MasterColumnNum**\ The column number (starting with 1) that contains the master axis position in the text asset. **SlaveColumnNum**\ The column number (starting with 1) that contains the slave axis position in the text asset. **CamDefinitionWithHeader**\ Indicates whether the first line of the text asset is a header. **ImportOnStart**\ Indicates whether the CAM data should be imported automatically when the simulation starts. **IsContinous**\ Indicates whether the CAM should continue as an offset based on the last CAM position, useful for continuous movements like transport chains. **Usage Instructions** 1. **Select CAM File**: Choose the CAM profile file using the `ExcelFile` or `CamDefintion` property, depending on whether you are using Excel or CSV. 2. **Set Scaling and Offsets**: Adjust the `MasterDriveAxisScale`, `MasterDriveAxisOffset`, `CAMAxisScale`, and `CAMAxisOffset` properties to fit your application's requirements. 3. **Import CAM Profile**: Use the `ImportOnStart` property to automatically import the CAM profile when the simulation starts. 4. **Configure Continuous Mode**: Enable `IsContinous` if the CAM profile should operate continuously. Adjust `ContinousOffset` as needed. Please check the[ Realvirtual.io Class Reference](https://game4automation.com/documentation/current/apidoc/html/classgame4automation_1_1_base_c_a_m.html) for more information about the properties and methods of this component. \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Drive Position Switch {% hint style="info" %} This feature was added in realvirtual **6.0.9 beta** {% endhint %} ## Overview The **Drive Position Switch** component controls a boolean PLC signal based on the drive's position. It monitors one or more position ranges and activates an output signal when the drive enters any of these areas. The component fully supports both linear and rotational drives, including drives with wrap-around behavior (e.g., 0-360° rotational drives). This component is particularly useful for creating position-dependent logic in automation systems, such as activating sensors, triggering actions at specific zones, or creating safe areas on linear or rotational axes. ## Key Features * **Multiple Position Areas** - Define multiple ranges where the signal should be active * **OR Logic** - Signal activates when drive is in ANY defined area * **Area Inversion** - Optionally define areas as "false zones" instead of "true zones" * **Position Offset** - Apply a global offset to the drive position before checking areas * **Wrap-Around Support** - Automatic detection and handling of rotational drives with position wrapping * **Wrapped Areas** - Support for areas that wrap around limits (e.g., 350-10° on a 0-360° drive) ## Properties

Drive Position Switch Inspector

### Position Areas **Areas** (list) A list of position ranges that control the output signal. Each area has: * **Name** - Descriptive name for the area * **Start Position** - Beginning of the range in millimeters or degrees * **End Position** - End of the range in millimeters or degrees When the drive position is within ANY of these areas, the output signal is set to true (OR logic). For rotational drives with wrapping enabled, areas can wrap around the limits by setting Start Position > End Position (e.g., 350-10 on a 0-360° drive). ### Settings **Invert Areas** (boolean) When enabled, the defined areas become "false zones" instead of "true zones". The output signal is false when inside areas and true when outside all areas. This is useful for defining exclusion zones or safe areas. **Position Offset** (float) A global offset in millimeters or degrees applied to the drive's current position before checking areas. For drives with wrapping enabled, the offset is automatically normalized to stay within the drive's limits. This allows you to shift all areas without modifying each individual area range. ### PLC IOs **Output Signal** (PLCInputBool) The boolean signal sent to the PLC. This signal is true when the drive position (after applying offset) is within any defined area, or inverted if Invert Areas is enabled. Connect this to your PLC logic or other components that need position-based triggering. ## Usage ### Basic Position Switch To create a simple position switch that activates in specific zones: 1. Add a **Drive** component to a GameObject 2. Add the **Drive Position Switch** component to the same GameObject 3. In the Inspector, expand the **Areas** list and click the + button 4. Set **Start Position** and **End Position** for your desired activation zone 5. Add a **PLCInputBool** signal or connect the **Output Signal** to your logic 6. The signal will be true when the drive is within the defined range ### Multiple Zones To activate the signal in multiple separate zones: 1. Add multiple elements to the **Areas** list 2. Configure each area with different Start and End positions 3. The output will be true if the drive is in ANY of the defined areas (OR logic) Example: Activate signal at positions 100-150mm and 300-350mm: * Area 1: Start=100, End=150 * Area 2: Start=300, End=350 ### Rotational Drives with Wrap-Around For rotational drives that jump from upper to lower limit (e.g., 360° to 0°): 1. Ensure your Drive has **Use Limits** enabled and **Jump To Lower Limit On Upper Limit** enabled 2. Create areas that can wrap around limits by setting Start Position > End Position 3. The component automatically detects and handles wrapped areas Example: Activate between 350° and 10° on a 0-360° drive: * Area: Start=350, End=10 * Signal will be true from 350° to 360° AND from 0° to 10° ### Safe Zones with Area Inversion To define safe zones where the signal is false (and true everywhere else): 1. Enable **Invert Areas** checkbox 2. Define areas where you want the signal to be FALSE 3. The output will be true when OUTSIDE all defined areas Example: Create a safe zone from 100-200mm where output is false: * Enable Invert Areas * Area: Start=100, End=200 * Result: Signal is false from 100-200mm, true everywhere else ### Position Offset Use position offset to shift the coordinate system without modifying all areas: 1. Set **Position Offset** to your desired offset value 2. The drive's position is adjusted before checking areas 3. For wrapping drives, the offset is automatically normalized Example: Check if drive is at position 0-50mm with 100mm offset: * Area: Start=0, End=50 * Position Offset: 100 * Result: Signal is true when drive is at -100 to -50mm (adjusted to 0-50mm) ## See Also * [Drive](/components-and-scripts/motion/drive) - The main Drive component * [Drive Behaviors](/components-and-scripts/motion/drive-behavior) - Overview of all Drive Behavior components * [PLCInputBool](https://github.com/game4automation/doc/blob/doc/components-and-scripts/plc-signals.md#plcinputbool) - Boolean signals to PLC * [Sensor](/components-and-scripts/sensors/sensor) - Alternative for proximity-based detection # Group The Group script is assigning a defined group to the component where the group is attached to.
The Group is named by a GroupName. For Prefabs you can also define a reference to another object which will create a Prefix for the group name. This is especially useful if you would like to generate reusable prefabs that are using the Group function. The Group scritp is specially used by the [Kinematic](/components-and-scripts/motion/kinematic) script. The [Selection Window](/basics/user-interface/selection-window) (available in Pro only) allows you to easily hide and show Groups. \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Joint ### Introduction PhysiX Joints and realvirtual.io forward kinematics > Joints use the Unity PhysX system. Due to some limitations of physics joints, you should only use this joint if you really need it for backward kinematics and you should not use it for normal forward kinematics. The default concept for moving axes in realvirtual.io is to move the position of the gameobjects themselves by using “Kinematic Rigidbodies”. This means that the gameobject hierarchy defines the kinematic chain and that these positions are not controlled by the Unitys physics engine. We took this approach, because pure PhysX-controlled movements have some disadvantages. PhysX joints always have some elastic behavior due to the physics solvers, and very accurate positioning of the axes is very difficult to achieve. For example, it is important that the TCP of a robot is exactly at the desired position after all robot axes are set to the angle calculated by the robot controller. If you need backward kinematics, which means that a kinematic chain should follow a component that is controlled by a drive, you can use PhysX joints. But you should always keep in mind that these positions are calculated by the PhysX engine and that the position can be inaccurate. {% hint style="info" %} It is only possible to combine Drive-controlled axes with PhysX joints if the PhysX axes follow the Drive. Due to Unity PhysX limitations, it is not possible to put a Drive controlled axis in the middle of a PhyxX Joint controlled kinematic chain. The realvirtual.io Drive MUST always be at the end or beginning of the PhysX kinematic chain. The PhysX kinematic chain will only follow the axis that is fully controlled by a realvirtual.io Drive. {% endhint %}
Sometimes the standard Unity Joints (e.g. Configurable Joint) are very hard to understand and overloaded with properties. This is why we implemented a simple Joint script. This Joint script will create a standard Unity joint automatically when the simulation starts. ### Joint With the Joint component you can define cylindrical and linear joints with the same kind of axis and direction definition you already know form realvirtual.io drives. Additionally the connected Rigidbodies will be automatically shown as a Mesh Gizmo in yellow (see picture above).
**Connected To** is the Rigidody which is connected to this component by this joint. **Delta Center** you can move the center of the Joint axis by the defined values. If the value is zero the center point of this joint is in the pivot point of the gameobject the Joint script is attached to. **Center On Object 1 / Center On Object 2** It is possible to define external gameobjects which are defining the rotation point of the axis. If to gameobjects are defined the center between the two gameobjects is the center point of this joint. **Show Gizmo** if set to true the axis of the joint is shown by a red line and the connected Rigidody is shown by a yellow mesh. \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Kinematic Very often when importing 3D parts from external sources like CAD systems the 3D data is not structured in a kinematic manner.\ The realvirtual.io kinematic is based on the hierarchy of Gameobjects. This means, that the hierarchy defines also the kinematic chain.\ For creating a kinematic chain there are multiple ways. You could restructure the Gameobject hierarchy manually in realvirtual.io or the CAD system before exporting to Unity. But normally, it is better to leave the imported structure as it is. This facilitates the update workflow, if you reimport the 3D data again, in the case of design changes. The Kinematic component is for restructuring the Kinematic chain and for repositioning objects without manually changing the imported 3D data (and without changing the structure of the data in the CAD system). In this Youtube tutorial you can get an insight about defining Kinematics with realvirtual.io:\\ {% embed url="" %} Tutorial CAD independent Kinematic definition {% endembed %} The Kinematic component offers these 4 functions. All functions are started on simulation start:\ **Repositioning and aligning the origin** to another Gameobject origin. This will also move the children of the Kinematic component. **Move the pivot center** and keep the position of the child Gameobjects for defining a rotation point. **Integrate parts from a defined Group** into this Kinematic component. **Define a Kinematic parent** to move the Kinematic Gameobject and its children underneath another GameObject.
### Gizmo In large CAD designs you work very often with a lot of Kinematic Groups based on the function *Integrate Group*. Because usually the Gameobjects with the *Kinematic* script attached to it are empty you can enable *Show Group Gizmo*. This will highlight all the meshes which are part of the defined group like shown in this picture.
### Reposition A part might be not placed on simulation start as it should. You can reposition any GameObject if you select this option. You need to assign another reference GameObject where this part will be placed to. The Pivot origins of the part will be aligned to the defined Gameobjects pivot. The operation will be performed uppon simulation start. ### Move Center You can move the center of a part without moving the positions of the underlying parts itself. To do this you can define a vector (in millimeters) and a rotation (in the local coordinate system) where the center of the part should be moved to. The operation will be performed uppon simulation start. ### Integrate Group You can integrate a group into this kinematic part. To do this you need to assign the Group script to any other GameObject and give the group a name. Integrate Group will move all parts with the defined group underneath this kinematic part on the simulation start. This is the most important function. With this method you can define CAD design structure independent Kinematic groups in parallel to the imported CAD data. For the reuse of components you can assign in *Group Name Prefix* a part whose name is used as prefix of the group name. Please check for example the Demo model *Assets/game4automation/Scenes/DemoGripping* for an example how to use this function. ### New Kinematic Parent With New Kinematic Parent, you are moving this part underneath another part upon simulation start. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Kinematic Joints (Pro) {% hint style="info" %} This feature was added in realvirtual **6.3.x** (Professional). {% endhint %} ## Overview Kinematic Joints add a purely kinematic, position-based constraint solver to realvirtual. They solve **closed kinematic chains** — Delta robots, four-bar linkages, scissor lifts, parallel grippers — without using Unity's physics engine at all. A `KinematicMechanism` collects every `KinematicJoint` in its hierarchy and, once per FixedUpdate, moves every passive link so that all joint constraints are satisfied, given the current position of your `Drive` components. There is no jitter, no drift, and no PhysX involved: the same Drive input always produces the exact same result. This is a different, fourth path alongside realvirtual's existing motion systems (kinematic hierarchy Drives, `Joint`/PhysX joints, `Kinematic`/CAD pivot correction — see [Joint](/components-and-scripts/motion/joint) and [Kinematic](/components-and-scripts/motion/kinematic)). Use Kinematic Joints specifically when a mechanism cannot be expressed as a simple parent/child hierarchy because one link has to satisfy more than one constraint at the same time — the defining trait of a closed loop. {% hint style="success" %} **Accuracy, not physics.** A PhysX `Joint` solves a closed loop with iterative, force-driven physics, so it tends to jitter, sag and drift, needs spring/damper tuning to stay stable, and is not exactly repeatable. Kinematic Joints satisfy the geometry *exactly* every FixedUpdate — no jitter, no drift, fully deterministic. Whenever the mechanism's pose has to be *correct* (a Delta picking to a precise point, a linkage indexing to a fixed stop, a gripper closing to an exact width), use Kinematic Joints; reach for a physics joint only when the dynamics themselves are what you want to simulate. {% endhint %} Drives keep working exactly as you already know them. A Drive still owns its own axis and moves it with speed, acceleration and limits. The only difference is that a `KinematicJoint` references that Drive as its **Driven By** field — the joint becomes the active boundary condition the solver treats as fixed for that step, and everything downstream (the passive links) is calculated from it.

A real Autonox delta robot (CAD import) running purely on Kinematic Joints: three driven arms close a Universal–Spherical parallelogram onto the floating platform, plus a telescope axis and a driven TCP rotation. This is the DemoKinematicsSolver sample scene (menu realvirtual/Kinematics demos).

{% hint style="info" %} The Autonox robot in the demo scene was reconstructed from the manufacturer's public connecting-dimensions drawing, not from exact internal CAD. The joint positions are plausible and the mechanism solves cleanly, but the arm/rod geometry is approximate — treat the demo as a showcase of the solver, not as a dimensionally accurate Autonox model. {% endhint %} ## Key Concepts **Floating links.** Links that form part of a closed loop do not need to be parented to each other. A coupler link in a four-bar linkage, for example, sits directly under the mechanism root and is positioned purely by its `KinematicJoint` connections — this is what makes closed loops possible in the first place. **Four joint types.** Revolute (hinge), Prismatic (slider), Spherical (ball joint) and Universal (cardan) cover the vast majority of mechanical joints. A Universal joint is required wherever a rod would otherwise be held only by two Spherical joints — that configuration has a free spin degree of freedom around the rod's own axis, which realvirtual detects and flags with a console warning. **Active vs. passive joints.** A joint becomes "active" the moment you assign a Drive to its **Driven By** field. Active joints are the boundary conditions of the solve; every other joint is passive and gets its value calculated by the solver every FixedUpdate. **Diagnosis, not silent failure.** If a mechanism is pushed to or beyond a joint limit, or into a configuration it cannot exactly reach, the solver converges to the closest achievable pose instead of tearing the chain apart. `Converged` and `Residual Error` on the `KinematicMechanism` make this visible at a glance, and an optional `Signal Converged` PLC signal exposes it to your automation logic. ## Joint Types Every `KinematicJoint` is one of four types. The type decides how many degrees of freedom the joint leaves open, which anchor/axis fields you need to fill in, and how the joint is drawn in the Scene View. When you select a joint (or its `KinematicMechanism`), each joint draws a type-specific, color-coded gizmo; selecting a single joint additionally highlights its two connected links as a wireframe — **Body A in blue, Body B in orange** — so you can see at a glance which two parts a joint ties together.

Scene View joint gizmos on the Autonox delta: the green/pink Cardan crosses are Universal joints, each with a live 90° angle label between its two axes; the orange outline marks the selected link.

**Revolute — 1 rotational DOF (hinge).** Rotates about a single axis. Fill in **Anchor A** (the hinge point) and **Axis A** (the rotation axis, in Body A's local space). This is the only joint type besides Prismatic that carries a single scalar value, so it is the type you normally make *active* by assigning a **Driven By** Drive, and the only type (with Prismatic) that supports **Use Limits**. Gizmo: a blue disc in the rotation plane with an axis arrow, plus a green limit arc that turns red as the joint approaches a limit. Typical use: robot arm axes, four-bar cranks and rockers, the driven arms of a Delta robot. **Prismatic — 1 translational DOF (slider).** Slides along a single axis. Anchor A and Axis A define the slide line; **Use Limits** clamps the travel in millimeters. Gizmo: an orange slide line with end markers and a cube marker at the current position. Typical use: scissor-lift strokes, linear actuators, the telescope axis of the Autonox demo. **Spherical — 3 rotational DOF (ball joint).** A free ball joint with no single axis — only **Anchor A** and **Anchor B** matter, Axis A and limits are hidden. Gizmo: three orthogonal wireframe rings (a wire sphere) at the anchor. Typical use: the lower end of parallelogram rods, ball-jointed linkages. A rod held by *two* Spherical joints has a free idle-spin degree of freedom around its own axis, which the solver flags as a warning — use a Universal joint at one end instead (see below). **Universal — 2 rotational DOF (Cardan / U-joint).** Transmits rotation while allowing a bend, like a cardan/universal joint. It needs **two** axes: **Axis A** in Body A's space and **Secondary Axis B** in Body B's space, which should be perpendicular at the assembled pose. Gizmo: a stylized Cardan cross (two perpendicular yoke forks) with a live angle label — green at 90°, orange as the two axes drift away from square. This is the required upper-joint type of a Delta parallelogram: pairing one Universal with one Spherical per rod removes the idle-spin freedom that two Spherical joints would leave.

A Universal joint of the delta parallelogram selected: the Inspector shows Body A (ArmPivot0) and Body B (rod), the connected-link wireframe highlight (blue = Body A, orange = Body B), and the Transform-authoring section.

## Properties ### KinematicJoint **Joint Type** (enum) Selects the constraint: Revolute (1 rotational DOF), Prismatic (1 translational DOF), Spherical (3 rotational DOF, no single axis) or Universal (2 rotational DOF, cardan-style). **Body A** / **Body B** (Transform) The two links this joint connects. Body A may be left empty to anchor the joint against world/static space; Body B is always required. **Anchor A** / **Anchor B** (Vector3, millimeters) The joint's pivot point, given in each body's own local space. **Axis A** (Vector3) The joint axis in Body A's local space. Used by Revolute, Prismatic and Universal; not shown for Spherical, which has no single axis. **Secondary Axis B** (Vector3) The second joint axis, in Body B's local space — Universal joints only. **Use Limits** (boolean) Clamps the joint's value between Lower Limit and Upper Limit. Available for Revolute and Prismatic joints, which have a single scalar value a limit can clamp. **Lower Limit** / **Upper Limit** (float) The clamping range, in degrees (Revolute) or millimeters (Prismatic). **Driven By** (Drive) The Drive that actively controls this joint. Leave empty for a passive joint the solver calculates. **Current Value** (float, read-only) The joint's current value in degrees or millimeters, written by the solver every FixedUpdate for diagnosis. ### KinematicMechanism **Solver Iterations** (int) The fixed number of Newton-Raphson iterations run every FixedUpdate. Four is enough for most mechanisms; a Delta robot with several floating links benefits from a higher value (the demo scene uses twelve). **Damping** (float) The damped-least-squares factor that keeps the solver stable near singular configurations. The default works well for typical mechanisms. **Tolerance** (float, millimeters) The residual error below which the mechanism reports `Converged = true`. **Converged** (boolean, read-only) Whether the last solve met Tolerance. **Residual Error** (float, read-only) The largest remaining constraint error of the last solve, in millimeters — visible directly in the Inspector's Diagnosis panel with a green check or red cross. **Signal Converged** (PLCOutputBool) Optional PLC signal mirroring Converged, so your control logic can react to a mechanism that has run into a limit. ## Quick Start 1. Create an empty GameObject for your mechanism and add a **Kinematic Mechanism** component (`realvirtual/Kinematics/Kinematic Mechanism`). 2. Add the links as children — the fixed frame, any Drive-controlled links, and any floating (loop) links. 3. Add one **Kinematic Joint** component (`realvirtual/Kinematics/Kinematic Joint`) per connection between two links, and set Body A, Body B, Anchor A/B and Axis A. 4. For every joint a Drive should control, assign that Drive to **Driven By**. 5. Press **Validate Mechanism** in the `KinematicMechanism` Inspector to check the topology (link/joint count, independent loops, an estimated degree-of-freedom count) before pressing Play. 6. In Edit Mode, use **Solve Now** to preview a single solve pass without entering Play Mode — the change is fully undoable. 7. Enter Play Mode and drive your Drives as usual. The mechanism solves automatically every FixedUpdate.

The KinematicMechanism Inspector: live Diagnosis (Converged, Residual Error, Solve Time), the Validation panel (here 19 joints OK · DOF 4), and per-joint Edit-Mode Jog sliders that drive the mechanism without entering Play Mode.

## Editor Tools Anchor A and Axis A can be dragged directly in the Scene View when a `KinematicJoint` is selected — a position handle for the anchor and a free-move handle for the axis direction. Gizmos color-code every joint by type (blue disc for Revolute, orange for Prismatic, purple sphere for Spherical, two colored arrows for Universal) and show a limit arc that turns red once a Revolute or Prismatic joint approaches its limit. Selecting the `KinematicMechanism` additionally draws a connector line between every joint's Body A/B anchors — this line turns into a dashed yellow warning line if the mechanism's residual error exceeds Tolerance, making an unreachable configuration visible at a glance. The **Kinematic Joint** section in the [Kinematic Tool](/basics/user-interface/kinematic-tool-pro) window reuses the tool's existing pivot/bounding-box axis definition to quickly place joint anchors on CAD meshes. ## Inverse Mode / Kinematic Target {% hint style="info" %} This feature was added in realvirtual **6.3.x** (Professional). {% endhint %} Everything above describes the **forward** direction: Drives in, passive link poses out. `KinematicTarget` adds the reverse direction to the same solver — a Cartesian world-space position in, driven-joint values out. Attach it to any GameObject, set **Mechanism** and **Target Link** (the mechanism's own link that should follow this GameObject, e.g. a Delta robot's platform), and enable **Tracking Active**: every FixedUpdate the mechanism's Drives are solved so Target Link converges towards the GameObject's own position. This is the generic replacement for a per-mechanism analytical inverse kinematics implementation — any mechanism this system can already solve forward, it can now also solve inverse, using the same damped-least-squares approach and the same "closest achievable pose" behavior for unreachable targets. Position only — there is deliberately no orientation target. The parallel-kinematic platforms this system targets (Delta robots above all) have no independent orientation degree of freedom at all; their platform orientation is a byproduct of the parallelogram-arm geometry, not a controllable input, so an orientation constraint would simply over-constrain a solve that position alone already fully determines. **Mechanism** (KinematicMechanism) The mechanism whose actively-driven joints are solved for this target. **Target Link** (Transform) The mechanism's own link that should track this GameObject's world position — typically the same link a forward-mode setup would read for diagnosis (a Delta robot's platform, a scissor lift's top stage). **Tracking Active** (boolean) Enables continuous inverse-mode tracking. While active, the driven Drives are released from their normal Jog/Drive To/speed-ramp behavior (`Drive.IsExternallyControlled`) so this component's writes are authoritative — the same convention `RobotIK` uses for its own IK solutions. Disabling it hands the Drives back to their usual behavior. **Reachable** (boolean, read-only) Whether the last inverse solve converged exactly on the target position. `false` means the target sits outside the mechanism's workspace or a Drive limit was hit — the mechanism still moves to the closest achievable pose instead of freezing, exactly like the forward solver's own diagnosis. A small crosshair marks the target position in the Scene View, with a dotted line to Target Link's current position — green while reachable, red when the target is outside the workspace. For scripted or programmatic use without a live-tracking GameObject, `KinematicMechanism` exposes the underlying solve directly: ```csharp // Pure calculation, does not move the scene: float[] jointValues = new float[mechanism.GetActiveJointCount()]; bool reachable = mechanism.SolveInverse(targetWorldPosition, platformLink, jointValues); // Solves AND writes the result into the driven Drives: bool reachable = mechanism.DriveToPosition(targetWorldPosition, platformLink); ``` ## Performance The constraint solver runs in a high-performance **native core**, not in managed script code. Even a demanding closed-loop mechanism like the Autonox delta — 19 joints, ten floating bodies, roughly 66 generalized coordinates — solves in well under a tenth of a millisecond per FixedUpdate. The live **Solve Time Ms** field on the `KinematicMechanism` Diagnosis panel shows this directly (about 0.07 ms for the Autonox demo). Mechanisms are also solved **in parallel**. When a scene contains many independent mechanisms, realvirtual gathers them into one batch each FixedUpdate and solves them across worker threads, then writes every result back on the main thread in a deterministic order. In a stress-test scene of **100 full Autonox delta robots** (1900 joints in total) the entire batch solves in roughly **8 ms per FixedUpdate** — comfortably real-time — where a naive one-after-another approach would need hundreds of milliseconds. The result stays fully deterministic: identical Drive inputs always produce identical poses, whether one mechanism runs or a hundred. You never configure any of this. Build your mechanism, press Play, and the solver picks the fast path automatically. ## Common Use Cases **Delta robots** – Three Drive-controlled arms, each closing a Universal-Spherical parallelogram onto a floating platform. This is the reference mechanism the solver was validated against — the platform stays purely translational (no rotation) as the arms move, exactly like a physical Delta robot.

The primitive four-bar linkage and Delta robot from the demo scene. The four-bar's Validation panel shows the expected DOF −2 note: the generic Grübler/Kutzbach formula routinely flags parallel-axis mechanisms as over-constrained even though they move freely — informational only.

**Scissor lifts** – A single Drive-controlled Prismatic joint pushes the base of a scissor stage; the platform height follows automatically from the geometry. **Four-bar / coupler linkages** – A Drive-controlled crank moves a coupler and rocker link through a closed loop, useful for cams, indexing mechanisms and toggle clamps. **Parallel grippers** – Two or more jaws that must open/close symmetrically from a single Drive, connected through a shared coupler link. ## Limitations (V1) **Joint types.** The four types cover the vast majority of industrial mechanisms, but three multibody joint types are not yet built in: * **Cylindrical** — rotation *and* translation about the *same* axis at once (2 DOF), as in a rotating telescopic shaft. Model it today as a **Revolute + Prismatic** pair on a shared intermediate link (one dummy link between the two joints, both using the same axis). The Autonox demo's telescope is built this way. * **Planar** — two translations plus one rotation in a plane (3 DOF). * **Screw / helical** — rotation and translation rigidly coupled by a lead (a threaded spindle). A separate `Drive` gear/ratio coupling is the current workaround. There is deliberately no fixed/weld joint — two links that never move relative to each other are simply parented in the hierarchy. **Other V1 limits.** * Kinematic Joints solve only in **Play Mode**, because the solve runs on Unity's `FixedUpdate` step, which Unity itself only executes while playing. Use **Solve Now** (or the Jog sliders) in the `KinematicMechanism` Inspector for a fully-undoable Edit Mode preview. * **Nested mechanisms** (a `KinematicMechanism` inside another one) are not supported and are flagged as a configuration error — each mechanism is solved as one self-contained constraint graph. * A mechanism has **one grounding reference** (its fixed frame, or world). Any number of joints may anchor to that same ground — a four-bar linkage's two ground pivots, for example, both anchor to the frame link. What is not supported is *two independent* static bases in a single mechanism (flagged as a configuration error); model the two pivots against a shared frame link, or split them into separate mechanisms. * The solver runs in a native core; the **Windows** Editor and Standalone player are supported out of the box. ## See Also * [Drive](/components-and-scripts/motion/drive) — the active axis every driven Kinematic Joint references * [Joint](/components-and-scripts/motion/joint) — the PhysX-based alternative for backward kinematics * [Kinematic](/components-and-scripts/motion/kinematic) — CAD hierarchy/pivot correction (unrelated despite the similar name) * [Kinematic Tool](/basics/user-interface/kinematic-tool-pro) — editor workflow for building mechanisms on CAD meshes \ © 2026 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # TransportSurface The TransportSurface component simulates conveyor belts and transport systems for moving objects through industrial automation processes. It provides physics-based movement of objects along defined transport paths, supporting both linear conveyors and rotational systems like turntables. For modeling conveyor systems with [MU](/components-and-scripts/mu-movable-unit) (Movable Units), TransportSurface provides the essential physics foundation. > ⚠️ **Note**:\ > For **standard speed-controlled accumulation conveyor systems**, you should use the **purely physics-based approach** with `TransportSurface`. > > \ > However, if this approach becomes unstable or imprecise—especially in **position-controlled systems** (e.g., driven by PLCs)—consider switching to a **guided transport** setup: > > * Use [`GuidedTransport`](/components-and-scripts/motion/guided-transport) for force-based control. > * Use [`KinematicMU`](/components-and-scripts/motion/kinematicmu-pro) for fully position-controlled, kinematic movement without violating physics constraints. A Transport Surface is always connected to a [Drive](/components-and-scripts/motion/drive) which controls the speed and position. The TransportSurface automatically detects and connects to Drive components in the parent hierarchy. {% hint style="info" %} If you are seeing instability with drives please check [Physics](/basics/physics#physic-solver-settings) as well as [Physics](/basics/physics#stability-of-transportsurfaces)in Section [Physics](/basics/physics). {% endhint %} ## Setup ### Basic Configuration 1. Add your conveyor GameObject with geometry (mesh or simple box) 2. Add a [`Drive`](/components-and-scripts/motion/drive) component to control movement direction and speed 3. Add `TransportSurface` component - it automatically connects to the Drive The TransportSurface automatically detects and connects to [`Drive`](/components-and-scripts/motion/drive) components in parent objects. {% embed url="" %} ## Properties ### Core Properties **Drive Reference** ([`Drive`](/components-and-scripts/motion/drive)): Optional override for automatic drive detection. Leave empty (null) for standard usage - the system automatically finds parent [`Drive`](/components-and-scripts/motion/drive) components. Use for special cases requiring specific drive connections. **Layer** (string): Physics layer assignment (default: "rvTransport") for transport simulation physics calculations. **Use Mesh Collider** (boolean): Controls collision precision vs performance. BoxCollider (default) provides better performance. MeshCollider enables precise collision for complex geometry. Changes apply immediately in Unity Inspector. ### Visual Properties **Advanced Surface** (boolean): Enables belt visualization with animated textures. Works with all geometry configurations including kinematic groups. **Animate Surface** (boolean): Enables texture animation synchronized with transport speed. **Texture Scale** (float): Texture animation speed multiplier in texture units per meter. ### Constraint Management **Change Constraints On Enter/Exit** (boolean): Modifies rigidbody constraints when objects enter/leave the transport surface. ### Hierarchical Systems **Parent Drive** ([`Drive`](/components-and-scripts/motion/drive)): For multi-axis systems where the transport surface moves relative to a parent drive (turntables, lifting conveyors). ## Collider Handling TransportSurface handles collision detection automatically - it uses existing colliders when available, or creates them automatically when needed. ### Collider Management **Existing Colliders**: If the TransportSurface GameObject already has colliders (BoxCollider or MeshCollider), they are used directly. **Kinematic Group Integration**: If the TransportSurface has a [`Kinematic`](https://github.com/game4automation/doc/blob/doc/components-and-scripts/kinematic.md) component with group integration enabled: * First searches for existing colliders within the kinematic group * If existing group colliders are found, they are reused for optimal performance * If no group colliders exist, creates a combined MeshCollider based on all meshes in the entire kinematic group **Automatic Creation**: If no colliders exist and no kinematic groups are configured, TransportSurface automatically creates them at runtime using this system: 1. **Standard Collision** * **BoxCollider** (Default): Fast, reliable collision for most conveyors * **MeshCollider** (Precise): Accurate collision matching for complex shapes * Automatically calculates the right size from your geometry 2. **Fallback** * Creates basic collision even when geometry is missing * Keeps your simulation running with warnings * Prevents common "objects fall through" issues {% hint style="info" %} **Collider Strategy**: TransportSurface respects your existing collider setup. If you've manually added colliders to the GameObject, they will be used as-is. Automatic creation only happens when no colliders are found. {% endhint %} ### Editor-Time Collider Switching When you toggle the **Use Mesh Collider** property in the Unity Inspector, the collider type switches immediately: * Provides visual feedback during development * Only affects the TransportSurface GameObject * Automatically handles component cleanup and creation ### Layer Management All transport surface colliders are automatically assigned to the **rvTransport** layer for physics calculations. The system validates layer assignments and warns about configuration issues that could affect performance. {% hint style="success" %} **Best Practice**: For complex CAD-imported conveyor systems, use the [`Kinematic`](https://github.com/game4automation/doc/blob/doc/components-and-scripts/kinematic.md) component with group integration. This improves performance by sharing colliders across grouped objects. {% endhint %} ## Advanced Surface The **Advanced Surface** option enables enhanced visual representation that now works with all geometry configurations: **Universal Geometry Support:** * **Simple Objects**: Uses direct MeshRenderer/MeshFilter components * **Kinematic Groups**: Automatically handles distributed geometry across grouped objects using [`Kinematic`](https://github.com/game4automation/doc/blob/doc/components-and-scripts/kinematic.md) components * **Complex Hierarchies**: Works with any renderer configuration in child objects When **Advanced Surface** is enabled, a child GameObject named **Belt** is created under the `TransportSurface`. This includes the `ConveyorBelt` component with animated texture effects that accurately follow surface geometry—including curves. The system automatically: * Calculates bounds from any geometry configuration (direct mesh, kinematic groups, or child renderers) * Hides original renderers appropriately based on the geometry setup * Provides error recovery if the ConveyorBelt prefab is missing * Handles both editor and runtime scenarios safely

Advanced Surface with enhanced geometry support

Advanced Surface texture animation

## Connecting Drives to Transport Surfaces TransportSurface features **automatic Drive detection** that makes setup effortless and intuitive: ### Automatic Drive Connection When you add a TransportSurface component: 1. **Flexible Drive Placement**: [`Drive`](/components-and-scripts/motion/drive) component can be on the same GameObject as TransportSurface or on any parent GameObject in the hierarchy 2. **Automatic Discovery**: The system automatically searches the current GameObject and then up the hierarchy for [`Drive`](/components-and-scripts/motion/drive) components 3. **Connection**: Found [`Drive`](/components-and-scripts/motion/drive) components are linked to the TransportSurface 4. **Visual Feedback**: The connection is visible in the Unity Inspector 5. **Automatic Setup**: Works for standard conveyor configurations {% hint style="info" %} **Drive Placement Options**: * **Same Level**: [`Drive`](/components-and-scripts/motion/drive) and TransportSurface on the same GameObject (simplest setup) * **Hierarchical**: [`Drive`](/components-and-scripts/motion/drive) on parent GameObject, TransportSurface on child GameObject (common for complex systems) {% endhint %} ### Drives above the TransportSurface Drive - using parent Drives {% hint style="info" %} *ParentDrives* is only needed if *IsKinematic* Drives are moving *TransportSurfaces* in a linear direction or rotational direction, e.g. for turn tables or lifting devices. {% endhint %} Sometimes Unity Physics is very difficult and the solution to master it is a little bit weird. As described in [Physics](/basics/physics) normal movements of a linear or rotational axis are not done based *IsKinematic* Rigidbodies. The transformation is done based on the Unity hierarchy and the position of [Unity’s Transform](https://docs.unity3d.com/ScriptReference/Transform.html) because this is usually much more stable. {% hint style="info" %} The Transport Surface is different from normal linear or rotational movements of an axis. It is using pure Unity physics functions for transporting the [MUs](/components-and-scripts/mu-movable-unit). {% endhint %} This causes one problem. If it is for example necessary to combine a linear or rotational movement with the Transport Surface itself this will cause problems. Unity will not move the Transport Surface [Collider](https://docs.unity3d.com/ScriptReference/Collider.html) as expected. To prevent this the option *ParentDrive* is available on the Transport Surface:
This option will automatically decouple the Transport Surface upon simulation start and will make a function as expected possible. During simulation, the Transportsurface will be without a parent in the top level of the hierarchy. You can see an example in the Demo model TurningAndLiftingTransportSurface which can be found under *realvirtual.io > Scenes*:
When you build up more complex kinematic structures, make sure to always keep the gameobject with the component transport surface parallel to the kinematic structure of the other drive belonging to the surface. An further expample model is MovingTransportSurface which can also be found under *realvirtual.io > Scenes.* The picture below shows how to define such a structure. The parent drive of the transport surface is the one which is the lowest in the kinematic structure.
{% hint style="info" %} If the parent drive of the transport surface is rotating, the pivot points (centre of rotation) of both objects must be in the same position for the movement to be transmitted correctly. If necessary, an empty GameObject must be inserted to achieve this. {% endhint %} ### Constraints of transported Objects You can choose if the constraints of objects which enter the transportsurface have to be changed or not. Setting the boolean *ChangeConstraintsOnEnter* or *ChangeConstraintsOnExit* to true will give the possibility to that.
{% hint style="warning" %} *When you change the constraints they will not be set back automatically to the former settings when the object leaves the transport surface. There you have to set ChangeConstraintsOnExit* true and define the values. Choosing *"None"* all contraints will be removed from the object. {% endhint %} ## Troubleshooting ### Objects Fall Through Transport Surface **Symptoms**: [MUs](/components-and-scripts/mu-movable-unit) pass through the conveyor instead of being transported **Solution**: Check the layer assignment in the Inspector - should be "rvTransport" **Causes and Solutions**: * **Layer Mismatch**: Click on the TransportSurface GameObject, check Layer dropdown in Inspector * **Missing Collider**: Enable "Use Mesh Collider" for complex geometry, or verify BoxCollider exists * **Kinematic Group Issues**: Ensure all CAD parts use the same `GroupName` in their [`Group`](https://github.com/game4automation/doc/blob/doc/components-and-scripts/group.md) components **Note**: Use automatic setup to avoid manual collider creation which can cause layer issues ### Poor Performance with Complex CAD Models **Symptoms**: Frame drops, sluggish physics, or slow conveyor response **Solution**: Add [`Kinematic`](https://github.com/game4automation/doc/blob/doc/components-and-scripts/kinematic.md) component and enable `IntegrateGroupEnable` **Performance Optimization Steps**: 1. Add [`Kinematic`](https://github.com/game4automation/doc/blob/doc/components-and-scripts/kinematic.md) component to the TransportSurface GameObject 2. Set `IntegrateGroupEnable = true` 3. Assign the same `GroupName` to all related CAD objects 4. Switch to BoxCollider if MeshCollider isn't essential **Performance Impact**: Can improve simulation speed by 10x for complex CAD assemblies ### AdvancedSurface Not Working **Symptoms**: Enhanced belt visuals don't appear or have wrong dimensions **Diagnosis**: Check Console for "ConveyorBelt prefab not found" errors **Solutions by Cause**: * **Missing Prefab**: ConveyorBelt prefab must exist in Resources folder * **No Geometry Bounds**: Add Renderer components or verify kinematic group setup * **Kinematic Group Issues**: Check that group names match across all [`Group`](https://github.com/game4automation/doc/blob/doc/components-and-scripts/group.md) components **Note**: Test AdvancedSurface with simple geometry first, then apply to complex models ### Drive Connection Issues **Symptoms**: Conveyor doesn't move, speed not synchronized, or no movement response **Solution**: Check that [`Drive`](/components-and-scripts/motion/drive) component exists on the same GameObject or parent GameObjects **Connection Troubleshooting**: 1. **Drive Placement**: [`Drive`](/components-and-scripts/motion/drive) must be on the same GameObject as TransportSurface OR on a parent GameObject (not sibling objects) 2. **Multiple Drives**: Set **Drive Reference** property to specify which [`Drive`](/components-and-scripts/motion/drive) to use 3. **Drive Configuration**: Verify [`Drive`](/components-and-scripts/motion/drive) component is enabled and properly configured 4. **Hierarchy Check**: Ensure TransportSurface can "see" the [`Drive`](/components-and-scripts/motion/drive) in its hierarchy path **Note**: Use supported hierarchy structures: * **Simple**: [`Drive`](/components-and-scripts/motion/drive) + TransportSurface on same GameObject * **Hierarchical**: [`Drive`](/components-and-scripts/motion/drive) (parent) → TransportSurface (child or descendant) {% hint style="success" %} **Performance Tip**: For large-scale transport systems, group related CAD objects using the [`Kinematic`](https://github.com/game4automation/doc/blob/doc/components-and-scripts/kinematic.md) component. This eliminates individual colliders and can improve performance by 10x. {% endhint %} © 2025 realvirtual [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Guided Transport realvirtual.io 2022.03 and above TransportSurfaces are ideal for modeling standard conveyor systems. However, for rail-based systems or systems with numerous colliders for making curves, stable modeling may not be achievable using TransportSurfaces. As an example, please check the following system, where the MUs are moving in a stable manner on the conveyor system. MUs can also be stopped by physical stoppers (based on colliders). > 💡 **Note**:\ > If your transport surface is **position-controlled** (e.g., updated by a PLC), using standard `GuidedMU` may lead to physics instability.\ > In such cases, switch to a **kinematic approach** using `KinematicMU` for smooth and reliable transport.\ > See [KinematicMU ](/components-and-scripts/motion/kinematicmu-pro)for setup and usage details.
In such cases, Guided Transports come to the rescue. They offer limited transport direction and position, following guide lines that can be linear or circular. There are two options for using Guided Transports. First, you can make Guided Transports children of TransportSurfaces by adding GuideLines or GuideCircles. This allows you to retain the standard animation features of the surface itself. Alternatively, you can use the TransportGuided Prefab, which combines a drive, the necessary GuideLine or GuideCircle, and all required colliders in a single component. This is especially useful for overlaying on an existing imported CAD Design. You can find a tutorial about Guided Transports on Youtube: {% embed url="" %} Guilded Transport Tutorial {% endembed %} ## Demo Scene

Demo Scene

A special demo scene showcases various demonstrations of guided transports, including lifting objects using Guide Transports, such as chain systems. You can access this demo scene through the main menu by navigating to `Tools > realvirtual > Additional Demos > Guided Transport`. Explore the different scenarios to see the capabilities and applications of Guided Transports in action. ## Prerequisites - GuidedMU

GuidedMU

To utilize Guided Transport, you must ensure that all [MUs ](/components-and-scripts/mu-movable-unit)(Moving Units) have a `GuideMU` script attached to them. The recommended approach is to add this script to the [Source](/components-and-scripts/mu-movable-unit/source), as shown in the picture. Guided Transports rely on colliders and raycasts to detect the Guide Lines. Therefore, it's necessary to define the raycast length and layers appropriately to ensure proper functionality. {% hint style="info" %} The raycast in the Guided Transport system will always be performed downwards in the Global Z direction. This ensures that even Moving Units (MUs) that may be tumbling or moving erratically will still be able to detect the colliders accurately and be snapped to the Guide Lines. {% endhint %} The standard components used in Guided Transport are `rvTransport`, which combines Guide Lines with [TransportSurfaces](/components-and-scripts/motion/transportsurface), and `rvSimStatic`, which is utilized for TransportGuided Components. The `rvSimStatic` component is especially useful when you want to avoid collisions with the [MUs ](/components-and-scripts/mu-movable-unit)detected by the detection collider. ## Guided Transport with TransportSurface `TransportSurfaces` can be extended by GuideLines. This will snap MUs as soon as the `GuidedMU` raycast are detecting the `TransportSurface`. The MU is always aligned and snapped to the nearest point on the `TransportSurface`. The speed is taken from the `TransportSurface`. You need just to add an empty Gameobject underneath the `TransportSurface` and add the `GuideLine` or `GuideCircle` component to it. Alternatively you can use the overlay menu or the main menu (e.g. `Tools > realvirtual > Add Object > GuideLine`)

GuideLine as children under a TransportSurface

Besides the GuideLine also GuideCircle is available for circular movements.

GuideLine as children under a TransportSurface

## TransportGuided A convenient alternative for implementing Guided Transport is to use the `TransportGuided` Component. This single Prefab component simplifies the process by combining a Drive and the `TransportGuided` script into one entity. Additionally, it automatically creates the necessary colliders and either a `GuideCircle` or *GuideLine*, depending on the configuration. To add a TransportGuided component: 1. Drag and drop the prefab into the scene, or 2. Use the main menu: Tools > realvirtual > Add Object > TransportGuided, or 3. Use the overlay menu.

TransportGuided Circular

### Properties #### Circular True for circular guide lines. #### Radius (Circular) The radius of the guide line. #### Angle (Circular) The angle of the guide line. #### Collider Border Z (Circular) The border in Z direction to the side on the entry of the guide line. #### Collider Border X (Circular) The border in X direction to the side on the exit of the guide line. #### Length (Linear) The length of the linear guide line. #### Height The height of the component. Zero Point of the component is always the start of the guide line or guide circle. #### Width (Linear) The width of the collider for linear guide lines. #### DistanceCollider The distance between the collider and the guide line. The collider should be always a little bit underneath the guide line. #### ShowGizmos True if the Gizmos for the collider and guide lines should be shown.

TransportGuidedLinear

# Chain Chains move components along spline paths or simulation paths for material handling systems, tool changers, and other applications requiring continuous linear motion. {% hint style="info" %} **New Feature**: Burst Compiler optimization was added in realvirtual **6.0.9** (beta) providing 20-33x performance improvements for chain simulations. {% endhint %} ## Overview Chains provide continuous movement of multiple components along a defined path. This is useful for modeling material handling systems or tool changers that are driven by chains. They are always connected to a Drive component that controls the chain's movement speed and position. Chain elements are automatically created and positioned along the spline during simulation. {% hint style="success" %} **Recommended path definition: Unity Splines.** Add a Unity `SplineContainer` component to the same GameObject as the Chain component. This is the only path definition that receives bug fixes and performance improvements. {% endhint %} {% hint style="danger" %} **Deprecated: legacy point-and-tangent spline.** The older custom spline system (`Spline` component with `P1..Pn` child GameObjects holding `InTangent`/`OutTangent` transforms) is no longer maintained. Existing scenes keep working, but it does not receive bug fixes — known issues include non-symmetric element placement and drift when two chains share one drive. Please migrate to a Unity `SplineContainer`. The `DemoChain` scene shows both variants side by side; `Chain_UnitySplineHorizontal` and `Chain-UnitySplineVertical` are the reference setups. {% endhint %} {% hint style="warning" %} Simulation path functionality requires realvirtual Simulation, which is not included in the base realvirtual package. There are separate demos for this in realvirtual Simulation. {% endhint %} You can find a demo scene at `Assets/realvirtual/Scenes/DemoChain` demonstrating chain functionality. ### Basic Concepts A chain is always connected to a drive, so the movement of the chain depends on the current drive position and speed. Usually, you should use a Drive with the Axis set to Virtual to move the chain. One or several Chain Elements are connected to the chain. These Chain Elements are created automatically upon simulation start by the chain. Usually, these chain elements should be Prefabs within your project. The Chain script requires an `IChain` implementation on the same GameObject. Use the Unity `SplineContainer` (via the `ChainUnitySpline` component) to define the path. The legacy point-and-tangent spline is deprecated — see the warning at the top of this page. ## Properties ### Settings #### Chain Orientation Determines whether the chain moves horizontally or vertically. * **Type**: Enum (Horizontal, Vertical) * **Default**: Horizontal * **Use case**: Set based on your mechanical system orientation #### Chain Element Prefab used for individual chain elements along the spline. * **Type**: GameObject reference * **Default**: None * **Use case**: Assign your custom chain link or carrier prefab #### Connected Drive Drive component that controls chain movement. * **Type**: Drive reference * **Default**: None * **Use case**: Connect to a Drive with Virtual axis for chain control #### Number of Elements Total number of chain elements created along the spline. * **Type**: Integer * **Default**: 10 * **Range**: 1 to 1000 * **Use case**: Adjust based on spline length and element spacing needs #### Start Position Offset position along the spline where the first element is placed. * **Type**: Float * **Default**: 0 * **Range**: 0 to spline length * **Use case**: Adjust starting position for alignment with mechanical systems #### Calculate Delta Position Automatically calculates spacing between chain elements. * **Type**: Boolean * **Default**: true * **Use case**: Enable for even distribution, disable for custom spacing #### Scaled On Fixed Length Maintains constant total spline length for external drive positioning. * **Type**: Boolean * **Default**: false * **Use case**: Enable when external drives provide positional data for elements ## Performance Optimization ### Burst Compiler Optimization {% hint style="info" %} This feature was added in realvirtual **6.0.9** (beta) {% endhint %} The Chain component supports Unity's Burst Compiler for dramatically improved performance when simulating large numbers of chain elements. This optimization uses SIMD (Single Instruction, Multiple Data) compilation to native code, providing: **Performance Benchmarks:** * **Kinematic elements** (MoveRigidBody=false): **29-33x speedup** * **Physics elements** (MoveRigidBody=true): **19-23x speedup** #### How It Works Burst optimization operates in two modes depending on your chain element configuration: **Kinematic Mode (Maximum Performance)** * Uses Unity's TransformAccessArray for parallel batch processing * Ideal for visual chain elements without physics interactions * Achieves 29-33x performance improvement * Set **MoveRigidBody=false** on ChainElements to use this mode **Physics Mode (High Performance)** * Uses traditional Rigidbody updates with Burst-compiled calculations * Required when chain elements need collider interactions * Achieves 19-23x performance improvement * Set **MoveRigidBody=true** on ChainElements for physics #### Setup Instructions **One-Click Setup (Recommended)** If Burst optimization is not enabled, you'll see a warning message in the Chain Inspector with performance information and a setup button.

Chain Inspector showing Burst optimization not enabled with one-click setup button

1. Click **Enable Burst Optimization (Install Package & Define)** button in the Chain Inspector 2. Unity will automatically: * Install the Burst Compiler package * Add `REALVIRTUAL_BURST` to Script Compilation Symbols * Recompile scripts with Burst optimization enabled 3. Restart Unity if prompted **Manual Setup** 1. Install Unity Burst Compiler package via Package Manager 2. Add `REALVIRTUAL_BURST` to **Project Settings > Player > Script Compilation Symbols** 3. Unity will automatically recompile with Burst optimization **After Setup** Once enabled, the Chain Inspector displays confirmation of active optimization:

Chain Inspector with Burst optimization enabled showing performance tips

#### Optimizing Chain Elements For maximum performance, configure your ChainElements based on their purpose: **Visual-Only Elements (Fastest)** * Set **MoveRigidBody=false** on the ChainElement component * Use for chain links, carriers, or fixtures that don't need physics * Achieves 29-33x speedup with kinematic batch processing **Physics-Interactive Elements** * Set **MoveRigidBody=true** on the ChainElement component * Required for elements with colliders that interact with other objects * Still achieves 19-23x speedup with Burst-optimized physics updates

ChainElement Inspector showing MoveRigidBody property with performance guidance

The ChainElement Inspector provides inline performance tips to help you choose the right setting. #### Advanced Settings **Spline Bake Resolution** * Controls the number of pre-calculated spline samples used by Burst jobs * Higher values = smoother interpolation but more memory usage * Default: 100 samples * Adjust based on spline complexity and available memory **Use Burst Optimization** * Enable/disable Burst processing at runtime * Defaults to enabled when REALVIRTUAL\_BURST is defined * Useful for performance comparisons or debugging #### Common Use Cases **High-Speed Bucket Elevators** * Set MoveRigidBody=false on buckets for 29-33x speedup * Buckets follow path without physics interaction * Ideal for material transport visualization **Overhead Conveyors with Load Detection** * Set MoveRigidBody=true on carriers for physics-based load pickup * Still achieves 19-23x speedup while maintaining collision detection * Necessary when carriers interact with sensors or parts **Mixed Configuration** * Combine kinematic and physics elements in the same chain * Use physics only where needed (e.g., pickup/drop zones) * Optimize performance while maintaining required functionality #### Technical Details Burst optimization works by: 1. Pre-calculating spline positions and tangents into native arrays 2. Batch-processing all element position updates in parallel 3. Using SIMD instructions for vectorized calculations 4. Minimizing managed-to-native transitions The system automatically handles: * Spline position interpolation * Tangent calculation for element orientation * Batch updates synchronized with drive events * Memory management for native arrays ## Usage Examples ### Basic Chain Setup 1. Create a spline path using Unity Splines or custom spline 2. Add **Chain** component to the spline GameObject 3. Add **ChainUnitySpline** component for Unity Splines integration 4. Assign **Chain Element** prefab 5. Connect to a **Drive** component with Virtual axis 6. Set **Number of Elements** based on your requirements ### Unity Splines Integration We recommend using Unity Splines for the chain. To do so, the Unity Splines package must be installed. Once the Unity Splines package is installed, the chain can be defined as follows: 1. In **Project Settings > Player**, add `REALVIRTUAL_SPLINES` under Script Compilation Symbols to use Unity Splines with realvirtual chains 2. Right-click in the Hierarchy and select the desired base spline from the **Spline** menu 3. Unity provides a Spline editing mode in the Scene view for adjusting spline control points. For each spline control point, Unity also shows the up direction at the point (red arrow). This is relevant if you want to set up a vertical chain 4. Add the **ChainUnitySpline** and **Chain** components to the created GameObject Once the chain is set up, it can be used with ChainElements and drives. ### Vertical Chain Configuration To construct a vertical chain, follow these steps: 1. Build the spline in the positive Z direction, starting from the bottom-right anchor point, and continue clockwise 2. Maintain a vertical angle of exactly 90 degrees. Avoid inclinations to prevent misalignment with interpolated curves representing the height difference 3. Note that these instructions are currently applicable only to splines with four anchor points and not more 4. Ensure that the front of the chain element also faces in the positive Z direction. This orientation is necessary for the parent GameObject 5. Set **Chain Orientation** to Vertical > **💡 Hint**\ > For vertical chains, use exactly four anchor points and maintain precise 90-degree angles to prevent misalignment with interpolated curves. ## Editor Tools ### Spline Construction (deprecated) {% hint style="danger" %} This section describes the legacy point-and-tangent spline. It is no longer maintained — please use Unity Splines instead. The description is kept here as a reference for existing scenes. {% endhint %} For extending a spline or creating a first point, you can click the **Extend** button on the Spline. This generates a Point with 2 included Tangent points. You can move these points like any GameObject to construct your spline. The order of these GameObjects also defines the order of the points in the spline. If you select **Loop**, the spline is closed and the last point is connected to the first point of the spline. ### Unity Splines Editor * Visual spline editing in Scene view * Control point manipulation with handles * Up direction indicators (red arrows) for vertical chain setup * Real-time spline preview and adjustment ## See Also * [Chain Element](/components-and-scripts/motion/chain-element) - Individual elements moving along the chain * [Drive](/components-and-scripts/motion/drive) - Motor control for chain movement * [Spline documentation](https://docs.unity3d.com/Packages/com.unity.splines@latest) - Unity Splines package reference *** © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Chain element Chain Elements represent individual links, buckets, or carriers in continuous chain transport systems. {% hint style="info" %} **New Feature**: Burst optimization support was added in realvirtual **6.0.9** (beta). Configure **MoveRigidBody** for optimal performance based on your physics needs. {% endhint %} ## Overview Chain Elements are the individual components that move along a chain path. Each element is automatically created and managed by the parent Chain component during simulation. Chain elements can be simple visual representations or physics-enabled objects that interact with other simulation elements. Most properties are automatically calculated by the Chain component, with key configuration options for alignment and physics behavior. ## Properties ### Settings **Align With Chain** (boolean) controls whether the element automatically rotates to follow the chain's tangent direction during movement. Enable this for realistic chain behavior where elements orient along the path. **Move Rigid Body** (boolean) determines whether physics simulation is enabled for the chain element. When enabled, the element's Rigidbody is actively moved and can interact with colliders. When disabled, only the transform is updated for visual representation, providing 29-33x performance improvement with Burst optimization compared to 19-23x with physics enabled.

ChainElement Inspector showing MoveRigidBody property with Burst optimization performance guidance

**Align Vector** (Vector3) defines the local axis used as the basis for alignment calculations when Align With Chain is enabled. This vector determines which direction on the element should point along the chain tangent. **Align Object Local Z Up** (GameObject) optionally specifies a reference object whose forward direction defines the up vector for element alignment instead of using Align Vector. **Debug Directions** (boolean) enables visual debugging in the Scene view showing the tangent direction (green) and up direction (red) for troubleshooting alignment issues. **Initial Position** (float) sets the starting position of the chain element along the chain path in millimeters, configured by the Chain component during element creation. **Offset To Drive Position** (float) adds a position offset in millimeters relative to the connected drive's position, useful for fine-tuning element placement. **Connected Chain** (Chain reference) manually links to a specific Chain component. Leave this null for automatically generated elements, which are connected by the Chain during creation. ## Performance Optimization ### Burst Compiler Support Chain Elements support Unity's Burst Compiler optimization when the parent Chain has Burst enabled. Configure the **MoveRigidBody** property based on your performance and physics requirements: **Visual-Only Elements (Maximum Performance)** * Set **MoveRigidBody = false** * Elements follow the chain path without physics interaction * Achieves 29-33x speedup with Burst optimization * Use for decorative chain links, visual carriers, or non-interactive elements **Physics-Interactive Elements** * Set **MoveRigidBody = true** * Elements can collide with and move other objects * Achieves 19-23x speedup with Burst optimization * Required when elements need to push parts, trigger sensors, or interact physically The Chain Element Inspector displays performance guidance to help you choose the optimal setting for your use case. ## Common Use Cases **Bucket Elevator Buckets** * Set MoveRigidBody=false for visual-only material transport * Buckets follow the elevator path without physics overhead * Maximum 29-33x performance with Burst optimization **Overhead Conveyor Carriers** * Set MoveRigidBody=true when carriers need to interact with sensors * Physics enables collision detection for load pickup/drop * Maintains 19-23x speedup while preserving functionality **Chain Links** * Set MoveRigidBody=false for decorative chain visualization * Pure visual representation without collision calculations * Optimal performance for large chain installations ## Alignment Configuration Chain elements can align with the chain path in two modes: **Vector-Based Alignment** * Uses the **Align Vector** property to define orientation * Specify which local axis should point along the tangent * Common settings: (1,0,0) for X-axis, (0,1,0) for Y-axis **Object-Based Alignment** * Uses **Align Object Local Z Up** reference object * The referenced object's forward direction becomes the up vector * Useful for complex orientation requirements Enable **Debug Directions** to visualize: * Green ray: Chain tangent direction (forward) * Red ray: Up direction used for alignment

Chain Element component in Unity Inspector

## Integration Notes **Automatic Creation** * Chain elements are typically created automatically by the Chain component * Number and spacing defined by Chain properties * Elements are instantiated from the prefab specified in Chain settings **Manual Placement** * For manually placed elements, assign the **Connected Chain** reference * Useful for specialized elements at specific positions * Manually placed elements coexist with auto-generated ones **Drive Synchronization** * Elements automatically synchronize with the connected drive speed * Position updates occur during drive calculations * Batch processing optimizes performance for multiple elements ## See Also * [Chain](/components-and-scripts/motion/chain) - Parent component managing chain element creation and movement * [Drive](/components-and-scripts/motion/drive) - Controls chain speed and position \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # PathTracer (Pro) {% hint style="info" %} This feature was added in realvirtual **6.0.7** (Professional) {% endhint %} **PathTracer** visualizes object movement paths with speed-based coloring, creating colorful trails behind moving objects like robot arms to help analyze and validate motion patterns.

PathTracer showing robot arm movements with speed-based colors

## Overview Add the PathTracer component to any moving object (robot TCP, conveyor parts, etc.) to see its path visualized in real-time during play mode. The trail color changes based on movement speed, making it easy to identify acceleration, deceleration, and constant-speed phases. ## Key Settings

PathTracer Inspector showing configuration options

**Trail Configuration** * **Enable Trail** – Turn trail visualization on/off * **Trail Time** – How long trail remains visible (60 seconds shown in example) * **Start/End Width** – Trail thickness in millimeters (20mm in example) * **Trail Material** – Material for rendering (TCPTrailMaterial in example) **Speed-Based Coloring** * **Slow Color** – Color for minimum speed (yellow in example) * **Fast Color** – Color for maximum speed (magenta in example) * **Min/Max Speed** – Speed range in mm/s for color mapping (0-2000 mm/s in example) **Performance** * **Minimum Vertex Distance** – Distance before adding new trail point (10mm reduces complexity) * **Play Mode Only** – Trail only visible during play mode ## Quick Start 1. Add PathTracer component to robot TCP or moving object 2. Enable "Speed Based Coloring" 3. Set Slow Color (e.g., yellow) and Fast Color (e.g., magenta) 4. Configure Max Speed based on your robot/object (e.g., 2000 mm/s) 5. Press Play to see motion trails ## Common Use Cases * **Robot Path Validation** – Verify arm movements follow expected trajectories * **Speed Analysis** – Identify acceleration/deceleration phases by color * **Cycle Time Optimization** – Compare different motion profiles visually * **Safety Review** – Check for unexpected movements or collision paths ## See Also * [Drive](/components-and-scripts/motion/drive) - Motion control component * [TransportSurface](/components-and-scripts/motion/transportsurface) - Conveyor and transport systems * [Runtime UI](/basics/runtime-ui) - Runtime user interface features # KinematicMU (Pro) Included since realvirtual.io Professional 6.2.2 beta The `KinematicMU` component enables **purely kinematic movement** of [Moving Unity (MUs) ](/components-and-scripts/mu-movable-unit)along a [`GuidedTransport`](/components-and-scripts/motion/guided-transport). This is essential in scenarios where **position-controlled transport surfaces** are used (e.g., from a PLC), and traditional physics-based transport would violate physical constraints due to rapid or unpredictable position updates. `KinematicMU` allows sensor interaction but **disables collisions** with other colliders or MUs during guided motion. This makes it ideal for precision transport systems or integration with external control systems like PLCs. ## Use Case Standard [`GuidedMU`](/components-and-scripts/motion/guided-transport) movement applies forces and obeys Unity physics. This works well in most guided transport scenarios but fails for **position-driven conveyor belts** that update positions in cycles. In these cases, using physics-based motion can lead to instability or incorrect behavior.

KinematicMU demo model

#### Setup Instructions 1. **Prefab**: Use the standard `TransportGuided` prefab\ Path: `Assets/realvirtual/TransportGuided.prefab` 2. **Scene**: Try the demo scene to see it in action\ Path: `Assets/realvirtual/Professional/KinematicMU/DemoKinematicMU.unity` 3. **Material Unit (MU) Setup**: * Add the `KinematicMU` script to your MU GameObject. * Remove the `GuidedMU` script (if present). * Keep the `MU` and `Source` components. * Ensure a `Rigidbody` is present (used for switching modes). * Assign appropriate layers to the **Raycast Layer** (typically `rvTransport`, `rvSimStatic`).
#### Inspector Properties | Property | Description | | ------------------ | ------------------------------------------------------------------------------------------ | | **Active** | Controls whether the MU should behave kinematically (`Always`, `Never`, or conditionally). | | **Raycast Length** | Distance for downward raycast to detect the transport surface. Default is `0.3`. | | **Raycast Layer** | Layers that are considered for detecting transport surfaces. | | **Debug Mode** | Enables debug visualization of raycasts. | # MU Behavior Switcher # Motion for developers ## **Sequence of FixedUpdates** When developing custom behavior models for drives, understanding the sequence of FixedUpdates is crucial for ensuring correct behavior and performance. * **Physics Update Cycle**: All [drive behavior](/components-and-scripts/motion/drive-behavior) calculations and setting of new drive positions occur within Unity's physics update cycle. By default, this cycle is set to 20ms, but it can be adjusted in the Unity settings based on performance and calculation requirements. * **FixedUpdate Sequence**: Unity executes FixedUpdate methods for all scripts within each physics cycle. However, the execution order of these FixedUpdates is not guaranteed. This means FixedUpdate in one script (Script1) could be called before or after FixedUpdate in another script (Script2). * **Dependency Management**: For behavior models that depend on other components—such as Gears or [CAMs](/components-and-scripts/motion/cam)—it is essential that dependencies are calculated in a specific order. For instance, the master Drive should be calculated before its dependent slave Drive. Moreover, behavior models of the master Drive need to be processed before the master Drive's position is updated. To ensure the correct sequence each Drive is implementing the following behavior: 1. **Drive Behavior Execution**: Each Drive calls `CalcFixedUpdate`of all attached drive behaviors that implement the`IDriveBehavior` interface. 2. **Behavior Model Calculation**: The attached behavior model may modify public properties of the Drive to control its status or directly set the `CurrentPosition` of the Drive. 3. **Position Update**: The Drive then updates its position to the `CurrentPosition`. 4. **Subdrive Calculations**: All subdrives of the Drive will have called their CalcFixedUpdate (see below). ## **Subdrives** Some Drives function as subdrives of a master Drive, such as in the case of Gears or CAMs. To ensure proper behavior, these drives need to implement the `IDriveBehavior` interface. Additionally, during the `Start` method, the subdrive must call `MasterDrive.AddSubDrive(thisDrive)`. This setup ensures that the subdrive does not run its own FixedUpdate but instead waits for the master Drive to invoke CalcFixedUpdate like explained above. ## Setting a Drive Position As previously discussed, within the Drive and Drive Behavior Execution cycle, a Drive Behavior can set the public property `CurrentPositio`. Due to the described sequence, this approach ensures that the position is updated correctly. There is also a public method `SetPosition(float position)` available on Drives. When this method is called, the Drive will set its position once again, even if the sequence described above for that Drive has already been completed in the same FixedUpdate cycle. **Important Note:** Calling `SetPosition` directly is not the recommended approach. It is better to implement your logic by using the `IDriveBehavior` interface within your behavior model attached to the Drive. This approach ensures that the Drive position updates occur in a controlled and predictable manner, adhering to the established sequence of FixedUpdates. ## Drive Events The Drive has two key events that you can utilize to hook into its update sequence: * **OnBeforeDriveCalculation:** This event is triggered before the Drive begins calculating its behavior models and updating its position. It's an ideal point to inject custom logic or make adjustments before the Drive's primary calculations occur. * **OnAfterDriveCalculation:** This event is called after the Drive has completed all behavior model calculations and updated its position, but before any SubDrives are calculated. This allows you to make further modifications or perform actions right after the main Drive update but still within the overall update sequence. By using these events, you can effectively integrate custom behavior or adjustments into the Drive's update process.

Drive Events

# Sensors Components for detecting objects, measuring positions, and providing feedback in automation systems. ## Available Components * [**Sensor**](/components-and-scripts/sensors/sensor) - Primary proximity sensor for detecting MUs and objects with configurable detection zones * [**Measure**](/components-and-scripts/sensors/measure) - Position and distance measurement sensor for precise object positioning * [**MeasureRaycast**](/components-and-scripts/sensors/measureraycast) - Raycast-based distance measurement for precise range detection ## Key Features * **PLC Integration**: Direct connection with PLCOutputBool and PLCOutputFloat signals * **Visual Feedback**: Editor gizmos and runtime visualization of detection zones * **Configurable Detection**: Adjustable zones, timing delays, and object filtering * **Logic Integration**: Works with Logic Steps and Behavior Graph systems ## See Also * [Logic Steps](/components-and-scripts/defining-logic/logicsteps) - Automation sequences using sensor inputs * [Interfaces](https://github.com/game4automation/doc/blob/doc/components-and-scripts/interfaces/README.md) - PLC communication for sensor data # Sensor Sensors are detecting [MUs](/components-and-scripts/mu-movable-unit). The sensor can use BoxColliders or Raycasts for collision detection.\ A behavior component (e.g. Sensor\_Standard) must be added to the Sensor for a connection to a PLC’s Input and Outputs. This tutorial explains first steps with Sensors: {% embed url="" %} Tutorial about adding Sensors to your Digital Twin {% endembed %} This picture shows a configured Sensor using Colliders in the demo model:
### Sensor using Colliders Because collisions are used to detect the Sensor status you need to take care that the sensor game object is on the appropriate collision layer which should be normally *g4aSensor*. {% hint style="info" %} Because of limitations in the collision detection of Mesh Colliders you should always use Box Colliders with Sensors. {% endhint %} The Sensor can change the color by changing the material of the sensor. For this, you need to select *Display Status*. ### Sensor using Raycasts Another way for implementing Sensors is to use Raycasts. The advantage of a Raycasts is, that you don’t need to define colliders and you are totally free which Layers you would like to check with the Raycast. Because there is no sensor geometry connected to a Raycast Sensor you need to define the *Raycast Direction* from the pivot point of the Gameobject and the *Raycast length*, as usual in mmm in realvirtual.io. In the game view the Raycast is shown as a Line Renderer which is automatically created on simulation start. {% hint style="info" %} If the sensor is using Raycasts, the Raycast is always checked against colliders on the same Layer then the Sensor Gameobject itself. Optionally you can define *additional Raycast Layers*. **Raycast always needs to start before the collission with the detected component. Please make sure that the start of the sensor raycast is never inside of an object with needs to be detected.** {% endhint %}
## Common functions for Sensors using Colliders or Raycasts It is possible to limit the sensor function to a certain Tag of the [MU](/components-and-scripts/mu-movable-unit). You must enter the Tag in the property *Limit Sensor To Tag*. The current sensor status can be inspected under the section *Sensor IO’s*. Please check the [Realvirtual.io Class Reference](https://game4automation.com/documentation/current/apidoc/html/classgame4automation_1_1_sensor.html) for more information about the properties and methods of this component. You can subscribe to the Unity Events on the Sensor. *Event MU Sensor* is called on every MU detected by the Sensor. *Event Non MU Gameobjet Sensor* is called for all colliders without an MU script that are colliding with the Sensor.
## Sensor Status Besides the color of the sensor you can check the state of the sensor in the section *Sensor Status* in the Inspector of the Sensor.
## Sensor\_Standard The Sensor\_Standard component provides the standard Sensor behavior and connectivity to the PLC inputs and outputs. With the property *NormallyClosed=true* it can be selected, as the sensor is true and the sensor is not occupied. {% hint style="info" %} The Sensor\_Standard is a blueprint for additional sensors that return various values such as distance, speed etc. to the PLC. We suggest you use this template as the starting point for building your own sensors. {% endhint %} \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Measure Measure is measuring distances between the pivot point of the Gameobject, the Measure script is attached to and another pivot point of a referenced Gameobject. You can also connect the result of the measurement to a PLCInput Signal. By doing this Measure is able to act as a distance sensor.
You can apply the following properties: | Property | Description | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Measure From | Gameobject the measurement should be performed from to this object. | | Distance | (Readonly) The measured distance as a vector. | | Distance Abs | (Readonly) The measured distance as an absolute value. | | Set Distance | A distance that should be set by the button Set Distance | | Keep Set Distance | If set to true the SetDistance value is always set to the related Gameobject so that the distance between the two objects always keeps the same. | | Display On Selected | Display the measurement only when the measurement object is selected. | | Display Always | Display the measurement always. | | Display Line | Display a line between the Pivot Points in scene view. | | Display Abs | Display the absolute value as a number in scene view. | | Display Vector | Display the vector as numbers in scene view. | | Use Millimeters | Display one Unity Unit as 1000. | | PLCSignalOffset | Offeset to the MeasuredDistance. | | Measured Distance | PLCInputFloat signal for the absolute distance. | | Measured DistanceX | PLCInputFloat signal for the DistanceX part of the Vector. | | Measured DistanceY | PLCInputFloat signal for the DistanceY part of the Vector. | | Measured DistanceZ | PLCInputFloat signal for the DistanceZ part of the Vector. | \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # MeasureRaycast MeasureRaycast is measuring distances between the pivot point of the Gameobject, the MeasureRaycast script is attached to and a collider or between two colliders. MeasureRaycast is using the Unity Raycast system for sending rays ino the desired direction and detecting collisions and distances. You need to attach a collider to the 3D meshes you want to detect. You can also connect the result of the measurement to a PLCInput Signal. By doing this MeasureRaycast is able to act as a sensor.
You can apply the following properties: | Property | Description | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | RaycastDirection | The direction of the Raycast in local coordinate system | | Measure between colliders | If set to true the measurement is not performed between the pivot point and a collider. Instead rays are set into two directions from the pivot point and the distance between the two detected collisions is measured. | | Raycast Length | Defines the maximum length of the raycast in one direction. If you measure between two colliders the total measured maximum distance is twice this given distance. | | Display Raycast | Needs to be set to true if you want to see a line in Scene window for the raycast. The line will be red on collision and yellow if no collision is detected. | | Raycast to layer | The raycast is always performed only on one layer. As default it is the Default Layer. If you colliders are on a different Layer you need to change this. | | Use Millimeters | If set to true as a result one Unity Unit will be transformed to 1000. | | PLCSignalOffset | A signal offset value which is added to the measurement result. | | DisplayDistance | Displays the distance of the raycast in Scene Window. | | Measured Distance | The measured distance as PLCInputFloat. It is 0 if no collision is detected. | | Raycast Hit | A PLCInputBool which will be true if the raycast hits an object. | \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Collision Detection realvirtual provides group-based collision detection for monitoring physical contacts between defined sets of objects during simulation. ## Components | Component | Description | Edition | | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- | ------------ | | [Group Collision Checker](/components-and-scripts/collision/group-collision-checker) | Runtime collision detection between named groups with GPU highlight and PLC signals | Professional | ## Concept The collision detection system builds on the [Group](/components-and-scripts/motion/group) component. You assign objects to named groups, then the GroupCollisionChecker monitors cross-group contacts while suppressing self-collision within each group. This is particularly useful for: * Detecting robot-to-machine collisions without false alarms from internal joints * Monitoring gripper-to-fixture contact * Safety zone violation detection * Multi-robot workspace overlap monitoring # Group Collision Checker (Pro) ## Overview The **GroupCollisionChecker** detects runtime collisions between named realvirtual groups. Objects within the same group never collide with each other (self-collision is suppressed), while objects from different groups trigger collision events automatically. This is useful for monitoring whether a robot arm collides with machine fixtures, or a gripper penetrates a workpiece holder — without false alarms from joints within the same kinematic chain.
Group Collision Checker detecting a robot colliding with the machine door

Collision between the robot group and the machine door is detected and highlighted in real time

{% hint style="info" %} This feature was added in realvirtual **6.3.0** (Professional) {% endhint %} ## How It Works The system uses a single dedicated physics layer (`rvCollissionCheck`) that is isolated from all other realvirtual layers (sensors, transport surfaces, sinks). Within that layer: * **Same-group** collider pairs are suppressed via `Physics.IgnoreCollision` * **Cross-group** collider pairs trigger collision events automatically * Only **one** physics layer is consumed regardless of how many groups you define This design avoids layer exhaustion and prevents side effects on sensors or transport systems. ## Quick Start 1. Add a **GroupCollisionChecker** component to any GameObject in your scene 2. Add entries to **Collision Groups** — each entry is a realvirtual Group name plus a collider mode 3. Optionally assign a **MultiObjectOverlayRendererFeature** reference for GPU-based highlighting 4. Press Play — collisions are detected and reported via signals, events, and Inspector status ## Properties ### Collision Groups **Collision Groups** (list) The groups to monitor. Each entry defines: * **Group Name** — the realvirtual Group name (as assigned via the Group component) * **Collider Mode** — how colliders are created for objects in this group: * **BoxApproximation** — creates a BoxCollider from the renderer bounds. Fast and safe, but coarse. * **MeshCollider** — creates a convex MeshCollider. More accurate, uses the convex hull (max 255 vertices). * **ExistingOnly** — uses only already-present colliders. Objects without a collider are skipped. ### Settings **Auto Setup On Start** (boolean) When enabled, the collision system initializes automatically when the simulation starts. Disable this to call `SetupCollisionSystem()` manually from script. ### Highlight **Highlight On Collision** (boolean) Enables GPU-accelerated visual highlighting of colliding objects via the URP Overlay Renderer Feature. **Overlay Feature** (reference) Assign a dedicated `MultiObjectOverlayRendererFeature` instance from your URP Renderer Asset. This must be a separate instance from the one used by the Selection system. **Highlight Color** (Color) The highlight overlay color applied to colliding objects. Default: red. **Overlay Mode** (enum) The rendering style for the highlight: Default, XRay, or Blink. **Blink Speed** (float) Blink frequency in cycles per second when Overlay Mode is set to Blink. **Reset Mode** (enum) Controls when highlights are removed: * **WhileColliding** — highlight disappears automatically when collision ends * **OnEnterPersistent** — highlight stays until manually reset via the ResetHighlight signal ### Interface Connection (PLC Signals) **CollisionActive** (PLCInputBool) Output to PLC — true when at least one cross-group collision is active. **CollisionCount** (PLCInputInt) Output to PLC — number of currently active collision pairs. **ResetHighlight** (PLCOutputBool) Input from PLC — a rising edge clears all collision highlights. **ResetCollisions** (PLCOutputBool) Input from PLC — a rising edge resets all collision tracking. ### Events **OnCollisionEnterEvent** (UnityEvent) Fired when a cross-group collision begins. Provides both GameObjects involved. **OnCollisionExitEvent** (UnityEvent) Fired when a cross-group collision ends. Provides both GameObjects involved. ### Advanced **Excluded Pairs** (list) Specific cross-group pairs to exclude from detection. For example, exclude "Gripper" vs. "Workpiece" if gripper contact is intentional. ### Status (Read-Only) **Is Colliding** — true when at least one collision is active **Active Collision Count** — number of active collision pairs **Total Proxy Count** — total managed collider proxies **Highlighted Renderer Count** — renderers currently highlighted **Active Pairs** — human-readable list of current collision pairs ## Collider Mode Recommendations | Group Type | Recommended Mode | Reason | | --------------- | ---------------- | ------------------------------------------------------ | | Robot joints | ExistingOnly | Manually placed capsule/box colliders are more precise | | Machine frame | BoxApproximation | Many parts, coarse detection sufficient | | Gripper / tools | MeshCollider | Accurate shape matters for contact detection | | Safety zones | ExistingOnly | Manually placed box triggers as zone boundaries | ## Typical Use Cases **Robot vs. Machine Frame** — A 6-axis robot arm (Group "RobotArm") moves near a machine frame (Group "MachineFrame"). Self-collision within the robot's joints is suppressed. Any contact between robot and frame triggers a red blinking highlight and sets the PLC signal to stop the robot. **Gripper vs. Fixture** — A gripper (Group "Gripper") picks parts from a fixture (Group "Fixture"). Gripper-to-workpiece contact is excluded via Excluded Pairs. Only unintended gripper-to-fixture contact triggers an alarm. **Multiple Robots** — Two robots (Group "Robot1", Group "Robot2") work in overlapping reach zones. Each robot's internal joints don't trigger alarms, but any robot-to-robot contact does. ## Highlight Setup (URP) To use the highlight feature, you need a second `MultiObjectOverlayRendererFeature` in your URP Renderer: 1. Open your URP Renderer Asset (typically `URP-Default-Renderer.asset`) 2. Click **Add Renderer Feature** and select **Multi Object Overlay Renderer Feature** 3. Name it "CollisionOverlay" to distinguish it from the selection overlay 4. Assign this new feature to the **Overlay Feature** field on the GroupCollisionChecker The existing overlay feature (used by the Selection system) remains untouched. ## Scripting API ```csharp // Manual setup (if AutoSetupOnStart is false) checker.SetupCollisionSystem(); // Clear highlights without resetting tracking checker.ClearAllHighlights(); // Reset all tracking (highlights + active pairs) checker.ClearCollisionTracking(); // Subscribe to collision events via C# delegates checker.OnGroupCollisionEnter += (objA, objB) => { Debug.Log($"Collision: {objA.name} <-> {objB.name}"); }; checker.OnGroupCollisionExit += (objA, objB) => { Debug.Log($"Collision ended: {objA.name} <-> {objB.name}"); }; ``` ## See Also * [Group](/components-and-scripts/motion/group) — assigning objects to groups * [Group Manager](/basics/runtime-ui/group-manager) — hiding/showing groups at runtime * [Selection Window](/basics/user-interface/selection-window) — filtering by groups in the editor \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Picking and Placing MUs Components for handling, gripping, and manipulating MUs (Movable Units) in automation systems. ## Available Components ### Gripping Systems * [**Grip**](/components-and-scripts/picking-and-placing-mus/grip) - Primary component for individual grip points (recommended for most use cases) * [**Gripper**](/components-and-scripts/picking-and-placing-mus/gripper) - Advanced gripper system for complex multi-point gripping ### Positioning and Fixturing * [**Fixer**](/components-and-scripts/picking-and-placing-mus/fixer) - Primary component for temporarily fixing MUs in positions (recommended for most use cases) * [**Pattern**](/components-and-scripts/picking-and-placing-mus/pattern) - Defines positioning patterns for organized placement of multiple MUs ## Key Features * **Physics Integration**: Realistic gripping with collision detection and weight handling * **PLC Integration**: Full integration with PLCInputBool/PLCOutputBool signals for industrial control * **Sensor Integration**: Works with sensors for grip confirmation and positioning feedback * **Logic Integration**: Seamless connection with Logic Steps and automation sequences ## See Also * [MU (Movable Unit)](/components-and-scripts/mu-movable-unit) - Base MU functionality * [Motion](/components-and-scripts/motion) - Drive systems for gripper movement * [Sensors](/components-and-scripts/sensors) - Sensor integration for feedback * [Logic Steps](/components-and-scripts/defining-logic/logicsteps) - Automation sequence programming # Grip {% hint style="info" %} The Grip component was redesigned in realvirtual **6.3** with a new Simple Mode / Advanced Mode interface. If you are upgrading from 6.0, enable **Advanced Mode** to access the legacy properties you are familiar with. {% endhint %} ## Overview The Grip component picks and places [MUs (Movable Units)](/components-and-scripts/mu-movable-unit) using automation signals or [LogicSteps](/components-and-scripts/defining-logic/logicsteps). It is essential for attaching MUs to grippers, robot end-effectors, or any moving component driven by a drive system. Grip offers two Inspector modes: * **Simple Mode** (default) — streamlined interface for the most common pick-and-place scenarios * **Advanced Mode** — reveals all properties for sensor-based detection, cylinder-based picking, and fine-grained placement control ## Simple Mode

Grip in Simple Mode

In Simple Mode, Grip uses an **OverlapSphere** with the configured **Grip Range** to automatically find the nearest MU. No sensor is required — just position the Grip near the MU and trigger a pick. ### How Picking Works When **Pick Objects** changes from `false` to `true` (or **Signal Pick** receives a positive flank), the Grip performs an OverlapSphere at its position with the **Grip Range** radius. Only objects on the `rvMU` physics layer are detected. The nearest free MU (not already held by another Grip or Fixer) is selected. The picked MU becomes a **child of the Grip GameObject** in the hierarchy. Its Rigidbody is set to kinematic — physics and gravity are turned off so the MU moves rigidly with the gripper. The MU appears in the **Picked MUs** list. ### How Placing Works When **Pick Objects** changes back to `false` (or **Signal Pick** receives a negative flank), the Grip releases all held MUs. In Simple Mode, the **Auto** placement cascade runs automatically: 1. **GripTarget** — Searches for a free [GripTarget](/components-and-scripts/picking-and-placing-mus/griptarget) within 500 mm. If found, the MU snaps to the target's position/rotation and becomes its child. Physics stays off. 2. **MU below** — Raycasts downward (up to 1000 mm). If another MU is hit, the released MU is loaded onto it as a child. Physics stays off. 3. **TransportSurface below** — If the raycast hits a transport surface (conveyor), the MU is released with **physics enabled** — it falls onto the conveyor and is transported. 4. **Nothing found** — The MU stays frozen at its current position (kinematic, no physics). This cascade means Simple Mode handles the most common scenarios automatically — placing on a GripTarget, stacking parts on other MUs, dropping onto conveyors, or holding in position. {% hint style="info" %} In Simple Mode, the **Place Mode** is always **Auto** and the search/raycast distances use their defaults (500 mm / 1000 mm). Switch to **Advanced Mode** to change the placement behavior or adjust these distances. {% endhint %} ### Properties **Active** (enum) Controls when this component is active in the simulation (Always, Edit Mode only, etc.). **Advanced Mode** (boolean) Toggle to reveal all properties. When unchecked, only the essential Simple Mode properties are shown. **Grip Range** (float) The detection radius in millimeters. Grip uses a sphere overlap to find the nearest MU within this range. Default: 10 mm. **Pick Objects** (boolean) Set to `true` to pick the nearest MU within the Grip Range. Reacts on the rising edge only (false → true). **Place Objects** (boolean) Set to `true` to release all currently picked MUs. In Simple Mode this is automatically toggled when Pick Objects changes. **Signal Pick** (PLCOutputBool) PLC signal to control picking. A positive flank (false → true) picks, a negative flank (true → false) places. **Show Gizmo** (boolean) Displays the Grip Range sphere in the Scene view for visual debugging. **Picked MUs** (list, read-only) Shows all MUs currently held by this Grip. ## Advanced Mode

Grip in Advanced Mode

Enable **Advanced Mode** to access the full set of properties. This includes all Simple Mode properties plus the sections below. ### Pick Detection **Part To Grip** (Sensor) Optional sensor to identify which MU to grip. When assigned, only MUs detected by this sensor are considered. **Directly Grip** (boolean) If `true`, the MU is gripped immediately when the sensor detects it. **Pick Align With Object** (GameObject) Aligns the MU pivot to this object's position and rotation before picking. **Align Rotation** (boolean) Also aligns the rotation when picking (used with Pick Align With Object). **Pick Based On Sensor** (Sensor) Picking starts when this additional sensor is occupied. **Pick Based On Cylinder** (Drive\_Cylinder) Picking starts based on the position of a cylinder drive. **Pick On Cylinder Max** (boolean) If `true`, picking starts when the cylinder reaches maximum position. If `false`, at minimum position. ### Place Mode **Place Mode** (enum) Controls how MUs are placed when released: * **Auto** — Runs the placement cascade described above (GripTarget → MU below → TransportSurface → kinematic fallback). Physics is only enabled when placing on a TransportSurface; all other placements keep the MU kinematic. * **Static** — MU stays exactly where the gripper leaves it. Physics and gravity remain off (kinematic). The raycast cascade is skipped entirely. * **Physics** — MU gets gravity and physics enabled on release and falls naturally. Velocities are reset to zero first so the MU does not fly away with the gripper's motion. The raycast cascade is skipped entirely. **Grip Target Search Radius** (float) Detection range in millimeters for finding nearby [GripTargets](/components-and-scripts/picking-and-placing-mus/griptarget) during Auto placement. Default: 500 mm. **Raycast Distance** (float) Distance in millimeters for the downward raycast used to detect surfaces and MUs below during Auto placement. Default: 1000 mm. **No Physics When Placed** (boolean) Legacy property. If `true`, bypasses the Auto placement cascade and releases the MU with physics re-enabled at its current position. **Place Align With Object** (GameObject) Aligns MU pivot to this object's position and rotation before releasing. **Place Load On MU** (boolean) If `true`, the placed MU becomes a child of the MU it is placed on, creating a load-on-MU relationship. **Connect To Joint** (Joint) Optional Unity Joint for physical joint-based gripping instead of hierarchy parenting. ### Pick & Place Control **Pick Objects** (boolean) Set to `true` to pick MUs. **Place Objects** (boolean) Set to `true` to place MUs. **One Bit Control** (boolean) If `true`, a single signal toggles between pick and place. If `false`, separate signals for pick and place are used. **Signal Pick** (PLCOutputBool) Signal to control picking (positive flank = pick). **Signal Place** (PLCOutputBool) Signal to control placing (positive flank = place). Only used when One Bit Control is `false`. ### Events **Event MU Grip** (UnityEvent) Triggered when an MU is gripped or released. Passes the MU and `true` for grip, `false` for release. ## GripTarget Integration When **Place Mode** is set to **Auto**, the Grip automatically searches for [GripTarget](/components-and-scripts/picking-and-placing-mus/griptarget) components within the **Grip Target Search Radius**. If a free GripTarget is found, the MU snaps to the target's position and rotation and becomes a child of the GripTarget. See [GripTarget](/components-and-scripts/picking-and-placing-mus/griptarget) for details on setting up placement slots. ## GripTarget vs Fixer Both components handle MU placement, but serve different purposes: | | GripTarget | Fixer | | --------------------- | --------------------------------------- | ------------------------------------------------------------------ | | **Purpose** | Passive placement slot ("parking spot") | Active station lock ("parking gate with lock") | | **Needs Grip?** | Yes, always — only works with Grip | No — works standalone | | **MU arrives how?** | Grip places it | Conveyor, AGV, or robot delivers it | | **Controlled by** | Grip component logic | PLC signals (FixerFix/FixerRelease) or auto-mode | | **Detection** | None — found by Grip's OverlapSphere | Own BoxCollider trigger or Raycast | | **MU parenting** | MU becomes child of GripTarget | MU becomes child of Fixer (restored to previous parent on release) | | **Multi-MU** | One MU per target | Multiple MUs via MUSFixed list | | **Handover blocking** | No | Yes — prevents double-fixing between stations | | **Tag filtering** | No | Yes — only fix specific part types | **Use GripTarget** when a Grip (robot gripper) places MUs at predefined positions. **Use** [**Fixer**](/components-and-scripts/picking-and-placing-mus/fixer) when MUs arrive on their own (conveyor) and need to be stopped/held by PLC control. ## Demo Scenes

Grip demo scenes

Open the [Demo Scenes Browser](/basics/user-interface/demo-scenes-browser) and look under **Object Handling** for gripping demos: * **DemoGrippingSimple** — three demos: simple pick/place with OverlapSphere, GripTarget placement, and physics-based placement * **DemoGrippingAdvanced** — sensor-based detection, cylinder-based picking, and PLC signal control ## See Also * [GripTarget](/components-and-scripts/picking-and-placing-mus/griptarget) * [Gripper](/components-and-scripts/picking-and-placing-mus/gripper) * [Fixer](/components-and-scripts/picking-and-placing-mus/fixer) * [LogicSteps — GripPick & GripPlace](/components-and-scripts/defining-logic/logicsteps) * [MU (Movable Unit)](/components-and-scripts/mu-movable-unit) # GripTarget {% hint style="info" %} This component was added in realvirtual **6.3**. {% endhint %} ## Overview GripTarget marks a precise placement position for the [Grip](/components-and-scripts/picking-and-placing-mus/grip) component's Auto-Place system. When a Grip releases an MU near a GripTarget, the MU aligns to the target's position and rotation and becomes a child of the GripTarget. GripTarget is a **passive marker** — it does not detect MUs on its own. The Grip component finds it using an OverlapSphere search within the configured **Grip Target Search Radius**. ## Properties

GripTarget Inspector

**Align Position** (boolean) Snaps the MU position to the GripTarget's world position on placement. Default: `true`. **Align Rotation** (boolean) Snaps the MU rotation to the GripTarget's rotation on placement. Default: `false`. **Occupied By** (MU, read-only) Shows which MU is currently placed at this target. Empty means the target is free and available for placement. ## Usage 1. Add a **GripTarget** component to a GameObject at the desired placement position 2. Position and rotate the GameObject to define where and how the MU should land 3. Configure the [Grip](/components-and-scripts/picking-and-placing-mus/grip) component with **Place Mode = Auto** 4. Set **Grip Target Search Radius** on the Grip to control the detection range (default: 500 mm) 5. When the Grip places an MU within range, it automatically snaps to the nearest free GripTarget The MU becomes a **child** of the GripTarget transform, so if the GripTarget moves (e.g., on a conveyor or robot), the placed MU moves with it. ## GripTarget vs Fixer Both components handle MU placement, but serve different purposes: | | GripTarget | Fixer | | --------------------- | -------------------------------------------- | ------------------------------------------------------------------ | | **Purpose** | Passive placement slot ("parking spot") | Active station lock ("parking gate with lock") | | **Needs Grip?** | Yes, always — only works with Grip component | No — works standalone | | **MU arrives how?** | Grip places it | Conveyor, AGV, or robot delivers it | | **Controlled by** | Grip component logic | PLC signals (FixerFix/FixerRelease) or auto-mode | | **Detection** | None — found by Grip's OverlapSphere | Own BoxCollider trigger or Raycast | | **MU parenting** | MU becomes child of GripTarget | MU becomes child of Fixer (restored to previous parent on release) | | **Multi-MU** | One MU per target | Multiple MUs via MUSFixed list | | **Handover blocking** | No | Yes — prevents double-fixing between stations | | **Tag filtering** | No | Yes — only fix specific part types | **Use GripTarget** when a Grip (robot gripper) places MUs at predefined positions. **Use** [**Fixer**](/components-and-scripts/picking-and-placing-mus/fixer) when MUs arrive on their own (conveyor) and need to be stopped/held by PLC control. ## See Also * [Grip](/components-and-scripts/picking-and-placing-mus/grip) * [Fixer](/components-and-scripts/picking-and-placing-mus/fixer) # Gripper The Gripper combines functions of [Drives](/components-and-scripts/motion/drive) for the fingers, [Sensors](/components-and-scripts/sensors/sensor) for detecting [MUs](/components-and-scripts/mu-movable-unit) and [Grip](/components-and-scripts/picking-and-placing-mus/grip) in one single component. It is usefull for modelling standard grippers like you find the usually in automation systems in a comfortable way. During simulation start, the Gripper component will automatically create the needed Grip and Sensor Scripts. {% hint style="info" %} If you are using Fingers a sensor for detecting the parts to grip will be automatically created. The sensor will also detect the length which is needed to close until the part is touched. The signal *Is fully closed* will only be set to true if the Gripper is fully closed what means that no part is gripped. {% endhint %}
### Properties **Left Finger / Right Finger**\ It is optional to define fingers or not (by setting the Properties *LeftFinger*, *RightFinger*). If no fingers are defined there will be no movement visible. The closing time of the fingers needs to be passed before the parts are gripped. {% hint style="info" %} You need to place the left finger component pivot point to the point where the sensor for detecting the parts is placed. {% endhint %} **Time closing / Time opening**\ Time for closing and opening the Gripper in seconds. Parts are gripped when closing time is passed. Parts are released directly after opening is started. **Gripper Width**\ The Width of the Gripper in millimeters, when it is opened. **Open Pos Offset**\ Offset between the current scene view position and the open position of the Gripper in millimeters. **Direction Finger**\ The direction of the fingers in the local coordinate system of the Gripper. **Direction Closing**\ The closing direction of the fingers in the local coordinate system of the Gripper. **Close Grippper / Open Gripper**\ PLC signals for closing or opening the gripper **Is Closing / Is Opening**\ Signals are true during the opening or closing process\\ \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Fixer The fixer is a component that is normally not controlled by a PLC signal. With a fixer you can fix [MUs](/components-and-scripts/mu-movable-unit) (as subcomponents) at any location. When [MUs](/components-and-scripts/mu-movable-unit) are fixed the Physics and Gravity for the MUs is turned of and the MUs will stay at the current location. This can be used if you would like for example to place parts on other moving parts. If a MU which is currently fixed by a gripper is entering the Fixer detection area nothing will happen as long as the Gripper ([Grip script](/components-and-scripts/picking-and-placing-mus/grip)) is still holding the MU. As soon as the Gripper will release the MU, the MU will be fixed by the Fixer. If a MU is fixed by a fixer and another fixer collides with the MU, the MU is handed over to the last collided fixer. This handover behavior can be prevented by setting *Block Handing Over* or the signal *Signal Block Handing Over* to true. MU tags and the restriction to certain tags can also be used to realize more advanced functions. The Fixer can work with a Box Collider or with a Raycast to detect components that need to be fixed. ### Grip-Fixer Handover Pattern Fixer automatically receives MUs released by Grip components, enabling precise final positioning: 1. **Grip** (active) - Picks and transports MU to the target location 2. **Grip releases** - Opens and releases the MU (PlaceObjects = true) 3. **Fixer** (passive) - Automatically catches and positions MU with exact alignment Use **Align MU**, **Delta Align**, and **Delta Rot** properties to control the precise final position of the MU. This pattern combines dynamic transport (Grip) with stationary precision positioning (Fixer). ### Multi-Part Holding Fixer can hold **multiple MUs simultaneously**, making it ideal for: * **Tool wheels** - Multiple tools fixed in circular arrangement around the fixer * **Magazines** - Stacked parts or buffer positions * **Pallets** - Multiple products positioned on a single pallet Each fixed MU is positioned according to the Fixer's alignment settings (Delta Align and Delta Rot). {% hint style="info" %} You need to take care, that the Layer is set to the correct value. If you use a Box Collider it is usually "rvSensor" (before 2022"*g4A Sensor*"). If you use a Raycast it is usually "rvMU" (before 2022 "g4A MU") or "rvMUSensor" (before 2022 "g4A SensorMU"). {% endhint %} Open the [Demo Scenes Browser](/basics/user-interface/demo-scenes-browser) and look under **Object Handling** for gripping and fixing demos.
### Properties
#### Use Raycast If set to true a Raycast is used to detect the MUs. **Limit to Tags**\ The fixer can be restricted to react only to certain MUs. In this list all MU tags can be defined that should be considered. **Fix MU**\ Needs to be set to true for fixing the MUs. **Align and fix on min distance**\ If set to true, the parts which are entering are only fixed, when the distance to the fixer pivot point is not decreasing anymore. This can be used, for example, to align parts exactly on a Transport Surface. **Release on collision non MU**\ Will release the Fixer when a collider that is not an MU is entering the Fixer area. **Align MU**\ Will align the MU pivot point with the Fixer pivot point when the MUs are fixed. **Delta Align**\ Defines a Delta position on the pivot points for Alignment. **Delta Rot**\ Defines a Delta rotation on the pivot points for Alignment. **Set Tag after Fix**\ Automatically sets the MU tag to a certain name after the MU is fixed. Keep it empty if nothing should happen. **Show Status**\ Shows the status of the Fixer by changing the color between red (not fixed) and green (fixed). **Block Handing Over** Blocks the Fixer to hand over the MU to another Fixer (does not affects grippers). **One Bit fix**\ If set to true, the Input Signals are limited to one Input - Fixer Fix, which will Fix on true and unfix on false. **Fixer Release**\ If this PLC signal is connected and if it is true, the Fixer will release all MUs and MUs which are entering will not be fixed. **Fixer Fix**\ Contrary to Fixer Release. **Signal Block Handing Over** PLC Signal for blocking the handing over to another Fixer. \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Pattern Pattern is an auxiliary component for creating circular matrix patterns. This can be used for example when you need to place many realvirtual.io components in a certain way (e.g. you need many fixers on a wheel with vacuum grippers). The pattern game objects are created based on a template and some geometric information about the spacing of the pattern components. The pattern can be created in the editor mode or when starting the simulation.
## Properties ### Circular pattern Creates a circular pattern. The center of rotation is always the center of rotation of the transformation to which the pattern component is attached. #### Detla angle The angle between the individual circular pattern components. #### Rotation vector The direction vector of the rotation. #### Start angle The start angle of the pattern. #### Number The number of the created pattern components. ### Matrix Pattern Creates a matrix pattern. #### Number X,Y,Z The number of components of the pattern in the X, Y and Z directions. #### Spacing X,Y,Z The spacing of the pattern components in the x, y, and z directions. ### Settings #### Template If no template is defined, the component to which the pattern component is attached will be copied. It is recommended to define a template (referenced by this property) and disable the template itself (the pattern components are automatically enabled when they are created). #### Parent If no parent is defined, the pattern components are automatically created below the game object to which the pattern component is attached. #### Create at startup If true, the pattern components will be created when the simulation is started. #### Delete pattern Manually delete the pattern in editor mode. #### Generate pattern Generates the pattern in editor mode. \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Changing MUs Components for dynamically modifying MU (Movable Unit) appearance, materials, and behavior during simulation. ## Available Components ### Visual Modifications * [**PartChanger**](/components-and-scripts/changing-mus/partchanger) - Changes the visual appearance of MUs by switching between predefined appearances * [**MUSwitcher**](/components-and-scripts/changing-mus/muswitcher) - Controls visibility of grouped GameObjects within MUs based on sensor detection * [**MaterialChanger**](/components-and-scripts/changing-mus/materialchanger) - Dynamically changes materials on MU components ### Processing Operations * [**Cutter**](/components-and-scripts/changing-mus/cutter) - Simulates cutting operations on MUs with visual feedback ## Key Features * **Sensor Integration**: Changes triggered by sensor detection events * **PLC Integration**: Control via PLCInputBool signals for industrial automation * **Visual Feedback**: Real-time appearance changes during simulation * **Logic Integration**: Works with Logic Steps and automation sequences ## See Also * [MU (Movable Unit)](/components-and-scripts/mu-movable-unit) - Base MU functionality * [Sensors](/components-and-scripts/sensors) - Sensor components for triggering changes * [Logic Steps](/components-and-scripts/defining-logic/logicsteps) - Automation logic integration # MaterialChanger The MaterialChanger enables seamless material adjustments for the MeshRenderer on a GameObject. Changes can be triggered by collisions, sensor status, or PLC signals.
### Properties **Material off / on**\ Materials that should be used. **Status on**\ The current status. **Change on collision**\ Change material based on a collision. A collider needs in this case to be attached to the same Gameobject. **Change on Sensor**\ Changes the material based on the sensor status. **Change on PLC Output**\ Changes the material based on the defined PLC Output. © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # MUSwitcher Included since version 6.2.3 beta The **MU Switcher** component allows dynamic switching of parts or variants of [Moving Units (MUs) ](/components-and-scripts/mu-movable-unit)based on sensor triggers. It is typically used in scenarios where different configurations or visual representations of an MU need to be activated during runtime (e.g., for visual changes, turning easy MUs into complex ones and so on).

Changing MUs with MUSwitcher (Demo2 in DemoChangeMU demonstration model)

## Properties **Switch To Group**: The name of the group (e.g., `MUVariant1`) that should be activated when an MU enters the sensor area.

MUSwitcher attached to a Sensor

When an MU enters the sensor associated with the `MUSwitcher`: 1. All subcomponents of the MU that are part of the specified group (matching the `Switch To Group`) are **enabled** (set active). 2. All other groups are **disabled** (set inactive). 3. Any GameObjects under the MU that do not belong to a group remain in their current active state ## Requirements * The `MUSwitcher` must be attached to the same GameObject as a `Sensor` component. * MU subcomponents must include a `Group` component that defines their `GroupName`.

Example of a part with several Groups

# PartChanger Instead of using PartChanger you can use MUSwitcher which might be an easier and more convienient way for changing a MU during simulation The PartChanger is able to change the visual appearance of a part on certain events. For doing this all child components under the object with the [MU](/components-and-scripts/mu-movable-unit) script attached to are getting replaced by a new part. The new part should always be a Prefab which is saved somewhere in the project. You can find a Demo scene for the PartChanger under Assets/realvirtual/Scenes/DemoChangeMU.unity The part changer can change the visual appearance of the component where the part changer is attached to (*Change this part* option) or to change the visual appearance of an [MU](/components-and-scripts/mu-movable-unit) which is detected by a Sensor (*Change On Sensor* option)
### Configuration of the PartChanger You need to set a Part Number in the Part changer. This is the number, starting from 0, in the list of available Appearances. The list of available Appearances can be on the [MU](/components-and-scripts/mu-movable-unit) or on the PartChanger itself if no MU is changed. #### Change detected MU on Sensor Is changing the appearance of [MUs](/components-and-scripts/mu-movable-unit) which are entering the defined sensor. #### Change this part Is changing the appearance of the object where the PartChanger script is attached to. This means that the part changer needs to be attached to an MU. #### Conditions You can select a condition when the Part should be changed. #### `Condition Sensor Is Touched` This property allows the visual appearance of a part to change when a sensor detects a part. If set to true, the part will change as soon as the sensor touches an [MU](/components-and-scripts/mu-movable-unit). #### `Condition Part Number Is Changing` When enabled, this property changes the visual appearance of the part whenever the `PartNumber` value changes. This is useful for dynamically updating the appearance based on external triggers, such as updates from a PLC or other logic controllers. #### `Condition PLC Signal Change` If enabled, this property changes the part's visual appearance when the corresponding PLC signal (`PLCChangePartNow`) changes. This is especially useful when integrating with PLC systems to trigger a part change based on automation logic. The part will be updated each time the signal changes its state. #### Signals You can connect two PLC Signals. One for starting the visual change and one for selecting a new part number.
© 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # Cutter Cutting MUs into multiple parts The Cutter component is designed to efficiently segment Movable Units (MUs) into distinct pieces by slicing the meshes within these units along a specified plane. This process divides the MUs into a positive side and a negative side, ensuring that all included meshes are precisely cut according to the plane's orientation. This functionality is integral for simulations requiring dynamic object modification, such as cutting or dividing objects into separate parts for further interaction. The Cutter component offers versatility in its cutting operation, allowing it to either divide the entire Movable Unit (MU) or selectively slice only specific meshes within the MUs that are designated by tags. This example demonstrates two distinct cutting processes using the Cutter component, where in both instances, the positive part of each cut is deleted—a configurable option. During the first cut, the entire Movable Unit (MU) is subjected to the slicing action. In the second cut, the process is refined to only target and slice the outer mesh of the MU. The DemoCutter Scene, showcasing the Cutter component's functionality, is located in the demo folder.

Cutting MUs with the Cutter component

## **Prerequisites** The Cutter component requires the 'BzKovSoft.ObjectSlicer' package from the Unity Asset Store. {% embed url="" %} Mesh slicer on Unity Asset Stroe {% endembed %} Ensure this package is installed and the Scripting Define Symbol `REALVIRTUAL_CUTTER` is set in your project settings. A demo package showcasing the Cutter component's capabilities is available. For more details and to download the package, please refer to the description on the Unity Asset Store. ## **Properties**

Cutter component

The simplest method to utilize the Cutter component is by dragging and dropping the Cutter prefab directly into your scene. All cutting actions performed by this component are based on the Plane, which is oriented according to the Y direction of the component. **Settings** * **Cut Material**: Assigns a material to the faces created by the cut. * **Delete Options**: Allows for the deletion of either the positive or negative side of the cut object. * **Block For Seconds After Cut**: Temporarily disables cutting after a cut is performed to prevent rapid successive cuts. * **Submesh Cutting**: Option to cut only specified submeshes by tagging them. **Signals / IOs** * **Start Cut**: A boolean signal that, when true, initiates the cutting process. This can be linked to an external PLC signal for automation. * **Signal Cut**: Represents an external trigger for starting the cutting process. ## **Functionality** 1. **Cutting Process**: * The component detects colliders entering its trigger area (defined by the included box collider), identifying objects for cutting. * When the `Start Cut` signal is activated, the component slices through the detected objects based on the configured settings. 2. **Submesh and Full MU Cutting**: * If `OnlySubmeshes` is enabled, only the parts of objects tagged with `SubmeshTag` are cut. Please make sure to define the tags for the Submeshes * Without `OnlySubmeshes`, entire objects within the trigger area are subject to cutting. 3. **Post-Cut Handling**: * Objects can be selectively destroyed based on the `DeletePositiveCut` and `DeleteNegativeCut` settings. # Scene Interaction The **Scene Interaction** section in the realvirtual.io documentation introduces a suite of components designed to facilitate user interaction within your digital twin models. These tools enable the creation of interactive elements such as buttons, switches, and overlays, allowing users to engage with the simulation in real-time. Some of the functions are only available in realvirtual.io Professional. #### Key Components: * [**3D Buttons**](/components-and-scripts/scene-interaction/3d-buttons): These are physical-like buttons placed within the 3D scene, mimicking real-world controls. They can be connected to PLC signals, enabling users to trigger actions like starting or stopping machinery directly within the simulation. * [**Screen Overlay Buttons**](/components-and-scripts/scene-interaction/screen-overlay-buttons): UI elements that overlay the 3D scene, providing users with controls such as toggling views or initiating processes without interacting directly with 3D objects. * [**Scene Selectables (Pro)**:](/components-and-scripts/scene-interaction/scene-selectables-pro) This system allows objects within the scene to be selectable during play mode. Selecting an object can display a window with options to manipulate predefined signals, facilitating dynamic interaction with scene elements. * [**Interact3D**: ](/components-and-scripts/scene-interaction/interact3d)A script that enables user interactions such as pressing buttons or toggling switches within the 3D environment. It allows for defining behaviors like changing materials or triggering signals upon user actions. * [**UI Components (depracated)**](/components-and-scripts/scene-interaction/ui-components): A collection of user interface elements including panels, buttons, and sliders that can be used to display information or provide controls within the simulation. * [**HMI Components (Pro)**](/components-and-scripts/scene-interaction/hmi-components-pro): Advanced human-machine interface elements like tabs, dropdowns, and message displays, allowing for the creation of comprehensive control panels and dashboards within the simulation. [doc.realvirtual.io](https://doc.realvirtual.io/components-and-scripts/scene-interaction/hmi-components?utm_source=chatgpt.com) # KeyboardMove {% hint style="info" %} **New Feature**: The KeyboardMove component is not yet released and will be part of realvirtual version 6.0.5. {% endhint %} The **KeyboardMove** component enables precise manual positioning of GameObjects using keyboard input with smooth interpolation and configurable movement boundaries. ## Overview KeyboardMove provides interactive control over GameObject positioning in automation simulations through customizable keyboard inputs. This component is particularly useful for manual positioning tasks during commissioning, debugging object placement, or creating interactive demonstrations where users need direct control over object movement. **Important**: KeyboardMove only moves the specific GameObject it is attached to, along with all of its child objects. The movement occurs in the object's local coordinate system, meaning the X, Y, and Z axes are relative to the object's current rotation and orientation, not the world coordinate system. The component supports independent control of all three axes with dual-key combinations, allowing for complex movement patterns while maintaining precise control. This local space movement behavior makes it ideal for controlling objects that may be oriented in various directions within your scene, as the movement directions remain consistent relative to the object's own coordinate system. > **💡 Hint**\ > KeyboardMove uses Unity's standard unit system where 1 unit equals 1 meter. All speed and limit values are specified in meters and meters per second. > **💡 Hint**\ > KeyboardMove is designed for manual control during setup, debugging, and testing phases. It is not a Drive-based movement system and should not be used as a replacement for automated movements in production automation sequences. Use Drive components for programmed automation movements.
KeyboardMove component in Unity Inspector

KeyboardMove component in Unity Inspector

## Properties ### Movement Settings **Speed** (float) Controls the movement velocity in meters per second when keys are pressed. Higher values result in faster movement, while lower values provide finer control for precise positioning tasks. The default value of 1 m/s provides a good balance for most applications. **LerpFactor** (float) Determines the smoothness of movement interpolation, with higher values producing more responsive movement and lower values creating smoother, more gradual transitions. Values between 1 and 20 are recommended, with 10 being the default that works well for most scenarios. This smoothing helps create natural-looking movement without abrupt starts and stops. ### Input Keys - X Axis The X axis controls left and right movement in the object's local coordinate system. **XNegativeKey1** (KeyCode) Primary key for negative X axis movement (typically left). Default is Keypad4 for intuitive numpad control. **XNegativeKey2** (KeyCode) Optional secondary key for negative X movement. When set to a value other than None, both keys must be pressed simultaneously to trigger movement. This dual-key requirement is useful for preventing accidental movements in critical positioning tasks. **XPositiveKey1** (KeyCode) Primary key for positive X axis movement (typically right). Default is Keypad6, maintaining consistency with numpad layout. **XPositiveKey2** (KeyCode) Optional secondary key for positive X movement, following the same dual-key logic as the negative direction. ### Input Keys - Y Axis The Y axis controls vertical movement (up and down) in the object's local coordinate system. **YNegativeKey1** (KeyCode) Primary key for negative Y axis movement (typically down). Default is None, as vertical movement is often not required in automation scenarios. **YNegativeKey2** (KeyCode) Optional secondary key for negative Y movement with dual-key support. **YPositiveKey1** (KeyCode) Primary key for positive Y axis movement (typically up). Default is None. **YPositiveKey2** (KeyCode) Optional secondary key for positive Y movement. ### Input Keys - Z Axis The Z axis controls forward and backward movement in the object's local coordinate system. **ZNegativeKey1** (KeyCode) Primary key for negative Z axis movement (typically backward). Default is Keypad2 for logical numpad navigation. **ZNegativeKey2** (KeyCode) Optional secondary key for negative Z movement with dual-key functionality. **ZPositiveKey1** (KeyCode) Primary key for positive Z axis movement (typically forward). Default is Keypad8, completing the intuitive numpad control scheme. **ZPositiveKey2** (KeyCode) Optional secondary key for positive Z movement. ### Reset Control **ResetKey** (KeyCode) Key used to instantly reset the GameObject to its initial position. Default is Keypad5, providing quick access to return to the starting position during positioning tasks. This feature is particularly useful when you need to quickly return to a known reference point after extensive movement. ### Movement Limits All movement limits are specified relative to the GameObject's initial position when the component starts. **XAxisLimits** (Vector2) Defines the minimum (x) and maximum (y) allowed positions along the X axis in meters from the initial position. The default range of -10 to +10 meters provides ample movement space while preventing objects from moving too far from their starting point. **YAxisLimits** (Vector2) Sets the vertical movement boundaries in meters from the initial position. These limits ensure objects remain within designated height ranges, particularly important for crane systems or vertical lift mechanisms. **ZAxisLimits** (Vector2) Establishes forward and backward movement boundaries in meters from the initial position. These constraints are essential for preventing collisions and keeping objects within their operational areas. ## Editor Tools ### Visual Gizmos When the GameObject with KeyboardMove is selected in the Unity Editor, cyan wireframe boundaries visualize the allowed movement area. This wireframe cube shows the exact limits defined by the axis limit properties, making it easy to understand and adjust the movement constraints. A yellow sphere marks the initial position (center point) of the movement area, providing a clear reference for the origin of all movement calculations. During play mode, a red sphere indicates the current target position, helping debug movement behavior and verify that limits are working correctly. ## Usage Examples ### Basic Setup for Manual Positioning 1. Add the **KeyboardMove** component to any GameObject you want to control 2. Configure the **Speed** to match your desired movement rate (1-5 m/s for general use) 3. Adjust **LerpFactor** for movement smoothness (5-10 for smooth motion, 15-20 for responsive control) 4. Set appropriate **Movement Limits** based on your scene constraints 5. Press Play and use the configured keys to move the object ### Numpad Control Configuration The default configuration uses the numpad for intuitive movement control: * Numpad 4/6: Left/Right movement (X axis) * Numpad 8/2: Forward/Backward movement (Z axis) * Numpad 5: Reset to initial position * Y axis keys can be configured if vertical control is needed This layout mirrors common industrial control panels and provides logical spatial mapping. ### Dual-Key Safety Setup For critical positioning tasks where accidental movement must be prevented: 1. Set **XNegativeKey2** to LeftShift or LeftControl 2. Set **XPositiveKey2** to the same modifier key 3. Repeat for Y and Z axes as needed 4. Movement now requires holding the modifier key plus the direction key This configuration ensures deliberate control actions and prevents unintended movements. # Tooltip (Pro) Disppaying tooltips in the scene. {% hint style="warning" %} This feature is only available in realvirtual.io Professional {% endhint %} The **RuntimeTooltip** system allows you to display contextual tooltips in your simulation, helping users understand the function or content of scene objects at runtime.

Runtime tooltip

#### Features * Works with any 3D object in the scene * Fully supports **TextMeshPro rich text** (bold, color, line breaks) * Dynamically displayed on hover or selection * Easy to integrate via prefab ## Required Components **1. Tooltip Controller (Scene-Level)** You must add the Tooltip Controller to your scene. This controller handles the positioning and display of all tooltips. > 📦 **Prefab**:\ > `Assets/realvirtual/Professional/SceneSelection/TooltipController.prefab` Drag and drop this prefab into your scene to enable the tooltip system. **2. RuntimeTooltip Script (Object-Level)** Attach the `RuntimeTooltip` script to any GameObject you want to annotate with a tooltip. **Steps:** 1. Select the target GameObject (e.g., a cabinet). 2. Add the component: `Runtime Tooltip (Script)` 3. Enter your tooltip text in the **Text** field using TextMeshPro for formatting if needed. **Example:** ```html Cabinet\nContains control electronics and power supply ``` # 3D Buttons The 3D button prefabs mimic real world physical buttons and their signal communication and lay in the 3D space of your digital twin.
We provide 4 drag and drop prefrabs under realvirtual/3DPrefabs/ControlCabinet. Each button has at least one connected signal reflecting the current state of the button. In playmode, the user can simply toggle the state of each button by clicking it directly in the 3D space. ## EmergencyButton
The emergency button has a fairly simple set up. it has a connection to a PLCInputBool signal representing the current state of the button. Additionally the user can select if it is active when starting play mode.
## HandleSwitch
The handle switch behaves identically to the emergency button and has the same properties. The handle switch comes with a second variant sharing the same functionality.
## PushButton
The push button implements some additional features to the functionality described above. Besides the state signal, the user can reference a light signal (PLCOutputBool). If the light signal is not set, the button light reflects the current state of the button, otherwise the light is controlled by the light signal.
Additionally, the push button can not only act as a toggle but also as hold button. To enable the click and hold mode, simply turn off the Toggle option in the inspector.
The button will now only be active while the user is clicking and holding the button, onrelease the button turns of after a minimum total pushing time which is defined by the Timer in the inspector. Moreover, the user can set the label text of the button by changing the label in the inpector. # Screen Overlay Buttons Hiding Groups or setting Camera Positions This documentation explains how to set up and use the overlay buttons whithin a scene. All elements are in the UIPrefabs folder. ## Overview * **OverlayButtons Prefab**: A pre-designed canvas that serves as the central UI element for your set up * **Button Prefabs**: Predefined button styles designed for different functionalities and use cases, such as camera position, group connection and signal trigger. ## Setup ### Adding the user canvas 1. Drag and drop the OverlayButtons-Prefab in the hierarchy. There are no further parameter needed. 2. the button placement area, named "Buttons," is positioned by default along the right margin. ### Button prefabs All button prefabs include the `rvUIToolbarButton` component, where you can configure the following parameters: * **Item Tooltip**: Defines the button's tooltip text. * **Tooltip Position**: Sets the tooltip's display position relative to the button.

rvUIToolbarButton

Each button GameObject contains two child images where you can assign custom sprites

Set button images

#### Button Camera position #### Within the component "StartCameraPosition" you can assign a Camera Pos.
A camera position is created in the following way: * "Right Click" in your project and select "Create/realvirtual/Add Camera Position". This creates a scriptable object where you define the position of the camera. * Assign the created camera position to the "StartCameraPosition" component.
#### Button Show Group The `ButtonShowGroup` component provides a list of groups available to the user in Playmode. Select a group to control its visibility with the button.
To define these groups for Playmode, use the [`GroupManager`](/basics/runtime-ui/group-manager) in the RealVirtual prefab. Ensure the `GroupManager` used is also assigned in the `ButtonShowGroup` component. # Scene Selectables (Pro) Interactive 3D object selection system with multi-layer highlighting, real-time signal monitoring, tooltips, and detailed property inspection for virtual commissioning and training scenarios. The Scene Selection system provides interactive runtime object selection with sophisticated visual feedback, allowing operators to inspect components, view live signal states, and interact with simulation elements during virtual commissioning, training, and debugging scenarios.
Scene Selection system showing tooltip and selection window

Scene Selection with modern tooltip display and interactive signal window

## Overview Scene Selection transforms static 3D models into interactive elements that users can hover over, click, and inspect during runtime. The system provides multi-layer visual feedback with separate highlighting for hover effects, active states, selections, and change indicators. Each selectable object can display tooltips on hover and detailed information windows when clicked, including live signal states that can be toggled directly from the interface. Key capabilities include: * **Multi-layer highlighting system** with four independent visual states (Active, Hover, Selected, Changed) * **Interactive tooltips** that appear on hover with customizable content * **Detailed selection windows** showing properties, descriptions, and live signal states * **Signal monitoring and control** with toggle switches for real-time manipulation * **Change tracking** that highlights objects when their signal states differ from initial values * **Dynamic content system** for adding runtime values and clickable links * **Multi-renderer grouping** to treat complex models as single selectable units * **Raycast-based interaction** with automatic UI avoidance The system integrates seamlessly with realvirtual's signal system, allowing you to monitor and control PLCInputBool, PLCOutputBool, and other signal types directly from the selection interface. This makes it invaluable for debugging automation logic, training operators on equipment functions, and creating interactive maintenance procedures. ## Setup and Configuration ### Adding Scene Selection to Your Scene To implement Scene Selection in your project: 1. **Add the prefab**: Drag the `SceneSelectables` prefab from `Assets/realvirtual/UIPrefabs/` into your scene hierarchy 2. **Configure the toolbar button**: The system automatically adds a toolbar button using the icon specified in the SceneSelectionManager 3. **Set up highlighting managers**: The prefab comes pre-configured with four highlighting managers that are automatically detected: * **Highlight 1**: Active state highlighting * **Highlight 2**: Hover effect highlighting * **Highlight 3**: Changed state highlighting * **Highlight 4**: Selected state highlighting ### Creating Selectable Objects You can create selectable objects in two ways: **Method 1: Using the Add Selectable Button** 1. Select the SceneSelectables GameObject in the hierarchy 2. Click **Add Selectable** in the Inspector 3. A new SceneSelectable child object is created automatically 4. Configure the selectable's properties in the Inspector **Method 2: Manual Creation** 1. Create an empty GameObject as a child of SceneSelectables 2. Add the SceneSelectable component 3. Configure renderers, signals, and content ## SceneSelectionManager Properties The SceneSelectionManager orchestrates all selection interactions and visual feedback: ### Selection Managers **Active** (AbstractSelectionManager) controls the highlighting for objects in their default active state. This manager applies visual feedback to all selectable objects when the selection system is enabled, providing a base layer of highlighting that indicates which objects are interactive. **Hover** (AbstractSelectionManager) manages the hover effect when the mouse cursor moves over a selectable object. This provides immediate visual feedback to users, indicating which object will be selected if clicked. The hover highlighting is automatically removed when the cursor moves away. **Selected** (AbstractSelectionManager) handles persistent highlighting for objects that have been clicked and selected. This highlighting remains active until another object is selected or the selection is cleared, providing clear visual indication of the currently inspected object. **Changed** (AbstractSelectionManager) highlights objects whose signal states have changed from their initial values. This is particularly useful for debugging and training scenarios, as it immediately shows which components have been manipulated or have changed state during simulation. ### UI Configuration **Icon** (Sprite) defines the toolbar button icon for enabling/disabling the selection system. This icon appears in both the on and off states of the toolbar button, providing a consistent visual identifier for the selection tool. **Window** (GameObject) references the selection window prefab that displays detailed information when an object is selected. This window contains the title, description, signal toggles, and any dynamic content associated with the selected object. **Title** (TextMeshProUGUI) points to the text component that displays the selected object's title in the selection window header. This is automatically updated when an object is selected. **Description** (GameObject) contains the panel for displaying detailed descriptions. The panel is automatically shown or hidden based on whether the selected object has a description defined. **Tooltip** (GameObject) references the tooltip prefab that appears on hover. The tooltip automatically sizes itself to fit the content and follows the mouse cursor position. ### UI Prefabs **Value Prefab** (GameObject) defines the template for displaying property values in the selection window. This prefab is instantiated for each value-type content item, showing a label and value pair. **Button Prefab** (GameObject) provides the template for creating interactive link buttons in the selection window. These buttons can open URLs, documentation, or trigger other actions when clicked. ## SceneSelectable Properties ### Basic Information **Title** (string) sets the header text displayed in the selection window. This should be a clear, concise name that identifies the component or system being selected. For example: "Conveyor Motor M1" or "Safety Door Sensor". **Description** (string) provides detailed information about the selected object. This text appears in an expandable panel within the selection window and can include operational details, specifications, or usage instructions. The description panel automatically hides if no text is provided. **Tooltip** (string) defines the hover text that appears when the mouse cursor is over the object. Tooltips are edited through a custom text area in the Inspector and support multi-line content. Use tooltips to provide quick identification or status information without requiring a full selection. ### Visual Configuration **Renderers** (List) specifies all mesh renderers that belong to this selectable unit. When any renderer in the list is hovered or selected, all renderers are highlighted together. This allows you to group multiple parts of a complex model as a single interactive element. For example, a motor assembly might include the motor body, mounting bracket, and cooling fan as separate renderers that highlight as one unit. ### Signal Integration **Signals** (List) contains the signals to monitor and control through the selection window. Each signal appears as a toggle switch in the selection window, showing its current state and allowing direct manipulation. The system tracks the initial state of all signals and automatically applies change highlighting when values differ from their starting state. Supported signal types include: * PLCInputBool for input signals * PLCOutputBool for output signals * PLCInputFloat and PLCOutputFloat for analog signals * Custom signal implementations ### Dynamic Content **Contents** (List) stores additional information items to display in the selection window. Each content item can be either a value (text display) or a link (clickable button). Content items are added programmatically using the AddStringContent and AddLinkContent methods, allowing you to populate selection windows with runtime data. ## Usage Examples ### Basic Setup Example Here's how to set up a simple selectable conveyor motor: ```csharp // Configure in Inspector or via script SceneSelectable motorSelectable = conveyorMotor.AddComponent(); motorSelectable.SetTitle("Conveyor Drive Motor M1"); motorSelectable.description = "Main drive motor for conveyor section 1\n" + "Power: 5.5 kW\n" + "Speed: 0-1450 RPM"; motorSelectable.tooltip = "Motor M1 - Click for details"; // Add the motor's mesh renderers motorSelectable.renderers.Add(motorBody.GetComponent()); motorSelectable.renderers.Add(motorFan.GetComponent()); // Link motor control signals motorSelectable.signals.Add(motorRunSignal); motorSelectable.signals.Add(motorFaultSignal); motorSelectable.signals.Add(motorSpeedSignal); ``` ### Adding Dynamic Content You can add runtime information to selectables: ```csharp public class MotorMonitor : MonoBehaviour { private SceneSelectable selectable; private float runtime = 0; void Start() { selectable = GetComponent(); // Add static information selectable.AddStringContent("Serial Number", "MTR-2024-0156"); selectable.AddStringContent("Installation Date", "2024-03-15"); // Add documentation link selectable.AddLinkContent("View Manual", "https://doc.realvirtual.io/motors/m1-series"); // Add maintenance link selectable.AddLinkContent("Maintenance Schedule", "https://maintenance.local/motor/M1"); } void Update() { runtime += Time.deltaTime; // Update runtime display selectable.ClearContent(); selectable.AddStringContent("Runtime", $"{runtime:F1} hours"); selectable.AddStringContent("Temperature", $"{GetMotorTemp():F1}°C"); } } ``` ### Tooltip Configuration Tooltips are configured through the custom Inspector interface: 1. Select a SceneSelectable object 2. In the Inspector, find the **Tooltip** section at the bottom 3. Enter multi-line tooltip text in the text area 4. The tooltip automatically appears on hover during runtime Example tooltip content: ``` Safety Door SD-01 Status: Closed Interlock: Active Last opened: 10:45 AM ``` ### Signal Monitoring Example Here's how the selection system integrates with signals for a sensor: ```csharp public class SensorSelectable : MonoBehaviour { public PLCInputBool sensorActive; public PLCInputBool sensorFault; public PLCOutputBool sensorReset; void Start() { SceneSelectable selectable = GetComponent(); // Add signals for monitoring selectable.signals.Add(sensorActive); selectable.signals.Add(sensorFault); selectable.signals.Add(sensorReset); // Set descriptive title selectable.SetTitle($"Proximity Sensor {gameObject.name}"); // Add diagnostic information selectable.AddStringContent("Type", "Inductive"); selectable.AddStringContent("Range", "8mm"); selectable.AddStringContent("Output", "PNP NO"); } } ``` ## Advanced Features ### Multi-Layer Highlighting System The four-layer highlighting system provides sophisticated visual feedback: 1. **Base Layer (Active)**: Shows all interactive objects when the selection system is enabled 2. **Hover Layer**: Provides immediate feedback as the cursor moves 3. **Selection Layer**: Persists to show the currently inspected object 4. **Change Layer**: Overlays objects that have been modified These layers work together to create an intuitive interaction experience. For example, a motor might show: * Active highlighting (blue outline) indicating it's selectable * Hover highlighting (yellow glow) when the mouse is over it * Selection highlighting (green outline) when clicked * Change highlighting (red pulse) if its signals have been toggled ### Change Tracking The system automatically tracks signal changes: ```csharp // Initial state is captured automatically on Start() // When signals change, the Changed highlight manager activates // This happens automatically - no code required // To reset change tracking programmatically: void ResetChangeTracking() { SceneSelectionManager manager = FindObjectOfType(); manager.RefreshActives(); // Re-evaluates all change states } ``` ### Custom Selection Behavior You can extend selection behavior by responding to selection events: ```csharp public class CustomSelectable : MonoBehaviour { private SceneSelectable selectable; void Start() { selectable = GetComponent(); } void Update() { // Check if this object is currently selected SceneSelectionManager manager = GetComponentInParent(); if (manager.selectedSelectable == selectable) { // Perform actions while selected UpdateRealtimeData(); } } void UpdateRealtimeData() { // Update dynamic content while selected selectable.ClearContent(); selectable.AddStringContent("Speed", $"{GetCurrentSpeed():F1} m/s"); selectable.AddStringContent("Position", $"{transform.position}"); } } ``` ### Programmatic Selection Control You can control the selection system through code: ```csharp public class SelectionController : MonoBehaviour { private SceneSelectionManager selectionManager; void Start() { selectionManager = FindObjectOfType(); } public void EnableSelection() { selectionManager.Activate(); } public void DisableSelection() { selectionManager.Deactivate(); } public void ClearSelection() { selectionManager.CloseWindow(); } public void RefreshHighlighting() { selectionManager.RefreshActives(); } } ``` ## API Reference ### SceneSelectionManager Methods **Activate()** enables all child SceneSelectable components and applies initial highlighting. Call this to turn on the selection system programmatically. **Deactivate()** disables all child SceneSelectable components, removes highlighting, and closes any open windows. Use this to turn off the selection system. **RefreshActives()** re-evaluates the active/changed state of all selectables based on current signal values. This updates the highlighting to reflect any changes since initialization. **CloseWindow()** closes the current selection window and clears the selection highlighting. The selected object reference is also cleared. **AddSelectable()** creates a new SceneSelectable child GameObject. This Editor method provides a quick way to add selectables through the Inspector. ### SceneSelectable Methods **SetTitle(string title)** sets the display title for the selection window header. **AddStringContent(string name, string value)** adds a text value display to the selection window. The name appears as a label, and the value is shown alongside it. **AddLinkContent(string name, string url)** adds a clickable button that opens the specified URL. Use this for documentation links, external resources, or web-based tools. **ClearContent()** removes all dynamically added content items. Signal displays are not affected. **Activate()** enables this selectable object, creating the necessary SelectablePart components and applying initial highlighting. **Deactivate()** disables this selectable object, removing SelectablePart components and clearing all highlighting. **Hover()** applies hover highlighting to all associated renderers and shows the tooltip if configured. **UnHover()** removes hover highlighting and hides the tooltip. **Click()** handles selection, toggling the selection state and opening or closing the information window. **HasTooltip()** returns true if a tooltip is configured for this selectable. **RefreshActive(SceneSelectionManager manager)** updates the visual state based on current signal values compared to initial state. ### SceneSelectableContent Structure The SceneSelectableContent class defines additional information items: ```csharp public class SceneSelectableContent { public enum Type { Value, // Text display Link // Clickable URL button } public Type type; // Content type public string name; // Display label public string value; // Text or URL } ``` ## Performance Considerations ### Raycast Optimization The system uses Physics.RaycastAll for accurate multi-layer detection. To optimize performance: * Place selectable objects on specific layers * Use layer masks in physics settings to exclude unnecessary objects * Limit the number of active selectables in dense scenes ### Highlighting Performance Each highlighting manager can impact rendering performance: * Use simple outline shaders for better performance * Limit the number of simultaneous highlight effects * Consider LOD settings for complex models * Disable highlighting for objects outside the camera view ### Signal Updates Signal monitoring happens continuously during runtime: * Limit the number of signals per selectable (recommend < 10) * Use efficient signal implementations * Consider update frequencies for real-time data * Cache signal references to avoid lookups ## Unity 6 Compatibility When upgrading projects to Unity 6, the Render Graph compatibility mode must be disabled for highlighting to work correctly: 1. Open **Edit > Project Settings** 2. Navigate to **Graphics** 3. Find **Render Graph Settings** 4. Disable **Compatibility Mode** 5. Restart Unity Editor
Unity 6 Render Graph settings

Disable Compatibility Mode in Graphics settings for proper highlighting

This setting ensures that the highlighting shaders work correctly with Unity 6's rendering pipeline. ## CMCViewR Compatibility When deploying realvirtual projects to CMCViewR, Scene Selectables have the following restrictions: ### Scene Selectables Not Supported Scene Selectables are **not compatible** with CMCViewR and will not function in exported CMCViewR scenes. The interactive selection system, highlighting, tooltips, and selection windows are editor/runtime Unity features that do not translate to the CMCViewR environment. If you need interactive object selection in CMCViewR, you will need to implement alternative interaction methods compatible with the CMCViewR runtime. ### Custom Script Requirements When using custom scripts in projects that will be exported to CMCViewR, all custom code must be placed in its own custom assembly definition. This is a CMCViewR requirement for proper script compilation and deployment. To create a custom assembly definition for your scripts: 1. Create a new folder for your custom scripts (e.g., `Assets/CustomScripts/`) 2. Right-click in the folder and select **Create > Assembly Definition** 3. Name the assembly (e.g., `MyProject.Custom`) 4. In the Assembly Definition Inspector: * Add references to `realvirtual` and any other required assemblies * Configure platform compatibility as needed 5. Place all your custom scripts within this folder Example assembly definition setup: ```json { "name": "MyProject.Custom", "references": [ "realvirtual.base", "Unity.TextMeshPro" ], "includePlatforms": [], "excludePlatforms": [] } ``` ### Camera Handling When exporting to CMCViewR, you do not need to manually prepare or deactivate realvirtual cameras. The realvirtual camera system will be **automatically deactivated** when the scene runs in CMCViewR, as CMCViewR uses its own camera management system. ## Integration with Other Components Scene Selection integrates seamlessly with other realvirtual components: ### Drive Integration Selectable drives can display current position, speed, and control signals: ```csharp selectable.signals.Add(drive.JogForward); selectable.signals.Add(drive.JogBackward); selectable.AddStringContent("Position", $"{drive.CurrentPosition:F2} mm"); ``` ### Sensor Integration Sensors can show detection states and configuration: ```csharp selectable.signals.Add(sensor.Occupied); selectable.AddStringContent("Detection Range", $"{sensor.Range} mm"); ``` ### Transport System Integration Conveyors and transport systems benefit from selection for debugging: ```csharp selectable.signals.Add(conveyor.Running); selectable.signals.Add(conveyor.EmergencyStop); selectable.AddStringContent("Speed", $"{conveyor.Speed:F1} m/s"); ``` ## Troubleshooting ### Highlighting Not Visible * Verify Render Graph Compatibility Mode is disabled (Unity 6) * Check that highlighting managers are assigned in SceneSelectionManager * Ensure renderers have materials that support highlighting shaders * Verify the Highlighter prefab exists in the scene hierarchy ### Tooltips Not Appearing * Check that tooltip text is configured in the Inspector * Verify the Tooltip GameObject is assigned in SceneSelectionManager * Ensure EventSystem exists in the scene for UI interaction * Check that Canvas render mode supports world space tooltips ### Signals Not Updating * Verify signals are properly initialized before adding to selectable * Check that signal GameObjects are active in the hierarchy * Ensure PLCInterface or signal source is running * Verify signal references are not null ### Selection Window Issues * Check Window GameObject is assigned in SceneSelectionManager * Verify UI Canvas and EventSystem are present * Ensure window prefab has required components (RectTransform, CanvasGroup) * Check that text components use TextMeshPro ## Best Practices 1. **Group Related Renderers**: Combine parts of the same component into a single selectable for cleaner interaction 2. **Use Descriptive Titles**: Make titles clear and include identifying information (e.g., "Motor M1" not just "Motor") 3. **Provide Helpful Tooltips**: Include status information in tooltips for quick inspection without selection 4. **Limit Signal Count**: Keep signal lists focused on the most relevant controls (5-10 signals maximum) 5. **Add Context Links**: Include links to documentation, datasheets, or maintenance procedures 6. **Update Dynamic Content Sparingly**: Only update runtime values when selected to reduce overhead 7. **Use Consistent Highlighting**: Maintain consistent colors across your application for each highlighting state 8. **Test Performance**: Profile selection interactions in complex scenes and optimize as needed ## See Also * [Signals](https://github.com/game4automation/doc/blob/doc/components-and-scripts/signals/signals.md) - Signal system for PLC communication * [UI System](https://github.com/game4automation/doc/blob/doc/components-and-scripts/ui/ui-system.md) - User interface components and controls * [Highlighting System](https://github.com/game4automation/doc/blob/doc/components-and-scripts/visual/highlighting.md) - Visual feedback and highlighting * [Drive](/components-and-scripts/motion/drive) - Drive components that integrate with selection * [Sensor](/components-and-scripts/sensors/sensor) - Sensor components for detection and monitoring # Lamp ## Overview The **Lamp** component turns any mesh into a visual status indicator — a signal tower light, a button lamp, a machine state beacon. It drives the emission color and intensity of the renderer through a `MaterialPropertyBlock`, so no per-renderer material is instantiated and GPU batching is preserved. The lamp can be switched on and off, set to flash at a configurable rate, and driven directly from PLC signals.
Lamp status indicator
{% hint style="info" %} This component was reworked in realvirtual **6.3.3** to use emission overrides via `MaterialPropertyBlock`. {% endhint %} {% hint style="warning" %} The shared material on the lamp's MeshRenderer must have **emission enabled** (URP Lit, HDRP Lit, or Standard with the `_EMISSION` keyword active) for the color override to be visible. When you add the component in the editor it assigns the built-in **Lamp** material automatically. {% endhint %} ## Properties **On Color** (Color) The emission color shown while the lamp is on. Also applied as the base color so the lamp reads correctly when unlit. **Intensity** (float) HDR emission intensity multiplier applied to the On Color. Higher values produce a stronger glow and bloom. Set to `0` for a flat, non-glowing color. **Flashing** (boolean) When enabled, the lamp blinks instead of staying steady. Can also be driven at runtime by the flashing signal. **Period** (float) Flashing period in seconds — the full on/off cycle length. The lamp is on for half the period and off for the other half. **Lamp On** (boolean) The current on/off state. Toggle it in the Inspector to test, or let the PLC signal control it. **Signal Lamp On** (PLCOutputBool) PLC signal that switches the lamp on and off. When assigned, it overrides the manual Lamp On state each frame. **Signal Lamp Flashing** (PLCOutputBool) PLC signal that enables or disables flashing mode at runtime. ## Quick Start 1. Add the **Lamp** component to a GameObject that has a MeshRenderer (e.g. a cylinder or a signal-light mesh). 2. Pick the **On Color** and adjust **Intensity** until the glow looks right. 3. To test, enable **Lamp On** in the Inspector during play mode. 4. For PLC control, assign **Signal Lamp On** (and optionally **Signal Lamp Flashing**) to your interface signals. 5. For a blinking warning light, enable **Flashing** and set the **Period**. ## Common Use Cases * **Signal tower** – Stack several lamps (red/amber/green) driven by machine-state signals. * **Button lamps** – Illuminate operator panel buttons based on PLC outputs. * **Fault indication** – Flashing red lamp tied to an alarm or collision signal. * **Status beacon** – Steady green for running, flashing amber for warning. ## See Also * [Signals and Interfaces](https://github.com/game4automation/doc/blob/doc/components-and-scripts/interfaces/README.md) *** © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. # Interact3D The Interact3D script alows you to define user interaction like pushbuttons, switches or opening of doors in the 3D scene. This script can be attached to any component with a collider. If the user is clicking on the object the status will change.
### Properties You can set the following properties **Switch**\ True if interaction should work like a switch, if false it works like a button. **MaterialOn**\ Material which should be used for Mesh renderer for the ON status of the Switch or Button. **MaterialOnMouseDown**\ Material which should be used for the Mesh renderer on mouse down. **MaterialOnBlocked**\ Material which should be used if interaction is blocked by a PLCSignal **DurationMaterialOnBlocked**\ Duration of visual feedback with MaterialOnBlocked. If user is pressing button and it is blocked by PLC the blocked status will be visualized. **MaterialPLCOn**\ Material which should be used if PLC Output signal SignalOn is true. **LightOn**\ Optional light which is turned on on ON status. **LightPLCOn**\ Optional light which is turned on if PLC Output signal SignalOn is true. **SignalIsOn**\ PLCInput if button or switch status is on. **SignalOn**\ PLCOutput to turn PLCOn Status on. **SignalBlocked**\ PLCOutput to block interaction with button (e.g. for security doors). \ \ \ \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # StatDisplay The StatDisplay system provides comprehensive real-time performance monitoring and production statistics for realvirtual simulations, enabling detailed analysis of automation system performance. {% hint style="warning" %} **Professional Version Only**: StatDisplay is exclusively available in realvirtual Professional. It is not included in the Starter version. {% endhint %} ## Requirements **TextMeshPro Required**: StatDisplay requires Unity's TextMeshPro for text rendering. TextMeshPro is included with Unity and accessible through the Window menu. ### Setting up TextMeshPro TextMeshPro is already included with Unity. To access TextMeshPro resources: 1. **Access TextMeshPro Menu**: Window → TextMeshPro 2. **Import Essential Resources**: Select "Import TMP Essential Resources" if prompted 3. **Import Examples (Optional)**: Select "Import TMP Examples and Extras" for additional resources

Accessing TextMeshPro resources through Unity's Window menu

{% hint style="info" %} **Note**: TextMeshPro comes pre-installed with Unity. You only need to import the essential resources when first using TextMeshPro components in your project. {% endhint %} ## Overview StatDisplay consists of multiple specialized components that work together to provide complete visibility into simulation performance and production metrics. The system tracks output rates, cycle times, state utilization, and operational efficiency to help optimize automation systems during virtual commissioning. Key benefits include: * Real-time production monitoring during simulation * Cycle time analysis for performance optimization * State utilization tracking for efficiency analysis * Automated statistics collection with minimal setup * Integration with realvirtual's LogicStep system > **💡 Hint** StatDisplay components work best when integrated early in the simulation development process, allowing for continuous monitoring during system development and optimization.

StatDisplay system with StatDisplayOutput component in Unity Inspector

## Component Architecture The StatDisplay system consists of five specialized components that work together: ``` StatController (Central coordinator) ├── StatDisplayOutput (Visual display) ├── StatCycleTime (Timing analysis) ├── StatStates (Utilization tracking) └── StatOutput (Production counting) ``` ### Component Roles **StatController**: Central coordinator for statistics management and reset timing **StatDisplayOutput**: Renders real-time statistics to on-screen display using TextMeshPro **StatCycleTime**: Tracks production cycle timing with min/max/average analysis **StatStates**: Monitors operational states and calculates utilization percentages **StatOutput**: Counts production output and calculates rates (parts per hour/day) ## Runtime Display The system provides comprehensive runtime visualization of all statistical data:

Complete StatDisplay system runtime view showing output stats, cycle times, and state utilization

## Quick Start ### Basic Setup (5 minutes) 1. **Create Statistics GameObject**: * Right-click in Hierarchy → Create Empty * Name it "ProductionStats" 2. **Add Core Components**: * Add **StatController** component * Add **StatOutput** component for production counting * Add **StatDisplayOutput** component for visual display 3. **Configure Display**: * Create UI Canvas if not present * Assign TextMeshPro components to StatDisplayOutput * Set reset interval in StatController (default: 60 seconds) 4. **Connect to Production**: * Use LogicStep components or direct API calls to trigger statistics * Call `StatOutput.IncrementCount()` when parts are produced ## StatDisplayOutput Component ### Properties #### Display Configuration **Stat Displays** (Array) Collection of display elements for showing different statistics. * **Type**: StatDisplayElement array * **Default**: Empty array * **Use case**: Define which statistics to show and their formatting #### Text Mesh Pro Settings **Background** Visual background component for the statistics display. * **Type**: UI Image component reference * **Default**: None * **Use case**: Provide visual background for better text readability **Padding** Display padding settings for text layout. * **Type**: Vector2 (X and Y values) * **Default**: (10, 10) * **Range**: 0 to 100 pixels * **Use case**: Adjust text spacing within the display background ### Runtime Display Features The on-screen display shows: * **Output Rate**: Current parts per hour (e.g., "308", "334") * **Total Count**: Cumulative production count * **Real-time Updates**: Live statistics that update during simulation ## StatController Component ### Properties #### Core Settings **Reset Statistics** Time interval for automatic statistics reset across all components. * **Type**: Float * **Default**: 60 seconds * **Range**: 1 to 3600 seconds (1 second to 1 hour) * **Use case**: Define how often statistics are cleared for fresh measurements #### Component Management **Stat Components** Automatically detected statistical components in the scene. * **Type**: Component array (read-only) * **Default**: Auto-populated * **Use case**: Shows which components are managed by this controller ### Functionality The StatController coordinates all statistical components by: * Synchronizing reset timing across all statistics * Providing centralized management interface * Automatically detecting compatible components in the scene ## StatCycleTime Component ### Properties #### Cycle Tracking **Auto Start Detection** Automatically detect cycle start events from connected components. * **Type**: Boolean * **Default**: true * **Use case**: Enable for automatic cycle detection, disable for manual control **Cycle Timeout** Maximum time before considering a cycle incomplete. * **Type**: Float * **Default**: 300 seconds (5 minutes) * **Range**: 10 to 3600 seconds * **Use case**: Prevent incomplete cycles from affecting statistics ### Runtime Statistics The component tracks and displays: * **Min Cycle Time**: Shortest recorded cycle (seconds) * **Max Cycle Time**: Longest recorded cycle (seconds) * **Average Cycle Time**: Mean cycle time over monitoring period * **Current Cycle Time**: Most recent completed cycle * **Cycle Count**: Total completed cycles since last reset > **💡 Hint** Use `StartCycle()` and `EndCycle()` methods in your LogicStep components to precisely control timing measurement. ## StatStates Component ### Properties #### State Configuration **Default States** Predefined operational states for tracking. * **Type**: String array * **Default**: \["Moving", "Waiting", "MoveBack", "Error"] * **Use case**: Customize states to match your automation system **Show Utilization** Display overall utilization percentage in runtime statistics. * **Type**: Boolean * **Default**: true * **Use case**: Toggle overall utilization display ### Runtime Analysis The component provides detailed operational analysis: **Overall Utilization**: System efficiency percentage based on productive vs idle time **State Breakdown**: Time and percentage spent in each operational state: * **Moving**: Active production operations * **Waiting**: Idle time between operations * **MoveBack**: Return or positioning movements * **Error**: Error or maintenance states > **💡 Hint** Call `State("StateName")` method to track state changes. States are case-sensitive and must match configured state names. ## StatOutput Component ### Properties #### Production Settings **Hours Per Day** Operating hours for daily production rate calculations. * **Type**: Float * **Default**: 24 hours * **Range**: 1 to 24 hours * **Use case**: Set actual operating schedule (e.g., 8 hours for single shift) **Parts Description** Custom label for the type of items being counted. * **Type**: String * **Default**: "Parts" * **Use case**: Specify product type ("Bottles", "Assemblies", "Packages") #### Display Options **Show Parts Per Day** Include daily production projection in the display. * **Type**: Boolean * **Default**: true * **Use case**: Toggle daily rate calculations for short-term analysis ### Runtime Statistics Displays real-time production metrics: * **Total Count**: Cumulative items produced since last reset * **Parts Per Hour**: Current production rate based on recent activity * **Parts Per Day**: Projected daily output based on current rate and operating hours > **💡 Hint** Use `IncrementCount()` or `IncrementCount(int amount)` to track production. The system automatically calculates rates based on timing. ## Editor Tools ### Inspector Features **Component Auto-Detection**: StatController automatically finds and manages compatible statistical components in the scene. **Real-time Preview**: Statistics display updates in real-time during Play mode for immediate feedback. **Reset Button**: Manual reset button in StatController inspector for clearing statistics during testing. ### Gizmos and Visual Aids **State Visualization**: StatStates component shows current state in Scene view when selected. **Connection Indicators**: Visual lines show relationships between StatController and managed components. ## Advanced Configuration ### Multi-Station Setup 1. **Separate Controllers**: Use individual StatController components for each production station 2. **Component Grouping**: Group related statistical components under station-specific GameObjects 3. **Display Coordination**: Configure multiple StatDisplayOutput components for different viewing areas 4. **Synchronized Reset**: Use global reset timing or independent station resets based on requirements ## Usage Examples ### Basic Production Monitoring #### Simple Output Counting ```csharp // In your production logic public class ProductionStation : MonoBehaviour { public StatOutput outputCounter; public void OnPartCompleted() { outputCounter.IncrementCount(); Debug.Log($"Total parts: {outputCounter.TotalCount}"); } } ``` #### Cycle Time Measurement ```csharp // Track complete production cycles public class CycleController : MonoBehaviour { public StatCycleTime cycleTimer; public StatStates stateTracker; public void StartProduction() { cycleTimer.StartCycle(); stateTracker.State("Moving"); } public void CompleteProduction() { cycleTimer.EndCycle(); stateTracker.State("Waiting"); } } ``` ### Integration with LogicStep System StatDisplay components integrate seamlessly with realvirtual's LogicStep system: #### Starting Cycle Time Tracking ```csharp public class LogicStep_StatStartCycle : LogicStep { public StatCycleTime StatCycleTimeComponent; #pragma warning disable 0414 // Suppress "field assigned but never used" warning private bool signalnotnull = false; #pragma warning restore 0414 protected new bool NonBlocking() { return true; } protected override void OnStarted() { State = 50; if (StatCycleTimeComponent != null) StatCycleTimeComponent.StartCycle(); NextStep(); } protected new void Start() { base.Start(); } } ``` #### Setting State for Utilization Tracking ```csharp public class LogicStep_StatSetState : LogicStep { public StatStates StatStatesComponent; public string SetState = "Moving"; protected override void OnStarted() { if (StatStatesComponent != null) { StatStatesComponent.State(SetState); } NextStep(); } protected new void Start() { base.Start(); } } ``` #### Advanced LogicStep Integration ```csharp // Complete production workflow with comprehensive statistics public class ProductionSequence : LogicStep { [Header("Statistics Components")] public StatCycleTime cycleTimer; public StatStates stateTracker; public StatOutput outputCounter; protected override void OnStarted() { // Initialize production cycle cycleTimer?.StartCycle(); stateTracker?.State("Moving"); // Execute production steps ExecuteProductionSequence(); } private void ExecuteProductionSequence() { // Production logic here // Complete cycle OnProductionComplete(); } private void OnProductionComplete() { cycleTimer?.EndCycle(); outputCounter?.IncrementCount(); stateTracker?.State("Waiting"); NextStep(); } } ``` #### Custom Statistics Manager ```csharp // Centralized statistics management public class ProductionStatsManager : MonoBehaviour { [Header("Statistics References")] public StatController controller; public StatCycleTime[] stationTimers; public StatOutput[] stationOutputs; public void ResetAllStatistics() { controller.ResetStatistics(); } public void GetProductionSummary() { float totalOutput = 0; foreach (var output in stationOutputs) { totalOutput += output.TotalCount; } Debug.Log($"Total Production: {totalOutput} parts"); } } ``` ### Display Customization #### Custom Display Layout ```csharp // Programmatic display configuration public class CustomStatDisplay : MonoBehaviour { public StatDisplayOutput display; void Start() { ConfigureDisplay(); } void ConfigureDisplay() { // Customize display appearance display.Background.color = Color.black; display.Padding = new Vector2(15, 15); // Add custom formatting display.ShowDecimalPlaces = 1; } } ``` ## Troubleshooting ### Statistics Not Updating **Symptoms**: Display shows static values, zeros, or outdated information **Common Causes & Solutions**: **Missing Component References** * Check that all StatDisplay components have their script references properly assigned * Verify StatController can find and manage statistical components in the scene * Ensure GameObjects containing statistics components are active **Timing Configuration Issues** * Verify StatController reset interval matches your analysis needs * Check if automatic reset is clearing data too frequently * Ensure production events are actually triggering statistical updates **Integration Problems** * Confirm LogicStep components are calling statistical methods correctly * Verify API calls like `IncrementCount()` and `StartCycle()` are executed * Check Unity Console for any statistical component error messages ### Inaccurate Cycle Times **Symptoms**: Cycle time measurements don't reflect actual production timing **Diagnosis Steps**: 1. **Verify Cycle Boundaries**: ```csharp // Ensure StartCycle() and EndCycle() are called at correct times Debug.Log($"Starting cycle at: {Time.time}"); cycleTimer.StartCycle(); // ... production logic ... Debug.Log($"Ending cycle at: {Time.time}"); cycleTimer.EndCycle(); ``` 2. **Check for Timing Conflicts**: * Multiple components calling cycle methods simultaneously * Reset operations interrupting active cycle measurements * LogicStep timing conflicts with manual cycle control 3. **Review Reset Settings**: * StatController reset interval too short for complete cycle measurement * Manual resets during active production cycles ### Display Formatting Issues **Symptoms**: Statistics appear incorrectly formatted, positioned, or illegible **Visual Display Problems**: * **Text Overlap**: Increase padding values in StatDisplayOutput * **Background Issues**: Verify UI Image component is assigned and properly configured * **Layout Problems**: Check Canvas scaling and StatDisplayOutput positioning * **Missing Statistics**: Ensure StatDisplayOutput array includes all desired display elements **UI Integration Issues**: * **Canvas Setup**: Verify UI Canvas is configured correctly for your display method * **TextMeshPro Configuration**: Check font, size, and color settings * **Z-Ordering**: Ensure statistics display appears above other UI elements ### Performance Issues **Symptoms**: Frame rate drops or stuttering when statistics are active **Optimization Solutions**: **Reduce Update Frequency**: * Increase StatController reset interval for less frequent calculations * Use fewer concurrent statistical components in large scenes * Consider separate StatControllers for different production areas **Display Optimization**: * Limit number of decimal places shown in display * Use object pooling for dynamic statistical displays * Disable statistics visualization when not needed ### Integration Debugging **Symptoms**: Statistics work in isolation but fail in complete simulation **System Integration Checks**: 1. **Component Dependencies**: ```csharp // Verify all required components are present if (cycleTimer == null) Debug.LogError("Missing StatCycleTime component"); if (stateTracker == null) Debug.LogError("Missing StatStates component"); ``` 2. **Event Timing**: * Ensure statistical events occur in correct sequence * Check for race conditions in complex automation sequences * Verify LogicStep execution order doesn't conflict with statistics 3. **Multi-Scene Issues**: * StatDisplay components may not persist across scene loads * Statistics references may break when reloading scenes * Consider using `DontDestroyOnLoad()` for persistent statistics {% hint style="warning" %} **Performance Tip**: In large simulations with many statistical components, consider using separate StatControllers for different production areas to optimize performance and organize statistics logically. {% endhint %} ## See Also * [LogicStep](https://github.com/game4automation/doc/blob/doc/components-and-scripts/behavior-graph/logicstep.md) - Core system for statistical event integration * [Runtime Debugger](/basics/runtime-ui/runtime-debugger) - Additional debugging and monitoring tools * [MU, Source and Sink](/components-and-scripts/mu-movable-unit) - Production components that generate statistics * [Performance Tools](/components-and-scripts/performance-tools) - Framework performance optimization components *** © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # State Statistics (Pro) {% hint style="info" %} This feature was added in realvirtual **6.0.7** (Professional) {% endhint %} **State Statistics** provides production state tracking with time-based statistics collection for OEE analysis, bottleneck identification, and performance monitoring. ## Overview The StateStatistics component tracks how much time objects spend in different states, enabling Overall Equipment Effectiveness (OEE) analysis and production optimization. ## Key Features * **State Time Tracking** – Measure duration in each production state * **OEE Calculation** – Support for availability, performance, and quality metrics * **Bottleneck Identification** – Identify which states consume most time * **Real-Time Monitoring** – Track statistics during simulation runtime * **Export Capabilities** – Generate reports from collected statistics ## Common Production States Typical states tracked in industrial automation: * **Idle** – Waiting for material or instructions * **Processing** – Active production or handling * **Blocked** – Cannot proceed due to downstream issues * **Starved** – Waiting for upstream material delivery * **Maintenance** – Under maintenance or repair * **Error** – In error state requiring intervention ## Usage Examples ### Basic State Tracking ```csharp // StateStatistics component tracks state changes automatically // Configure which states to monitor in Inspector ``` ### OEE Analysis Statistics collected can be used for: * **Availability** = (Total Time - Downtime) / Total Time * **Performance** = Actual Output / Theoretical Maximum Output * **Quality** = Good Parts / Total Parts Produced * **OEE** = Availability × Performance × Quality ## Common Applications * **Production Line Analysis** – Identify inefficiencies in manufacturing processes * **Bottleneck Detection** – Find which stations limit throughput * **Shift Performance** – Compare productivity across different time periods * **Continuous Improvement** – Track impact of process changes over time * **Capacity Planning** – Understand actual vs theoretical capacity ## Integration Points * Integrates with [StatDisplay](/components-and-scripts/scene-interaction/statdisplay) for visualization * Compatible with DES simulation for accelerated analysis * Exports to standard reporting formats ## See Also * [StatDisplay](/components-and-scripts/scene-interaction/statdisplay) - Real-time statistics display # UI components {% hint style="warning" %} UI components is still part of our release but you should consider using the new [HMI components](/components-and-scripts/scene-interaction/hmi-components-pro) (only available in Professional), [Screen Overlay Buttons](/components-and-scripts/scene-interaction/screen-overlay-buttons) or [3DButtons](/components-and-scripts/scene-interaction/3d-buttons) {% endhint %} UI Components can be used to display PLC Signals on the screen or to control PLC Signals during simulation. Currently the UI Components contain these components: | Component | Description | | ------------ | -------------------------------------------------------- | | UIPanel | Empty sliding panel as a container for the UI components | | UIButton | A push or toggle button | | UILamp | Lamp with different colors | | UIMessageBox | Model window for displaying messages. | The components can be arranged in a Panel (or multiple Panels) that can slide over the main view:
All UI Components should be arranged under the UI Gameobject in the Hierarchy:
### UIPanel The UIPanel is an element used as a container for Buttons and Lamps. It is opened when it is selected in the bottom of the screen with a sliding animation. It can be closed by selecting the panel name or closing icon. You can place multiple panes on the screen but the naming of the second panel and the position of the animations must be changed manually.
### UIButton The Button can be placed in a UI Panel. The Button can act as a switch (changes between on and off everytime you press it) or can act as a pushbutton (only stays at on if you press it). You can select the color and the text which is displayed under the button. The connection to PLC Inputs is made by dragging the PLC Input onto the Field *Button On* or by selecting under *Button On* the desired input.
### UILamp The lamp is used for displaying values. It can be connected to a PLC Output.
### UIMessageBox The UIMessageBox is a modal message box that is opening as an overlay over all windows in the scene. It can be turned on by a PLC Output signal.
The message box can be closed automatically after a defined time in seconds if *Auto Close After Seconds* is a value greater zero. The message box can be connected to a Cinemachine Virtual Camera for automatically zooming to the position of the message. Also some objects in the scene, that are highlighted during the message, can be selected.
Please check the [Realvirtual.io Class Reference](https://game4automation.com/documentation/current/apidoc/html/classgame4automation_1_1_u_i_message.html) for more information about the properties and methods of this component.\ \ \ \ \ \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. # HMI components (Pro, Deprecated) only available in realvirtual.io Professional {% hint style="danger" %} **Deprecated — Unity-only, superseded by realvirtual WEB.** These uGUI HMI components are deprecated and are **not read by realvirtual WEB** — the browser-based 3D-HMI is a separate, re-architected system, not a port of these components. Migration status per component: * **HMI Marker → WebSensor** and **HMI Message → WebError / WebDiagnostics + CustomRuntimeInstruction** — equivalent capability exists in realvirtual WEB via new components; use those. * **HMI Value / HMI Text** — shown in the browser via hover tooltips, signal chips, KPI cards and WebSensor labels; there is no authored per-object overlay. * **HMI Slider / Switch / Pushbutton / DropDown / Tab and the HMI panel system** — interactive operator widgets with **no realvirtual WEB equivalent**; the browser HMI is built from WebSensor / WebError, KPI and message panels, and the React plugin layer. See [**realvirtual WEB**](/extensions/realvirtual-web), the single platform for delivering browser-based 3D-HMIs. {% endhint %} {% hint style="warning" %} Please install CINEMACHINE via the package manager. [Cinemachine ](https://doc.realvirtual.io/advanced-topics/usefull-addons#cinemachine)is needed for controlling the camera position for HMI messages. Please also make sure that "CINEMACHINE" is added as Scripting Define Symbols (`Project Setting > Player > Scripting Define Symbols`) {% endhint %} HMI components are prefabricated UI components used to create 3D interfaces for automation systems. They can be connected to signals and integrated with various PLC interfaces such as [S7TCP](/components-and-scripts/interfaces/s7-tcp), [TwinCAT](/components-and-scripts/interfaces/twincat), [TwinCAT HMI](/components-and-scripts/interfaces/twincat-hmi), [EthernetIP](/components-and-scripts/interfaces/ethernetip), [OPCUA ](/components-and-scripts/interfaces/opcua)and more.

HMI example with error message

## Overview HMI components are organized into "Tabs" which are overlays on the 3D scene and can be opened and closed by buttons or certain events. All HMI components can be connected with Signals and by this the can control or display scene or machine data. Certain HMI components can utilize Unity's Cinemachine to manage multiple cameras and camera positions. To enable this functionality, ensure that you have the required [compile definition](/advanced-topics/compiler-defines) in place The following components can be used for building individual HMI interfaces: * [HMI Tab](/components-and-scripts/scene-interaction/hmi-components-pro/hmi-tab) * [HMI Pushbutton](/components-and-scripts/scene-interaction/hmi-components-pro/hmi-puschbutton) * [HMI Switch](/components-and-scripts/scene-interaction/hmi-components-pro/hmi-switch) * [HMI Value](/components-and-scripts/scene-interaction/hmi-components-pro/hmi-value) * [HMI Text](/components-and-scripts/scene-interaction/hmi-components-pro/hmi-text) * [HMI Slider](/components-and-scripts/scene-interaction/hmi-components-pro/hmi-slider) * [HMI Drop Down](/components-and-scripts/scene-interaction/hmi-components-pro/hmi-dropdown) * [HMI Message](/components-and-scripts/scene-interaction/hmi-components-pro/hmi-message) ## Supported Use Cases HMI components offer various use cases when combined with real machine controls. These include: 1. Displaying custom texts, such as IDs of machine components at 3D positions 2. Changing data on the industrial control by pushbuttons, sliders and pulldowns and switches 3. Representing sensor states as colored elements (booleans) at 3D positions 4. Showing values like axis positions and temperatures as 2D overlays or within the 3D scene 5. Presenting messages (normal, warning, and failure) that are connected to PLC outputs and inputs, allowing for acknowledgments. These messages can trigger specific 3D views and initiate custom animation sequences based on logical steps. ## Demo scene The HMI demo scene contains most of the realvirtual.io HMI functions. You find the demo scene `realvirutal/professional/HMI/Demo/DemoHMI.` Within the Demo folder you find also a scene with an example how to set up your own HMI. The scene ["emptyHMIscene"](/components-and-scripts/scene-interaction/hmi-components-pro/start-your-own-hmi) is an example which can be used as a HMI prefab. The basic elements of this scene are available as prefabs.
## Common properties The following attributes are available at all interactive HMI components.
* `Color`: standard of the element when no user interaction * `Color Mouse` Over: color when the mouse pointer is on the element * `Alpha Visibility`: determine the occupancy of the element * `EventOnValueChanged`: Unity event when the value of the connected signal is changing ### HMI Controller The HMI controller must be added as a component to the topmost GameObject in the HMI area. It manages camera position changes and can also restrict mouse navigation for the user.
--- [Next Page](/llms-full.txt/1)