How to test a machine before the first part exists - principles, tools and examples in the open Unreal Engine environment
A virtual prototype is a digital machine that behaves like the real one. It has mass, drives, joints and controls, so you can load it, move it, connect a control program to it or walk around it in virtual reality. This guide explains how it works, where it is used today and what you need to get started.
Say “virtual prototyping” and most people picture expensive engineering suites in which a specialist spends weeks tuning a mesh to produce a colourful stress plot. Those tools have their place. This guide takes a different route.
Over the last few years game engines have become full simulation platforms. Unreal Engine now powers simulators for autonomous cars, robots and drones as well as factory digital twins. Combined with an engineering-grade physics engine, it lets you build a machine with real mass, drives and controls - and work with it in real time: drive it with a joystick, connect a PLC, walk around it in VR or train AI on it.
I wrote this guide for design engineers, R&D managers, automation engineers and students. You will find no equations; instead there are analogies, diagrams and examples. After reading it you should know what a virtual prototype can and cannot do, when it pays off, what data and people it needs, and how to proceed.
How to use this guide
Chapters build on each other, but each can be read on its own. Four kinds of boxes repeat throughout to help you find your way:
Opening paragraphWhat the chapter is about and why it matters.
Think of it this wayAn everyday analogy to grasp the principle quickly.
ExampleHow the model company Hoist Ltd. applied the principle.
Key takeawaysThe chapter summarised in a few points.
Question finder: what are you dealing with?
No time to read everything? Find your question and jump straight to the right chapter.
Your question
Where to find the answer
What exactly is a virtual prototype, and how is it different from a 3D model?
The model company Hoist Ltd. (fictional) makes hydraulic loader cranes mounted on trucks. It is developing a new, longer boom with a 10 m reach. So far it has worked the classic way: design, build a prototype, test it in the yard, modify, repeat. Each loop took more than two months.
Rated capacity and static stability in a given position are calculated conventionally to the standard - no model needed for that. What the engineers don't know is what happens in motion: how the load swings when the operator stops slewing abruptly, whether an outrigger lifts off as a result, whether the load-moment limiter reacts in time when several cylinders move at once, whether the boom touches the cab while folding, and whether the operator can see the hook from the control station.
Exactly these questions - events over time, the interplay of mechanics and control, and the person at the machine - are what a virtual prototype is for. Each chapter shows how Hoist would use it.
01 · Basics
What is a virtual prototype
A virtual prototype is a digital model of a product that behaves like the real product. It is not just about how it looks: the model knows how much it weighs, where its centre of mass is, how its joints move, how hard its drives push and how its software controls it. That makes it testable much like a physical prototype - only inside a computer.
Think of it this way
Looking at the concept of a new car, you can see that everything fits and holds together. What you can't see is how it behaves on the move: how it accelerates, how it leans in a corner, when it starts to slide on a wet road. That is why carmakers try it out in driving simulators before they build a physical prototype. A virtual prototype works the same way - except that instead of a car it runs your machine with its real parameters, and you measure forces and motion. If you don't like the result, change a parameter and try again.
Formally, it means modelling, simulating and visualising a system under operating conditions and refining the design iteratively without building physical units. In practice you can load the machine, move it, crash it into an obstacle, let a program or a person control it and watch what happens - repeatedly, safely, measuring everything you care about.
A virtual prototype does not replace physical testing entirely. Its job is to make sure that an already-debugged design reaches the test rig and that physical loops are kept to a minimum. Typically you end up with one validation prototype instead of several development ones.
Four layers of a virtual prototype
It helps to think of the prototype as a four-tier cake. Not every project needs every tier - and the more tiers, the more data and work (see Five fidelity levels).
layer 1
Geometry
Shape and dimensions at a true 1:1 scale, usually taken from CAD. Answers whether everything fits and how it looks.
Does the folded boom fit behind the cab?
layer 2
Physics
Masses, centres of mass, joints, drives, friction, ropes, contacts. Answers how the machine moves and what forces act in it.
How does the load swing when the operator stops slewing abruptly?
layer 3
Control & sensors
Control logic (PLC, controllers, autonomy) and sensor models. Answers whether the machine does what it should and how it reacts.
Does the load-moment limiter stop the motion in time?
layer 4
People & environment
Operators (e.g. in VR), terrain, the plant, other machines. Answers how the machine is used in real conditions.
Can the operator see the hook from the controls?
A virtual prototype is built in layers. Each additional layer answers another kind of question.
Digital mock-up, virtual prototype, digital twin
Three terms that are often confused. They differ in what the model can do and when in the product's life it is created.
Digital mock-up (DMU)
Virtual prototype
Digital twin
What it is
A static 3D assembly of the product
A model that behaves like the product
A model linked to a specific existing unit
When it is made
During design
Before production, instead of development prototypes
After commissioning
Where its data comes from
CAD
CAD, datasheets, calculations and tests
Plus live sensor data from the real machine
Typical question
Does it fit? Does it collide?
Will it work? How does it behave?
What is happening now? What will happen next week?
The boundaries are not sharp: once production starts, a good virtual prototype often becomes the basis of a digital twin. It pays to build it from the start so that it can be connected to real data.
Key takeaways
A virtual prototype shows not just the shape but how the machine behaves in motion.
It is built in layers: geometry, physics, control, people and environment.
It does not replace all testing; it reduces the number of physical loops.
A digital twin is linked to an existing machine; a virtual prototype exists before the machine does.
02 · Value
Why prototype virtually
Every change to a physical prototype costs material, labour and, above all, time. A virtual prototype can be modified and retested in a fraction of that time. But it is not only about savings: when a test is cheap, you dare to try unusual ideas too.
Linear development vs. simulation-driven development
Top: linear development with physical prototypes. Bottom: simulation-driven development (SDPD) - the design–test loop runs virtually.
Many companies develop linearly: concept → design → physical prototype → testing. If the test fails, they go back to design and the whole loop repeats. Each round costs weeks and serious money.
In simulation-driven product development (SDPD) the design–test loop runs in a virtual environment. Only a design that has passed virtual testing is built physically. The first physical unit then serves mainly for validation - and sometimes goes straight into production.
The key difference is the speed of learning. A virtual loop takes hours to days, so the same time allows ten times more attempts. And because it is cheap, production, service, sales and the customer can join in - before anything is built.
The cost of late change
The indicative “rule of ten”: the later an error is found, the more expensive it is to fix.
Practitioners often quote the indicative rule of ten: an error that costs 1 to fix in design costs roughly 10 at the prototype stage, 100 in production and 1,000 at the customer. The exact numbers vary by industry, but the principle holds everywhere.
A virtual prototype moves error discovery to the left - into the phase where a change is just an edit to the model. That is why it pays off especially for products with expensive prototypes, risky tests or several expected development loops.
Think of it this way
It is like trying on clothes in an online shop with a virtual fitting room. You don't have to order five sizes and return four; you try them on straight away. In the end you still order one and put it on - but you already know it fits.
Calculator: does a virtual prototype pay off?
Compare the cost and time of both approaches for your project. The virtual route has an entry cost (building the model), but each further loop is cheap. A final physical validation prototype is included.
Physical vs. virtual prototypingDefault values are illustrative - enter your own
How many times the design is changed and retested
loops
Building the prototype, changes, testing, labour
EUR
From design change to test result
weeks
Data preparation, model, physics, controls (one-off)
EUR
Until the model is ready for the first test
weeks
Model change, runs, evaluation
EUR
Usually days
weeks
How many units are built at the end anyway
pcs
Cost
Physical prototypes
Virtual + validation
Time to a validated design
Physical prototypes
Virtual + validation
The virtual route is cheaper by 34,500 EUR and faster by 21 weeks.
Break-even: a virtual prototype pays off financially from 3 development loops.
Excludes benefits that are hard to quantify: earlier market entry, fewer warranty claims, safe testing of risky situations and reuse of the model for training and sales.
What a virtual prototype delivers
Fewer physical prototypes and shorter development
Tests of situations that are dangerous or impossible for real (abrupt stops, collision, failure)
Comparison of many design variants instead of one or two
Control software developed alongside the mechanics, not on the finished machine
Production, service and sales review the design from day one
Customers see and “touch” the machine before it exists
The model is reused for operator training, marketing and service manuals
Measure everything: forces, speeds, collisions, times - no sensors or cables
Example: Hoist Ltd.
Hoist Ltd. expects five development loops for the new boom. Physically that would mean EUR 75,000 and more than nine months. With a virtual prototype development costs roughly half and the validated design is ready in under five months. Try the numbers in the calculator above.
Key takeaways
A virtual loop is an order of magnitude faster and cheaper than a physical one.
You find errors earlier, when fixing them is cheapest.
It pays off most for expensive prototypes, risky tests and multiple development loops.
Physical validation at the end remains - just one unit instead of several.
03 · Principle
How real-time simulation works
A game engine does not compute physics “all at once”. It splits time into very short steps and, in each one, works out where everything has moved. If the steps are short enough and the computation fast enough, you get smooth motion you can interact with in real time.
Think of it this way
Remember flip-book cartoons drawn in the corner of a notebook? Each page is one moment, and if you flip fast enough the figure runs. A simulation does the same: each “page” is one time step, typically a hundredth of a second or less. The difference is that the simulation computes each next page from the laws of physics - and you can step in at any moment.
The simulation loop and the time step
In every step Δt the simulation runs through the same loop: inputs → physics → sensors and logging → rendering.
The loop repeats tens to hundreds of times per second. The length of one step is the time step (Δt). A shorter step means a more accurate and stable result, but more computation. Machines with fast dynamics (impacts, stiff springs, hydraulics) therefore often compute physics in several smaller sub-steps per rendered frame - known as substepping.
For engineering use, a fixed time step matters: physics always advances by the same Δt, no matter how fast the image is being rendered. Only then do repeated runs give the same results. Unreal Engine supports this with asynchronous physics at a fixed step; engineering physics engines (AGX, MuJoCo) use a fixed step by default.
What happens in one step
Inputs
Commands from the controller (PLC, autonomy, script) or a person (joystick, VR controller).
Forces & drives
Gravity, motors, hydraulic cylinders, springs, dampers, friction.
Collisions & contacts
Which parts touch and how hard they push against each other.
Solver
Computes new positions and velocities of all bodies so that joints hold and nothing interpenetrates.
Sensors & logging
Virtual sensors measure distances, forces and angles; data is written to a log.
Rendering
The image is drawn on the monitor or in the VR headset. Then everything again.
Collision shapes: what you see vs. what is computed
Left: the CAD render mesh (thousands of triangles). Right: simplified collision shapes used by the physics.
A CAD model often has millions of triangles. Checking each against every other in every step would be far too slow. Physics therefore works with collision shapes - simplified envelopes made of boxes, cylinders, spheres and convex hulls. On screen you see the detailed part, but collisions are computed with its simplified “shell”.
The quality of collision shapes determines the result. Shapes that are too coarse cause false collisions or gaps; shapes that are too fine slow the simulation down. Preparing collisions is therefore one of the most laborious steps - and where most mistakes happen.
Solver, joints and drives
In a simulation a machine consists of bodies (boom segments, wheels, frame) and constraints between them (pin, slider, ball joint). A constraint defines how bodies may move relative to each other. Drives can be attached to constraints: a motor with torque, a linear actuator or a hydraulic cylinder.
The solver is the part of the physics engine that, in every step, finds new positions and velocities that satisfy all constraints and contacts at once. Game solvers usually iterate approximately - it only has to “look right”. Engineering physics engines such as AGX Dynamics or MuJoCo solve constraints more accurately, so they handle long chains of bodies, heavy loads on ropes or large mass ratios without “rubbery” behaviour.
Why it matters
A typical game-physics failure: a crane with a 10 t load on a light rope starts to jitter or the rope “stretches”. That is not a modelling error but a solver limitation. For machines with large mass ratios, ropes and hydraulics, choose an engineering physics engine (see Physics engines).
Speed vs. accuracy
Indicative map: tools differ in how fast they compute and how accurate the result is. An engine with an engineering physics core is a compromise of both.
Every simulation is a compromise. Kinematic animation is instant but knows nothing about forces. Game physics is fast and stable but simplified. Engineering physics in an engine (AGX, MuJoCo) keeps real time while computing constraints and contacts credibly. Classic CAE (FEM, CFD, offline multibody) is the most accurate but takes minutes to days and offers no interaction.
A virtual prototype in an engine aims for the top-right corner reachable in real time: accurate enough for design and control decisions, fast enough for interaction, VR and thousands of repeated runs.
Real-time engine or classic CAE?
It is not either/or. An engine and classic engineering analysis (CAE) answer different questions. The table helps decide what goes where.
Question
Real-time engine
Classic CAE
Does the mechanism fit its envelope and move without collisions?
Yes, fast and interactive, even in VR
Yes (CAD kinematics), no interaction
Rated capacity and static stability in a given position (reach, tilt)?
Unnecessary - a conventional calculation will do
Yes - even a hand calculation to the standard
How does the machine behave in motion: load swing, braking shocks, outrigger lift-off?
Yes, with an engineering physics engine and validation
Yes (offline multibody), more accurate, slower
Does the control program (PLC), sequence and safety logic work?
Yes - virtual commissioning
Usually not
How is the machine operated, what does the operator see and reach?
Yes - VR and interactive operation
No
Can autonomy or AI learn under varied conditions?
Yes - photorealistic sensors, fast runs
Limited
Will a part withstand the load? Where will it crack, what about fatigue?
No - the engine only supplies forces for the analysis
Yes - FEM
How do air, oil and heat flow?
No - only approximate visual effects
Yes - CFD, thermal analysis
Basis for certification and standards?
No, not on its own
Yes, together with physical tests
Established CAE suites (Ansys, Siemens Simcenter, Dassault SIMULIA, Altair and others) are indispensable for strength, flow and certification analysis. In practice both are combined: the engine finds critical situations and computes the forces; CAE turns them into stresses.
Key takeaways
Simulation advances in short time steps; repeatability needs a fixed step.
Physics does not use the detailed CAD mesh but simplified collision shapes.
A game solver is fine for kinematics and simple dynamics; ropes, hydraulics and heavy loads need an engineering physics engine.
Strength, fatigue and flow are computed in CAE; the engine supplies the loads and critical situations.
04 · Practice
Where virtual prototyping is used today
Real-time engines have moved from visualisation to the core of development. According to Epic Games, the simulation industry is shifting “from building tools that train humans to building tools that train machines”: robots, autonomous vehicles and drones. Alongside that, the classic tasks remain - functional verification, virtual commissioning and operator training.
Eight use cases
Function and space verification
Reach, collisions, motion sequences, assemblability and service access on a 1:1 model.
Does the crane boom fold without hitting the cab?
Virtual commissioning (VC)
The real control program (PLC) is connected to a virtual machine and debugged before the machine exists. Terms and model types are described in the German guideline VDI 3693.
Testing a packaging line sequence a month before assembly.
Testing control and autonomy
The machine's software runs against the simulation (software-in-the-loop), or a real controller does (hardware-in-the-loop).
An autonomous loader runs a thousand scenarios overnight.
AI training and synthetic data
The engine knows every pixel of the scene, so it labels images automatically. Varying weather, light and layout makes models more robust.
A camera learns to detect pallets under different lighting.
Operator simulators
Operator training on a machine that behaves like the real one. A prototype becomes a simulator before the machine is on the market.
A crane operator practises placing a load precisely.
Design review and ergonomics in VR
The team and the customer walk around the machine at 1:1 scale, checking visibility, reach and maintenance access.
View of the hook from the control station.
Sales, configurators and service
Interactive demos at trade fairs and in the browser (Pixel Streaming), equipment variants, 3D service and assembly instructions.
A customer configures a crane online and sees it in motion.
Layout and material flow
The machine in the context of a plant or site. For long periods and whole operations a dynamic production simulation is a better fit; physics is applied to critical spots.
Can the truck with the crane pass the gate and turn in the yard?
Platforms built on Unreal Engine
The simulators built on the engine show that it can handle serious engineering work. Some are open source and can serve as a ready-made foundation; others are commercial products.
Source: Epic Games (2026) and project websites; as of 10/2026. A selection, not a complete list.
Open-source plugin combining UE rendering with MuJoCo physics.
Example: Hoist Ltd.
Hoist Ltd. uses the virtual prototype of the new boom three times: engineers verify how the boom behaves in motion and its reach, automation engineers debug the load-moment limiter before the wiring is finished, and sales turns it into an interactive trade-fair demo. One model, three departments.
Key takeaways
Main uses today: functional verification, virtual commissioning, autonomy and AI, operator training.
Unreal Engine is the foundation of many professional simulators (CARLA, AURELION, Falcon…).
One model serves engineering, automation, training and sales.
05 · Tools
An open stack with Unreal Engine
A virtual prototype doesn't have to rely on one vendor's closed suite. It can be assembled like a construction kit: an engine for rendering and interaction, a physics engine matched to the accuracy you need, and open standards to connect CAD, PLCs, robotics software and models from other tools.
What “open environment” means
Unreal Engine is not open source in the strict sense, but it is source-available: the full source code is available on GitHub after registration and can be modified. You can add your own physics, sensors or communication and are not limited to what a vendor happens to support.
The other half of openness is standards: STEP for geometry, OPC UA for industrial communication, ROS 2 for robots, FMI for exchanging simulation models, OpenXR for VR. They let you connect the prototype to tools you already use.
The virtual prototype toolkit: data comes in through importers, the engine links it to physics, control and outputs.
Unreal Engine
Unreal Engine by Epic Games is an engine for real-time graphics and interaction. For virtual prototyping these parts of it matter most:
NaniteRenders detailed geometry from CAD and 3D scans without manual optimisation.
Lumen and ray tracingRealistic light and reflections - important for design review and camera simulation.
Chaos PhysicsBuilt-in physics: rigid bodies, constraints, vehicles, cloth, destruction; double precision according to Epic.
Blueprint and C++Machine logic visually (Blueprint) and in code (C++) - from prototype to high-performance implementation.
Python and Remote ControlEditor automation, batch runs of variants, controlling the simulation from other programs.
OpenXRSupport for VR and AR headsets for design review and training.
Sequencer and Movie Render QueueVideos and renders from the prototype for presentations and marketing.
PCG and Learning AgentsProcedural environment generation and AI training through reinforcement and imitation learning.
Physics engines: what computes the motion
The physics engine is the “brain” that computes motion. Choosing it is the most important technical decision in the project because it determines how accurate your results will be.
part of UE
Chaos Physics
Rigid bodies, joints, drives, vehicles (Chaos Vehicles), cloth and destruction. Handles thousands of bodies and is built into the engine.
Best for
Kinematics, conveyors, simpler dynamics, interaction and VR.
Licence
Included with Unreal Engine.
Algoryx
AGX Dynamics for Unreal
Engineering multibody physics: hydraulics, drivetrains, ropes and cables, tracks and wheels, deformable terrain. The plugin source is on GitHub.
Best for
Cranes, heavy and mobile machinery, robotics, operator simulators, autonomy.
Licence
Commercial AGX Dynamics licence; trial and academic licences on request.
Google DeepMind
MuJoCo
Accurate contact dynamics designed for robotics and control. It can be brought into UE, for example, with the open-source plugin Unreal Robotics Lab; physics runs on its own thread while the engine renders.
Hydraulics, a drivetrain or a thermal system can be modelled in Modelica or Simulink, packaged as an FMU and run in UE - for example with the open-source UEFMI plugin (ORNL).
Best for
Subsystems you have already modelled elsewhere.
Licence
The FMI standard is open; licensing depends on the tool that created the FMU.
Connectivity: linking the prototype to the outside world
The strength of an open stack is connectivity. A prototype doesn't have to be a closed world; it can receive CAD data, listen to a real PLC or robotics software and send results onward.
Interface
What for
How in UE
Datasmith / Interchange
CAD and BIM models into the engine
Direct import of STEP (AP203/214/242), CATIA, NX, SolidWorks, Creo, JT, IFC, Revit - see our Datasmith guide
RealityScan
3D scans of the environment (plant, terrain)
Photogrammetry, laser and SLAM point clouds → mesh for UE
OPC UA
PLCs and industrial communication (virtual commissioning)
Plugin built on an open-source library (e.g. open62541) or a commercial connector; a physical PLC or its simulator
ROS 2
Robotics software, navigation, sensors
rclUE (Rapyuta Robotics), ROSIntegration; CARLA has native ROS 2
FMI / FMU
Models from Modelica, Simulink and others
UEFMI plugin (ORNL), custom integration
Simulink
Controls
Simulink 3D Animation (MathWorks)
gRPC, REST, Python
Automation, batch runs, links to your own systems
Remote Control API, Python scripts, custom plugin
OpenXR, Pixel Streaming
VR headsets, demos in the browser
Built-in UE plugins
Licensing and cost
Unreal Engine is free for companies with annual gross revenue under USD 1 million, for students and for education. Companies above that threshold that do not make games pay a subscription of USD 1,850 per seat per year (Epic Games pricing). Games and applications sold to end users follow different terms.
On top of the engine come licences for the physics engine (AGX is commercial, Chaos and MuJoCo are not) and possibly for connectors and PLC simulators. The biggest cost item, however, is usually not licences but the work of preparing data and building the model.
Check current terms
Pricing and licence terms change. The figures above reflect the state as of 10/2026; verify them with Epic Games and the plugin vendors before deciding. Do not treat the licensing information in this guide as legal advice.
Key takeaways
Engine (UE) + physics engine + open standards = a toolkit without vendor lock-in.
The physics engine determines accuracy: Chaos for simpler tasks, AGX or MuJoCo for engineering work.
OPC UA, ROS 2 and FMI connect the prototype to PLCs, robots and models from other tools.
06 · Resources
What a simulation needs
A good virtual prototype rests on four resources: data, people, hardware and time. Data is most often the missing piece - and without it even the best engine is just a nice animation.
Think of it this way
A simulation is like a recipe. The engine is the kitchen, the physics engine the oven. But if you don't know how much of each ingredient to use and how long to bake, even a professional kitchen won't help. Data are the ingredients and their quantities - and the result can never be better than the ingredients.
Five fidelity levels
The higher the level, the more questions the prototype answers - and the more data and work it needs.
The first step is not collecting data but deciding which question the prototype must answer. That defines the required fidelity level, and the level defines the data list. Always building the highest level is expensive and unnecessary.
1
Visual modelAppearance, proportions, space.CAD or 3D scan, materials
DynamicsForces and shocks in motion, cycle times.+ masses, centres of mass, drives
4
Contact and complianceFriction, ropes, hydraulics, terrain.+ material parameters, measurements
5
Control and validationReal PLC/software, sensors, validated predictions.+ control program, validation data
Input data: a checklist
The checklist helps you prepare inputs. Most of the data already exists in the company - it is just spread across engineering, purchasing and automation. The “If missing” column shows how a missing item can be substituted.
Priority A = without it the prototype cannot answer the question, B = significantly improves the result, C = as needed.
Input
Where to get it
If missing
Priority
Geometry and mass
1:1 3D geometry
CAD (ideally STEP or native format)
3D scan, simplified model from drawings
A
Masses, centres of mass, moments of inertia
CAD with assigned materials (mass properties)
Weighing parts, estimate from volume and density
A
Assembly structure
CAD assembly tree, bill of materials
Manual split into moving groups
B
Motion and drives
Joints, axes, ranges, end stops
Kinematic diagram, drawings
Measurement on a similar machine
A
Drive characteristics
Datasheets of motors, gearboxes, cylinders (torque, pressure, flow, speed)
Simplified drive with force and speed limits
A
Ropes, cables, hoses
Catalogue (diameter, mass per metre, stiffness)
Typical values for the type
B
Contact and environment
Friction and restitution between materials
Tables, measurements
Table values + sensitivity analysis
B
Environment (plant, terrain, ground)
BIM, 3D scan, map data
Simplified plane, typical slope
B
Loads and materials handled
Customer specification
Typical and limit cases
B
Control and sensors
Control logic
PLC program, I/O and tag list, sequence description
The most important input is not data but the question
“We want a virtual prototype of the machine” is not a brief. “We want to know whether, during an emergency slew stop with a 1,200 kg load at 8 m reach, the opposite outrigger lifts off and how long the load takes to settle” is. A good question tells you which data you need and when you are done. And if a conventional calculation answers the question, don't build a simulation.
Hardware
Machine physics loads mainly the CPU, rendering the graphics card. The table gives practical recommendations for engineering work - beyond Epic Games' minimum requirements.
Indicative recommendations as of 10/2026. Choose the actual setup by scene size and number of physics bodies.
Powerful PC + PC VR headset, or a standalone headset linked to a PC
1:1 design review, ergonomics, training
Batch runs and AI
Linux server or cloud with GPU, headless runs, containers
Hundreds of variants and scenarios overnight, synthetic data
Browser demo
GPU server for Pixel Streaming
Show the prototype to anyone without installation
Controls
Joystick, wheel, pedals, or a replica of the real control panel
Realistic operation by an operator
Team
For a smaller project two people covering several roles are enough. The key, however, is the involvement of the client's design engineer: they know the machine, provide the data and judge whether the model behaves correctly.
Simulation engineer
Mechanics and the physics model: bodies, constraints, drives, parameters, validation.
Unreal Engine developer
Blueprint and C++, logic, interfaces (OPC UA, ROS 2), measurement and outputs.
PLC, control logic and I/O - only for virtual commissioning.
Client's design engineer
Questions, data, criteria and expert review of the model's behaviour.
How long it takes
Indicative values for one machine or workstation when data is available. Missing data extends the timeline the most.
Scope
Indicative duration
Typical output
Kinematic study (level 2)
days to 2 weeks
Reach, collisions, video, VR walkthrough
Dynamic machine prototype (level 3-4)
3-8 weeks
Force histories over time, variants, CSV data
Virtual commissioning of a line (level 5)
1-3 months
Debugged PLC program, test report
Operator simulator
2-6 months
Training application with scenarios and scoring
Key takeaways
Question first, then the fidelity level, then the data list.
Masses, kinematics, drives and success criteria are essential; the rest can be substituted for now.
Physics loads the CPU; rendering and VR load the GPU.
Without the client's design engineer the model cannot be validated.
07 · Workflow
Step-by-step workflow
Eight steps from the question to a validated result. In practice, steps 3-6 repeat several times - the model is built gradually and each layer is checked before the next one is added.
Ask the question and set criteria
What exactly we are verifying, in which scenarios, and when the result counts as a pass. This defines the fidelity level.
During an emergency slew stop with a 1,200 kg load at 8 m reach, no outrigger may lift off; the load settles within 5 s.
Collect data
Using the checklist. Replace missing items with estimates and note that you did.
Boom and chassis CAD, cylinder catalogue, segment masses, load chart.
Prepare the geometry
Import via Datasmith, merge parts into moving groups, set pivots at pin axes, create collision shapes.
2,400 parts become 9 moving groups with simple collision shapes.
Build the physics model
Bodies with mass and centre of mass, constraints, drives with real limits, materials and friction.
Segments as bodies, pins as joints, cylinders as hydraulic drives in AGX.
Connect controls and inputs
Logic in Blueprint/C++, or a real PLC (OPC UA), robotics software (ROS 2), a joystick or VR.
Joystick control and a model of the load-moment limiter.
Measure
Virtual sensors and logging of the quantities that answer the question. Output to CSV, charts and video.
Outrigger forces, tilt angle, load swing.
Validate
Compare with measurements or calculations and check sensitivity (see Validation).
Outrigger forces match measurements on the previous crane model within 6%.
Iterate variants
Parameterise the model and run variants in batches (Python, command line), ideally overnight.
40 combinations of slew deceleration ramp and valve damping; the winning setting goes into the controller.
Validation: can we trust the model?
Verification checks that the software computes the model correctly; validation checks that the model matches reality.
A nice picture proves nothing. Trust in a model is built by two checks. Verification answers “are we computing the model right?” - free of setup, unit and parameter errors. Validation answers “are we computing the right model?” - does it behave like reality within the range we use it for.
Frameworks for assessing model credibility include NASA-STD-7009 and the ASME V&V family of standards. For a typical industrial project, the simple checklist below, documented assumptions and a clearly stated range of validity are enough.
Think of it this way
A cookbook can be free of typos (verification) and the recipe can still taste bad (validation). The only way to find out is to taste it - for a model, to compare it with real measurements.
Static check: total mass and centre-of-mass position match CAD
Simple cases agree with hand calculation (equilibrium, pendulum, free fall)
Halving the time step gives practically the same result
Results match measurements at several points (test rig, previous machine)
Sensitivity: does the conclusion change if uncertain parameters (friction, stiffness) shift by ±20%?
Assumptions and range of validity are written down and approved by the client
Key takeaways
Build in layers and check each one before adding the next.
Measure only what answers the question - but measure it properly.
Verification = computing it right; validation = computing the right thing.
A parameterised model can try dozens of variants overnight.
08 · Examples
Six practical examples
Six typical tasks prototyped in Unreal Engine today. For each you will find the question, what is simulated, which data is needed, which tools are used, what the output is and where the limits lie.
Question: How does the load swing when slewing stops abruptly? Does an outrigger lift off as a result? How should motion ramps be set so operation is fast yet safe?
What we simulate
Multibody model of the boom with hydraulic cylinders and valves, outriggers in contact with the ground, a load on a rope or chain, a load-moment limiter and joystick or VR control.
Data needed
Boom and chassis CAD (STEP)
Segment masses and centres of mass
Cylinder strokes, diameters and pressures, valve flow rates
Time histories of outrigger forces and load swing (CSV), recommended motion ramps, video and VR demo.
Watch out for: Calculate rated capacity and static stability conventionally to the standard; the prototype covers what happens in motion. The engine does not compute weld strength or fatigue - pass the dynamic forces to FEM.
Automation
Robot cell and virtual commissioning
Fidelity level5/5
Question: Does the cell meet a 12 s cycle time? Does the robot collide with the fixture? Does the PLC program work before the hardware arrives?
What we simulate
Robot, conveyor, fixtures and light curtains; the real PLC program runs in a PLC simulator and talks to the model over OPC UA.
Data needed
Cell and part CAD
Robot kinematics (e.g. URDF), axis speeds and accelerations
PLC I/O and tag list
Description of sequences and safety functions
Tools
Unreal EngineChaos (collisions)OPC UA pluginVendor PLC simulator
Output
Debugged PLC program, verified cycle time, collision list, log of tested scenarios.
Watch out for: The exact robot path and cycle time are computed by its controller. The engine model is an approximation - use the robot vendor's offline programming for precise cycle times.
Logistics
Conveyor and parcel sorting
Fidelity level3/5
Question: Will the sorting diverter jam at peak? What spacing between parcels prevents them from getting stuck?
What we simulate
Hundreds of rigid bodies on belts with friction, diverters and sensors, random arrival of parcels of different sizes and weights.
Data needed
Parcel dimensions and weights (distribution)
Belt speeds, transfer geometry
Belt-to-packaging friction
Diverter logic, peak arrival profile
Tools
Unreal EngineChaos (fixed time step)Blueprint/C++CSV export
Output
Throughput, jam spots (heatmap), recommended spacing.
Watch out for: For a whole warehouse and long periods a discrete flow simulation is faster. Use physics only on the critical section.
Mobile machinery
Machine on terrain: traversability and tilt
Fidelity level4/5
Question: Can the machine climb a muddy slope? When does it start slipping and how does it tilt?
What we simulate
Chassis with wheels or tracks, engine and transmission, deformable terrain, controlled by an operator or an autonomous system.
Data needed
CAD and mass distribution
Engine and transmission characteristics
Tyre or track parameters
Terrain model (scan, elevation) and soil properties
Tools
Unreal EngineAGX Dynamics (terrain, wheels, tracks)RealityScanChaos Vehicles for simpler tasks
List of design-review findings, comparison of variants, VR recording.
Watch out for: VR does not show forces or fatigue. For assessment against ergonomic standards, add an ergonomic analysis.
Want to tackle a similar task on your machine? See how we offer virtual prototyping as a service.
09 · Next
Next steps
A virtual prototype is not the final stop. Once the model exists, it opens the way to further approaches - from automatic shape generation to a digital twin of the machine in operation.
Generative design
Software proposes the shape of a part from given goals and constraints. You then verify the chosen part in the virtual prototype of the whole machine.
Parameter optimisation
Batch runs of variants (design of experiments) find the best combination of dimensions, masses and control settings.
Digital twin
After commissioning, the prototype is connected to sensor data from the real machine: monitoring, diagnostics, failure prediction.
Operator training
The prototype becomes a training simulator with scenarios, scoring and error logging.
Marketing and sales
Photorealistic renders, animations, configurators and interactive demos without a physical unit.
Shared data (PLM, PIP)
A product innovation platform keeps data, versions and comments from all departments in one place.
Key takeaways
A model, once built, can be reused: optimisation, twin, training, sales.
Build the prototype so it can later be connected to real data.
10 · Limits
Limits and common mistakes
A virtual prototype is a powerful tool, not a magic wand. These are the mistakes we see most often - and they can be avoided.
Bad data, bad result
Guessed masses and friction without a sensitivity analysis lead to convincing but wrong conclusions.
A nice picture is not proof
Photorealistic rendering invites trust. Correctness is decided by validation, not render quality.
Real-time compromises
Simplified collisions, artificial damping and too long a time step can distort fast events. Check time-step independence.
Sim-to-real gap
What works in simulation may not work in reality - especially for sensors and autonomy. Add noise, latency and variability.
An engine is not a structural analysis
Compute stress, fatigue, flow and heat in CAE. The engine supplies loads and critical situations.
Certification still needs tests
Standards and approvals require physical tests and prescribed calculations. A prototype reduces their number and the risk of failing.
A model without a question, or instead of a calculation
“Let's build a model and see” ends in an expensive animation. Rated capacity or static stability is faster to calculate conventionally. Use a prototype for events over time, interplay with controls and the person at the machine.
Maintenance and versions
The engine, plugins and physics engines evolve. Plan updates and freeze versions for the duration of a project.
A digital model of a product that behaves like the real product: it has mass, drives, joints and controls.
Digital mock-up (DMU)
A static digital assembly of a product for checking shape, packaging and collisions.
Digital twin
A model of a specific existing machine or operation that is continuously synchronised with it through data.
SDPD
Simulation Driven Product Development.
Real-time engine
Software that computes and renders a 3D world fast enough for smooth interaction (e.g. Unreal Engine).
Physics engine
The software component that computes motion of bodies, constraints and contacts (Chaos, AGX Dynamics, MuJoCo).
Time step (Δt)
The length of one simulation step. Shorter step = more accurate and stable result, more computation.
Substepping
Splitting one rendered frame into several shorter physics steps.
Solver
The algorithm that finds body positions and velocities satisfying all constraints and contacts in each step.
Multibody dynamics (MBD)
Computing the motion of systems of bodies linked by constraints - the basis of machine simulation.
Constraint (joint)
A restriction of relative motion between two bodies - pin, slider, ball joint.
Collision shape
A simplified envelope of a part used by physics for collisions instead of the detailed mesh.
Virtual commissioning (VC)
Debugging the control program (PLC) against a virtual machine model before physical commissioning.
SIL / HIL
Software-in-the-loop / hardware-in-the-loop: control software or a real controller runs against a simulation.
OPC UA
An open industrial communication standard used to connect PLCs to a simulation.
ROS 2
Robot Operating System - open software and communication layer for robots.
FMI / FMU
A standard for exchanging simulation models; an FMU is a model packaged according to FMI.
Datasmith
Unreal Engine's toolset for importing CAD, BIM and 3D scenes.
Synthetic data
Automatically labelled images and measurements generated by simulation for AI training.
Domain randomization
Random variation of the environment (light, textures, layout) for more robust AI.
Sim-to-real gap
The difference between behaviour in simulation and in reality.
Verification and validation (V&V)
Checking that a model is computed correctly (verification) and matches reality (validation).
CAE
Computer Aided Engineering - engineering analysis such as FEM for strength and CFD for flow.
Generative design
Software proposes shape variants from given goals and constraints.
Sources
References and citation
Epic Games (2026). UE5 is becoming the platform of choice for robotics simulation. Unreal Engine Spotlight, 8. 4. 2026. https://www.unrealengine.com/spotlights/ue5-is-becoming-the-platform-of-choice-for-robotics-simulation
Epic Games (2024). Unreal Engine, Twinmotion and RealityCapture pricing update. Unreal Engine Blog.
Algoryx Simulation (2026). AGX Dynamics for Unreal - documentation. https://us.download.algoryx.se/AGXUnreal/documentation/current/
Dosovitskiy, A., Ros, G., Codevilla, F., López, A., Koltun, V. (2017). CARLA: An Open Urban Driving Simulator. Proceedings of the 1st Conference on Robot Learning (CoRL), 1-16.
Shah, S., Dey, D., Lovett, C., Kapoor, A. (2018). AirSim: High-Fidelity Visual and Physical Simulation for Autonomous Vehicles. In Field and Service Robotics, Springer, 621-635.
Todorov, E., Erez, T., Tassa, Y. (2012). MuJoCo: A physics engine for model-based control. IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 5026-5033.
Tobin, J., Fong, R., Ray, A., Schneider, J., Zaremba, W., Abbeel, P. (2017). Domain randomization for transferring deep neural networks from simulation to the real world. IEEE/RSJ IROS, 23-30.
Modelica Association (2022). Functional Mock-up Interface Specification 3.0. https://fmi-standard.org
VDI/VDE 3693 Blatt 1 (2016). Virtuelle Inbetriebnahme - Modellarten und Glossar. Verein Deutscher Ingenieure.
ISO 23247-1:2021. Automation systems and integration - Digital twin framework for manufacturing - Part 1: Overview and general principles. ISO.
NASA (2016). NASA-STD-7009A: Standard for Models and Simulations. National Aeronautics and Space Administration.
Sargent, R. G. (2013). Verification and validation of simulation models. Journal of Simulation, 7(1), 12-24.
Grieves, M. (2014). Digital Twin: Manufacturing Excellence through Virtual Factory Replication. White paper.
How to cite this publication (APA 7)Nepor, V. (2026, October 5). Virtual prototyping: a practical guide. Vrealmatic. https://vrealmatic.com/publications/virtual-prototyping
Share
Have a machine you want to verify before you build it?
Send us a description or a CAD model. We will suggest what to test in a virtual prototype, which data you will need and what to expect.
