Client Performance

Posted05/09/2026

Updated05/09/2026

ByMrDino

Most of the visual workload created by Theatrical: Realistic Pack (TRP) is rendered on the client.

This means two players connected to the same server can experience very different FPS even when they are looking at exactly the same lighting rig.

Client performance is primarily affected by:

Fixture model complexity
Number of visible fixtures
Volumetric beams
Beam distance
Beam occlusion
Surface projections
Gobos
Pixel fixtures
Disco-ball reflections
Minecraft render distance
Screen resolution
External shader packs
Other installed mods

The server can synchronise the same fixture state to every player, but each client is responsible for rendering that state using its own hardware and graphics configuration.

Client Rendering

TRP separates the physical fixture model from its optical effects.

This allows different performance controls to be applied to:

Fixture bodies
Volumetric beams
Surface projections
Impact lights

A distant fixture may therefore use a simplified model while its beam remains visible.

This separation is particularly useful in large venues where the physical fixture body may be far away but its lighting effect still needs to remain visible.

Model Quality

Available settings:

Performance
Balanced
Quality

Default: Balanced

Model Quality controls the detail used when rendering fixture bodies.

Performance

Recommended when:

Many fixtures are visible
FPS is more important than model detail
Running on lower-end hardware
Operating very large productions

Balanced

Recommended for most users.

Provides a compromise between model quality and rendering cost.

Quality

Recommended for:

Screenshots
Video recording
Showcase environments
High-end hardware
Smaller fixture counts

Detailed Model Distance

Range: 1–32 chunks
Default: 9 chunks

At the default setting, detailed models are used up to approximately:

144 blocks

from the player.

Reducing this value is one of the most useful optimisations when many fixtures are visible across a large stage.

For example:

Performance-Oriented

4–6 chunks

Balanced

9 chunks

Showcase

12–20 chunks

The optical beam can remain visible even after the fixture body moves into a lower-detail rendering state.

Volumetric Beams

Volumetric beams can be one of the most visually important and demanding parts of TRP.

Their cost depends on:

Number of active beams
Beam distance
Segment count
Occlusion mode
World geometry
Number of projections

The default volumetric beam segment count is:

with a configurable range of:

8–48

TRP can also adaptively reduce segmentation when appropriate.

If beams are significantly affecting FPS, reduce:

Beam Reach
Beam Segments
Active beam count

before disabling the system entirely.

Beam Occlusion

TRP provides:

Legacy
Realistic

occlusion modes.

Legacy

Uses a less expensive collision approach.

Recommended for:

Large shows
Lower-end clients
High fixture counts

Realistic

Samples world geometry more thoroughly.

It can consider:

Faces
Corners
Floors
Walls
Undersides

This can produce stronger world interaction but requires additional processing.

For clients struggling with FPS, switching:

Realistic → Legacy

is one of the first settings to try.

Maximum Beam Reach

Range: 0–512 blocks
Default: 96 blocks

Longer beam distances can increase the amount of world geometry TRP needs to evaluate.

For indoor venues, values around:

32–64 blocks

may often be sufficient.

For larger stages:

64–96 blocks

is a reasonable starting point.

Use very long beam ranges only when the production actually requires them.

A value of:

disables physical beam and projection rendering.

Projections

TRP can project fixture output onto Minecraft world geometry.

This includes:

Coloured projections
Gobos
Rotating gobos
Indexed gobos
Gobo shake
Focus-dependent blur

The renderer includes five precomputed blur levels for projected gobo textures.

Large quantities of simultaneously projected gobos can therefore create more client workload than simple open beams.

Projection Steps

Range: 8–128
Default: 48

Higher values provide more detailed projection sampling but increase processing cost.

For lower-end clients, values such as:

may be useful.

For high-quality showcase rendering, higher values can be used if the client has enough performance available.

Pixel Fixtures

Pixel fixtures can create significantly more visual activity than simple fixtures.

Examples include:

Spiider
Arianne 6
LEDBeam 150
TetraX
Tetra2
WTF!

Several of these fixtures contain many individually represented sources.

For example:

Tetra2

18 RGBW pixels
2 flower sections

TetraX

9 RGBW pixels
3 flower sections

WTF!

2 RGBW zones
16 RGBW pixels
12 white pixels

A large quantity of actively changing pixel fixtures can therefore be much more demanding than the same number of conventional fixtures.

Disco Ball Reflections

TRP disco balls react to actual active fixture beams.

Reflection calculations consider:

Beam colour
Beam intensity
Ball rotation
Ray intersections
World geometry

The workload is adaptively budgeted by TRP, and the internal active source-beam registry is capped at:

256 entries.

Multiple disco balls receiving many simultaneous beams can still increase client rendering cost.

External Shader Packs

TRP uses its own integrated shader systems.

Third-party shaders are optional and compatibility is not guaranteed.

They can increase GPU workload significantly when combined with:

Volumetric beams
Projections
Pixel fixtures
High render distances
High resolutions

If performance is unexpectedly poor, test the same scene with the external shader disabled.

Minecraft Render Distance

Minecraft Render Distance affects how much world geometry the client must render independently of TRP.

A very high render distance combined with:

Large stages
Many fixture bodies
TRP beams
Projections
Other mods

can place substantial load on both CPU and GPU.

Reducing render distance can therefore improve performance even without changing TRP settings.

Screen Resolution

Higher display resolutions increase GPU workload.

The recommended TRP hardware guidelines are primarily based around:

1920 × 1080

Running at:

1440p
Ultrawide resolutions
4K

may require significantly stronger graphics hardware for the same fixture and beam configuration.

Different Players Can Use Different Visual Settings

Because much of TRP’s visual work happens on the client, players do not necessarily need identical graphics quality.

For example:

Lighting Operator

Could use:

Performance models
Legacy occlusion
Shorter beam range

to prioritise stable control and FPS.

Camera Operator

Could use:

Quality models
Realistic occlusion
Longer beam reach

to prioritise visual quality.

Both can still connect to and observe the same server-side lighting state.

Diagnostic Rendering

TRP provides independent diagnostic switches for:

Physical Fixture Models
Volumetric Beams
Projections
Impact Lights

These are useful when determining which visual system is responsible for a performance problem.

Disable Physical Models

If FPS improves significantly:

Reduce Model Quality
Reduce Detailed Model Distance

Disable Beams

If FPS improves significantly:

Reduce Beam Reach
Reduce Beam Segments
Use Legacy Occlusion
Reduce simultaneous active beams

Disable Projections

If FPS improves significantly:

Reduce Projection Steps
Reduce active gobos
Reduce Beam Reach

Disable Impact Lights

If FPS improves significantly, the impact-light system is contributing noticeably to the scene cost.

Performance Profiling

TRP includes optional renderer profiling.

When enabled, accumulated renderer information can be reported approximately every:

120 rendered frames

This is useful for:

Diagnosing performance problems
Comparing graphics settings
Preparing bug reports
Testing large scenes

Profiling normally does not need to remain enabled during regular gameplay.

Renderer Recovery

TRP includes a recovery guard for expensive beam rendering.

If an exception occurs during beam rendering, TRP can temporarily suspend that work rather than repeatedly failing every frame.

The default recovery cooldown is:

200 ticks

or approximately:

10 seconds.

This is designed as a stability mechanism rather than a normal performance optimisation.