Technical Notes · Pre-visualisation and Production Technology

Pre-visualisation for Live Production: Where the Virtual and Real Worlds Meet

Ross Williams · Jul 10, 2026 · 24 min read

Pre-visualisation, usually shortened to pre-vis, has become one of the most valuable preparation tools available to lighting programmers, lighting designers and production teams.

At its simplest, pre-vis allows us to build a production in a virtual environment, connect a real lighting console and begin programming before the physical equipment has been installed. On a large television show, concert, ceremony or special event, that can save days of valuable studio or venue time.

That simple description, however, understates what is really happening.

Modern pre-vis sits at the intersection of CAD, real-time rendering, lighting control, media servers, camera planning, automation, tracking and show control. The visualiser is not merely producing an attractive three-dimensional picture. It is attempting to maintain a continuously updated digital version of a production in which thousands of parameters may be changing every second.

When it works well, the virtual production responds to the lighting desk, media playback and other control systems in much the same way as the real show eventually will.

The important qualification is when it works well.

A visualiser can only represent the information it has been given. However sophisticated the rendering engine may be, the result is only as useful as the attention paid to the technical drawing, fixture data, patch, positioning and real-world installation.

What a visualiser is actually doing

A professional lighting visualiser is effectively a specialised real-time graphics engine.

There are obvious similarities with a video game engine. Both systems contain three-dimensional models, cameras, materials, textures, lights, animation and a rendering pipeline. Both must calculate an image quickly enough for movement to appear fluid.

The important difference is the nature of the control.

A conventional game responds primarily to players, scripted events and internal simulation. A production visualiser is expected to respond deterministically to external control data. When a programmer sends a pan value, changes a gobo, opens a shutter or runs a timecoded cue, the corresponding virtual fixture must respond correctly and repeatably.

The same cue should produce the same result each time. The virtual system therefore needs to understand much more than the appearance of a fixture. It must understand its control personality, movement limits, optical system, colour system and operating mode.

The CAD model: the foundation of the virtual production

Everything begins with the drawing.

The venue, studio or site must be represented at the correct scale. The model may include walls, floors, ceilings, seating, stages, scenic structures, trusses, lighting positions, LED screens, projection surfaces, camera tracks and automated scenery.

On a straightforward production, the model may only need to answer a few questions:

• Where are the lighting positions?
• Where are the scenic surfaces?
• What can the audience and cameras see?
• Where will the beams land?

On a complex production, it may need to represent almost everything that moves or affects a shot.

That can include lifts, revolves, tracked screens, flown scenic pieces, performer entrances, camera cranes, rail cameras, Steadicam routes, pyrotechnic positions and temporary structures. Camera sensor formats, lens choices and approximate focal lengths may also be included so that wide shots and restricted sightlines can be evaluated before rehearsals.

For my own drawing and data-exchange workflows, I generally use Vectorworks Spotlight before moving the production into systems such as Depence or WYSIWYG. As discussed in Tools for the Lighting Programmer, formats including GDTF and MVR can reduce the amount of information that has to be recreated manually.

GDTF describes the device: its geometry, control channels, DMX modes, wheels, emitters and other physical or behavioural information. MVR carries information about the wider production scene, including fixture locations, orientation, patch and geometry. The intention is to let CAD packages, consoles and visualisers share a more consistent understanding of the same production.

These formats are an enormous improvement, but they do not eliminate the need for checking. A neatly imported file is not necessarily a correct file.

Fixtures as digital twins

Every lighting fixture in the virtual production is intended to act as a digital twin of a real device.

A basic model might contain the fixture’s dimensions, pan and tilt movement, beam angle and colour. A more detailed model may also contain:

• Multiple DMX operating modes
• Zoom limits and focus behaviour
• Colour wheels and colour-mixing systems
• Gobo wheels, indexing and rotation
• Framing shutters
• Prism, frost and iris behaviour
• Movement speed and acceleration
• Dimmer curves
• Individual LED emitters or pixel cells
• Physical lens and body geometry

The correct operating mode is particularly important. A fixture may have several personalities with different channel counts and different arrangements of functions. Choosing the wrong mode can produce a virtual light that appears broadly correct but does not respond in the same way as the physical fixture.

This becomes more complicated when different firmware versions contain modified modes, channel functions or calibration behaviour. The console, visualiser, paperwork and fixture all need to agree on what that mode actually means.

A digital fixture may also contain photometric information intended to approximate the physical output. This may describe the shape of the beam, its fall-off, colour characteristics and relative intensity.

Even with good manufacturer data, it remains an approximation.

A new digital model represents something close to an ideal fixture. A real production may be using equipment with different lamp hours, LED calibration, lens cleanliness, mechanical wear or previous maintenance histories. Two supposedly identical physical fixtures may not produce identical colour or intensity.

The rendering engine

Once the environment and fixtures have been defined, the rendering engine has to calculate the resulting image.

It must determine where the beams travel, what they strike, how surfaces respond and what the virtual cameras can see. Materials may be configured to resemble gloss paint, black cloth, metal, timber, glass, water, LED surfaces or projection screens.

Atmospheric rendering is especially important in entertainment lighting. Without haze, many lighting beams are almost invisible until they strike a surface. The visualiser therefore has to simulate the scattering of light through an atmosphere while continuing to render the scene interactively.

This is computationally expensive.

Every volumetric beam, shadow, reflection, piece of video and transparent surface adds processing work. A complex show may contain thousands of fixtures, multiple video surfaces, animated scenery, particles, camera moves and effects. The machine must process all of this while also receiving constantly changing control data.

The goal is not necessarily to perform a perfect offline calculation of every light ray. The goal is to produce a sufficiently convincing result quickly enough for the designer and programmer to make useful decisions.

The bridge between the console and the model

The real value of a production visualiser appears when it is connected to the lighting console.

DMX512 remains the underlying control language for much of stage lighting. It carries channel values that tell fixtures what to do. In a visualisation environment, the software receives those values and applies them to the appropriate virtual devices.

RDM is related but performs a different job. Rather than being the primary stream of show levels, it provides bidirectional management and feedback. It can be used for functions such as device discovery, addressing, configuration and status information.

On a modern production, individual DMX cables are rarely run all the way from a large console system to every visualisation computer. Art-Net and sACN carry multiple universes of DMX-style control data over an Ethernet network. A desk sends packets across the network; the visualiser receives them, translates the values and updates the virtual fixtures.

When the configuration is correct, moving a fader or running a cue on the real desk produces an almost immediate response in the virtual rig.

“Almost” is important.

There is always some processing time, even when it is imperceptible. Data must leave the desk, travel across the network, be received by the visualiser, applied to the virtual fixtures and rendered into the next frame.

With a modest system this feels immediate. With thousands of parameters, high-resolution video, tracking streams and complex rendering, delays can become more noticeable. Network design, universe management, multicast configuration, frame rate and processing load all matter.

Media servers and video surfaces

Lighting is now only one part of many visual productions.

LED screens, projection surfaces, mapped scenic objects and embedded video elements frequently occupy a large proportion of the audience’s view. A useful pre-vis model therefore needs to show how the content works within the overall lighting and scenic design.

Depending on the system, video may be imported directly, captured from an external source or shared through a media-server workflow. Protocols and technologies such as CITP, NDI, Spout, video capture and proprietary integrations may be involved.

CITP is often useful for exchanging media information, thumbnails and related control data. It should not automatically be thought of as a universal method for carrying every full-resolution production feed. The precise workflow depends on the media server, visualiser and hardware being used.

This continuing convergence between lighting and video is an extension of the media-server workflows discussed in The Media Server. A media server may receive DMX, Art-Net, MIDI, OSC or timecode and then manipulate video in real time as part of the production. The distinction between a lighting cue and a video cue is consequently much less rigid than it once was.

More than lighting: modelling the whole production

The term “lighting visualiser” can now feel rather narrow.

Modern pre-vis environments may contain lighting, video, projection, lasers, fountains, flame effects, fireworks and other special effects. These elements can be represented inside a common real-time environment rather than being treated as unrelated systems.

LED audience wristbands can be represented as large pixel-mapped arrays. A stadium or arena audience can be turned into a virtual canvas, allowing waves, blocks of colour, chases and image-based effects to be considered alongside the stage lighting.

As always, the quality of that simulation depends on the detail of the model. It needs to account for the distribution of the wristbands, seating geometry, viewing angle, output level and the way the effect will be photographed.

Lasers introduce their own requirements. Scanner speed, projection geometry, divergence, atmosphere and safety zones all affect the real result. A virtual laser can be a useful creative and planning aid, but it does not replace the calculations, safety procedures and qualified personnel required for the physical system.

Fountains and water effects add fluid behaviour, wind, gravity, nozzle characteristics, pump response and illumination. Pyrotechnics introduce timing, spread, smoke, residue, exclusion areas and strict safety controls. The pre-vis may help communicate the intended sequence, but it cannot remove physical uncertainty or regulatory responsibility.

Any visual is only as accurate as the drawing

It is tempting to judge a pre-vis system by the beauty of its renders.

That is not the most important test.

The real test is whether the virtual production accurately represents the production that is going to be installed.

A beautifully rendered model with incorrect coordinates is still incorrect. A lower-quality render built from accurate information may be far more useful to the programmer.

Small drawing errors can create substantial programming errors. A truss that is shown half a metre too high changes beam intersections and focus positions. An LED screen with the wrong dimensions changes content framing and reflections. A camera platform in the wrong place gives everyone a false impression of the shot.

Fixture orientation is one of the most common problems.

A moving light hung with its display facing the opposite direction may have its pan direction effectively reversed relative to the visualiser. A linear fixture rotated through 180 degrees may map its pixels in the opposite order. A fixture placed on the wrong side of a truss chord may have a different physical range or may be masked by another object.

In the virtual model, everything can appear perfectly organised. On site, the programmer discovers that half the rig moves in the opposite direction or that symmetrical effects no longer appear symmetrical.

The result is unnecessary work realigning the virtual and physical worlds.

Fixture modes, patch and addressing

A similar problem occurs when fixtures are installed in the wrong mode.

Imagine that the drawing, visualiser and console have all been prepared for a fixture in an extended mode. The physical unit has been set to a smaller basic mode. Every parameter after the point of difference may be incorrect.

Alternatively, the real fixture may be in the correct mode but have a different firmware version, channel order or personality implementation.

Incorrect addresses and universe assignments create another layer of confusion. A visualiser may appear to be responding correctly because the virtual patch is internally consistent, while the real network has been wired or configured differently.

The production then reaches the point at which several versions of the truth exist:

• The drawing says one thing.
• The console says another.
• The visualiser says something else.
• The fixture itself is doing something different again.

Resolving these differences during a pressured rehearsal is far more expensive than checking them during preparation.

Position and orientation must survive installation

The physical installation must follow the drawing closely enough for the pre-programmed information to remain useful.

That does not mean every measurement will be millimetre-perfect. Temporary structures flex, trusses move under load, venue drawings contain tolerances and scenic elements change. The production needs an agreed level of accuracy appropriate to the scale of the show.

What matters is that deviations are identified and communicated.

When a lighting position moves, the virtual model should be updated or the console data corrected. When a fixture is substituted, its profile and physical characteristics need checking. When a screen changes size, the video and camera departments need to know.

Undocumented changes are the real problem.

A fixture that has moved but remains in its original virtual location creates a false relationship between the desk and the stage. Every focus created in pre-vis is now based on outdated geometry.

A production can quickly waste hours attempting to correct programming when the underlying problem is that the model and the installation no longer describe the same thing.

The human role: maintaining the digital production

On a sufficiently complex project, maintaining the visualisation model is effectively a full-time job.

Someone has to receive the latest drawings, import changes, clean geometry, resolve coordinates, assign materials, update fixture types, check modes, confirm patch information and manage model versions.

They may also need to incorporate:

• Video content
• Camera positions and movements
• Lens choices and focal lengths
• Performer blocking
• Automated scenery
• Stage lifts and revolves
• Laser positions
• Pyrotechnic cues
• Water effects
• Audience wristbands
• Tracking objects
• Projection surfaces
• Changes to the venue or scenic design

The work can consume many hours before a single lighting cue is programmed.

This does not mean the process is inefficient. The time is being moved from a highly pressurised venue or studio environment into a more controllable preparation period. If thirty or forty hours of careful drawing and modelling save two days on site, that can be an excellent exchange.

The saving is only achieved when the information is sufficiently accurate and the resulting show file is carried successfully into the production.

Pre-vis as a programming environment

For the lighting programmer, the objective is not simply to make a presentation film.

The most valuable output is usually the show file.

Before arriving on site, I may be able to prepare:

• Fixture types and operating modes
• Patch and universe structure
• Console layouts
• Selection grids and groups
• Position, colour and beam palettes
• Basic focuses
• Timecode structure
• Effects
• Cue lists
• Song programming
• Repeated production looks

This is consistent with the wider role of the programmer described in The Moving Light Programmer. The job is not limited to pressing buttons. It can include drawing, networking, documentation, media-server integration, control infrastructure and the organisation of information across departments.

A successful pre-vis session means that the first day with the physical rig is spent correcting and refining rather than constructing the entire show file from nothing.

That distinction can save an enormous amount of time.

The gap between the virtual and physical worlds

No visualiser reproduces the real world perfectly.

The most obvious difference is atmosphere.

In software, haze is normally controlled through a set of defined parameters. Density can be increased or decreased and may remain relatively uniform throughout the virtual venue.

Real haze does not behave like that.

Air-conditioning systems, doors, stage fans, thermal currents, roof spaces and audience movement all affect its distribution. One side of a venue may have a dense atmosphere while the other is almost clear. A low-level effect may rise, drift or disappear.

A look created around a perfectly even virtual atmosphere may therefore feel quite different on site.

Surface materials also vary. A scenic wall that appears matt in the model may arrive with a slight sheen. Black flooring may reflect more light than expected. A video surface may illuminate nearby people and scenery differently from the approximation used during preparation.

The same applies to fixture output. Real units differ, lenses become dirty and colour calibration varies. Shutters may not align perfectly. Gobos may focus differently. A physical beam can contain optical artefacts that were not included in the model.

Pre-vis gets us close. It does not eliminate the need to look at the stage.

Human vision and camera vision

The difference becomes even more significant in television and filmed production.

The human eye and a camera do not perceive light in the same way.

A lighting look may feel balanced when viewed from the studio floor but appear too contrasty, flat or saturated through the camera chain. Exposure, sensor response, lens transmission, filtration, white balance, picture profile, colour processing and display monitoring all influence the final image.

LED products introduce further complications. Colours that look acceptable to the eye may reproduce poorly on camera. Very saturated sources may exceed the colour range that the camera or display pipeline handles gracefully. Refresh rates, dimming methods and shutter settings can create flicker or banding that a general-purpose visualiser may not predict.

This is one reason that a virtual render should not be treated as a colour-critical promise.

The render can communicate direction, balance, texture, timing and scale. It cannot guarantee that the physical production will look identical after passing through real fixtures, lenses, sensors, vision control, grading and domestic displays.

Knowing when to leave the virtual world

I use these systems regularly and consider them extremely valuable. There is, however, a point in the rehearsal process when attention has to move decisively into the real world.

Once the rig is installed, powered, focused and being viewed through the production cameras, the physical show becomes the authority.

At that stage, the question is no longer whether the real stage matches an idealised render. The question is whether the real stage works for the production.

Lighting levels may have been reduced for camera exposure. Colours may have been altered because of skin tone, costume, scenery or video content. Beam positions may have changed to avoid cameras, reflective surfaces or performer sightlines.

The result may now be technically and artistically correct even though it has departed from the pre-vis.

Continuing to update the virtual model after every real-world adjustment can become counterproductive. Time that should be spent looking at monitors, responding to the designer and improving the show is instead spent maintaining a second version of reality.

This is also the point at which requests for endless renders and updated movies need to be managed carefully.

During early design development, those outputs can be very useful. They help producers, directors, artists and clients understand an idea before equipment exists.

During rehearsals, the actual production is now visible. A new render may be less accurate than a recording from the studio or venue because the real-world exposure, colour, haze and camera treatment have already moved beyond the assumptions used in the model.

The visualiser has completed its main task. It has helped get the production to the stage.

Renders are communication tools, not contracts

A pre-vis film often becomes more polished than originally intended.

A camera move is added. Then video content. Then performers. Then animated scenery. Atmospheric effects are adjusted, materials are improved and the lighting is modified to make the render read clearly.

Eventually, the production may begin treating the film as a promise of exactly how the show will look.

That is dangerous.

A render intended to illustrate a concept may use stronger beams, denser haze or brighter surfaces to communicate clearly on a laptop or in a meeting room. Those settings may not be appropriate for the real production.

The purpose of the output should therefore be agreed:

• Is it a technical programming reference?
• A director’s planning tool?
• A client concept film?
• A camera-planning exercise?
• A marketing-quality animation?
• A timing reference for multiple departments?

These are not the same deliverable.

A highly polished presentation film may require substantially more work than a functional programming model. That work should be recognised, scheduled and resourced rather than treated as an automatic by-product of the lighting programmer’s preparation.

Unreal Engine enters live-production pre-vis

Unreal Engine is increasingly relevant to this area because it combines real-time rendering, cinematic cameras, animation, sequencing, scripting and external control in one environment.

Unreal can receive control from a lighting desk, interpret DMX data and, in some workflows, generate DMX output itself. Its Sequencer environment can record, edit and replay control data alongside camera moves, scenic animation and other timeline events.

This does not mean Unreal Engine automatically replaces established visualisers.

Dedicated lighting packages already understand many production concepts directly. They include fixture libraries, patching tools, paperwork, focus workflows and established connections to consoles. Unreal is a broader development platform and can require more work to build equivalent production-specific tools.

Its advantage is flexibility.

A production can combine lighting, scenic animation, characters, cameras, video, effects and cinematic presentation inside a highly customisable environment. The same scene can be used for interactive review, high-quality renders, camera studies, virtual production and real-time control.

This makes Unreal particularly interesting where traditional lighting visualisation begins to overlap with broadcast design, content production and virtual production.

Timeline workflows with CuePilot and LiveEdit

Another important development is the movement of pre-vis material into collaborative show-planning timelines.

CuePilot is built around projects, rundowns, acts and timelines. It allows production cues and camera ideas to be plotted before the show and can communicate with switchers, media servers, effects and other systems through several control methods.

LiveEdit similarly provides shared timelines for media, shots, lighting cues, playback, notes and timecoded feedback. It can become a common place for the production team to review how departments fit together.

The significant change is not simply that these systems can display a movie file.

It is that a simulated production can be placed into the same timing context as the wider show.

A lighting render can be aligned with music, camera cuts, choreography, lyrics, automation and video content. Producers and directors can review the overall concept before the stage has been built. Departments can discuss the same moment using a shared timeline rather than relying on separate cue sheets and differently numbered notes.

In an Unreal-based workflow, simulated cameras and lighting may be rendered from the virtual production and inserted into CuePilot, LiveEdit or a similar platform. As the concept develops, updated sequences can replace earlier versions.

The timeline then becomes a common communication layer between the virtual design and the eventual live execution.

This should not be confused with a guarantee that every platform has a direct, automatic or formally partnered connection to every other one. In many cases, the workflow is assembled through exported renders, timecode, OSC, media exchange or custom integration.

What matters is that the visualisation is no longer isolated on one operator’s computer. It becomes part of the production’s shared planning language.

Cameras, lenses and virtual shot planning

Unreal Engine and other advanced real-time tools also make camera planning more sophisticated.

A virtual camera can be assigned a sensor format, lens and focal length. It can be placed on an approximate pedestal, crane, rail or handheld path. Directors can explore how the production reads from different viewpoints before the studio is available.

This is valuable for lighting because a look does not exist independently of the camera.

A beam that looks impressive from the front may disappear from a side angle. A scenic element may mask a fixture in a wide shot. A camera may travel directly through a lighting position or reveal equipment that the design assumed would remain hidden.

Adding virtual cameras helps expose these issues earlier.

It also increases the workload. Camera positions, platform heights, lens information and movement paths must be maintained as the production develops. An inaccurate virtual lens can be just as misleading as an inaccurate fixture position.

Tracking and responsive productions

Real-time tracking adds another connection between virtual and physical space.

Systems such as BlackTrax use camera arrays and infrared markers to track performers or objects. That positional data can be sent to robotic lights, media servers, projection systems, cameras and spatial-audio systems.

A performer’s position can therefore exist simultaneously in several systems.

Lighting may follow the performer. Video content may react to them. Projection may remain mapped onto a moving scenic object. A virtual model may show the same tracked object in real time.

This changes pre-vis from a rehearsal of fixed cues into a rehearsal of responsive behaviour.

The creative possibilities are substantial, but so are the calibration requirements. Every system must agree on origin, scale, axes and orientation. A tracking position is only useful when every receiving device interprets the coordinates correctly.

Once again, the quality of the result depends on the accuracy of the shared world.

Augmented and mixed-reality review

The next stage is likely to involve more augmented and mixed-reality review.

Instead of looking only at a monitor, designers may inspect virtual production elements in relation to the physical venue. An empty stage could be viewed with a proposed scenic structure, lighting rig or screen configuration overlaid in position.

This has obvious potential for evaluating scale, access, sightlines and spatial relationships.

It will not remove the need for drawings or traditional visualisation. An augmented view still depends on the same underlying model and coordinate system. If the virtual truss is in the wrong position, it will simply be displayed in the wrong position more convincingly.

The technology changes the way we view the information. It does not remove the need for accurate information.

A practical accuracy hierarchy

When building and using a production model, it is helpful to prioritise accuracy in roughly this order:

1. Coordinate system and scale

The venue, stage and rig must share the same origin, scale and orientation.

2. Fixture identity and mode

The model, console and physical fixture must agree on the fixture type, operating mode and relevant firmware behaviour.

3. Patch and addressing

Universe, address, fixture number and control data must match across the drawing, console, network and real device.

4. Position and orientation

Fixtures must be hung where the model expects them to be and facing the correct direction.

5. Scenic and video geometry

Screens, masking, floors and scenic objects must have sufficiently accurate dimensions and positions.

6. Movement and timing

Automation speeds, camera moves, fixture movements and effects need realistic timing.

7. Materials, atmosphere and presentation quality

Once the underlying production data is reliable, visual materials and render quality can be improved.

It is very easy to reverse this order and spend time making the render beautiful while the technical data remains uncertain.

The correct measure of success

The success of pre-vis should not be judged solely by how closely a final production photograph resembles an early render.

A successful workflow may have:

• Identified drawing errors before installation
• Reduced onsite programming time
• Allowed fixture modes and patch to be checked
• Provided a useful starting show file
• Exposed camera or sightline problems
• Improved communication between departments
• Helped a client understand the overall concept
• Allowed difficult sequences to be rehearsed safely
• Reduced the number of expensive changes required on site

The final show may look different because it has improved through rehearsal.

That is not a failure of pre-vis. It is the normal development of a production.

Conclusion

Pre-visualisation is one of the most powerful tools available to modern production teams, but it is not automatic and it is not free.

A detailed model may take many hours to build and maintain. Complex productions require someone to coordinate drawings, fixture data, video content, cameras, automation, performers and special effects. The work can become a full-time responsibility.

When that work is done accurately, it can save days on site.

The programmer arrives with a structured show file. The designer can explore ideas before the rig exists. Directors and producers can review timing, cameras and overall concepts. Problems can be found while they are still inexpensive to correct.

The visualiser must nevertheless remain a tool rather than becoming the production itself.

Its value depends on the accuracy of the drawing, the quality of the data and the discipline of the physical installation. Lights hung backwards, fixtures set to the wrong modes or equipment installed in different positions all create unnecessary work reconnecting the virtual and real worlds.

Then, once the real rig is available, we have to know when to look away from the computer.

At that point, real fixtures, real cameras, real performers and real human vision become the final authority. The purpose of pre-vis was to help us reach that moment with more time, better information and fewer surprises.

It was never intended to stop us looking at the stage.

Related technical notes

• Tools for the Lighting Programmer
• The Media Server
• The Moving Light Programmer

See all technical notes