Building an In-World Manual or Kiosk with PDF Pages in UE5

The problem: real documents, inside the world

You have a PDF that already exists. It might be the printed manual for an in-game machine, a lore book your writers laid out in InDesign, an archviz brochure with floor plans, or a museum exhibit panel. You want the player to walk up to a surface in the level and page through that exact document, not a screenshot of it baked into a texture and not a re-typed UMG approximation that drifts out of date the moment the source changes.

This is the classic Unreal Engine interactive document kiosk in game problem, and it is awkward to solve by hand. The engine has no native PDF support, so the usual workarounds are to export every page to PNG and juggle a texture array, or to embed a web browser widget and fight its layout. Simple PDF Viewer takes the document directly: it rasterises each PDF page to a UTexture2D using the bundled PDFium library and shows that texture on an in-world mesh, so what the player reads is the real page, paged with real navigation.

This guide walks through the three things that make an in-world manual or kiosk actually usable: sizing the display correctly in world units, making it readable from any angle, and driving multiple viewers from a single controller so a bank of screens stays in sync. Everything here is grounded in the plugin's actual Blueprint API.

When this is the right tool

Simple PDF Viewer is built for exactly the cases where the source of truth is a PDF and you want it shown faithfully. The plugin's own listed use cases cover in-world manuals, lore books and readable documents on a mesh such as an open book or wall poster; interactive kiosk, museum or archviz exhibits where the player pages through brochures or plans; tutorial and onboarding screens that show a real PDF navigated with Next and Previous; multi-page PDFs used as a slideshow surface driven by scroll progress; and certificates, handbooks or spec sheets shown on monitors in a sim.

Be clear about what it is not, because that shapes your design. Pages are rasterised to image textures, so the result is a faithful picture of each page, not a text-selectable or interactive document. There is no text extraction, form filling, or hyperlink navigation in the public Blueprint API, so do not design a UI that assumes the player can click a link inside the page or copy text out of it. The plugin is Windows only, with PDFium bundled for Win64, so plan around a Windows target rather than promising Mac, Linux, mobile or console.

If those constraints fit, the payoff is that the document drops straight into the world. You set a file path, drag in an actor, and the page renders. The rest of this article is about making that render look deliberate rather than accidental.

Sizing the display in world units

The fastest path to a working kiosk is the drop-in actor. Drag an APDFViewerActor (it shows up as 'PDF Viewer') into your level. It builds its own display mesh and a dynamic material for you, so there is nothing to author up front.

1. Select the actor and set its PDF File Path. You can use an absolute path, or use the plugin's content-relative and project-relative path helpers from the Blueprint library so the path travels with your project rather than your machine.

2. Set 'Display Width' to the physical size you want the document to occupy. This is a real world-unit measurement clamped between 10 and 1000, so for a wall-mounted information panel you might use 150 to 300, and for an open lore book on a lectern something much smaller.

3. Leave 'Auto Adjust Orientation' enabled. The actor reads the loaded page's dimensions and orients the display mesh from the page aspect ratio, so a portrait A4 manual and a landscape brochure both come out the right shape without you measuring anything. You can query the geometry yourself with 'Get Current Page Size' (reported in points), 'Get Current Page Aspect Ratio' (width over height, and 1.0 when no PDF is loaded), and 'Is Current Page Landscape' if you need to drive other actors from the page shape.

4. Set 'Render Quality' to control how sharp the rasterised page is. This is the resolution the page is rendered at on the actor, clamped between 256 and 4096. Higher values give crisper small text but cost more texture memory, so match it to how close the player will physically get. The render resolution is capped at 4096, so do not plan a design that needs the page sharper than that at extreme zoom.

On play the actor auto-loads (both 'Auto Load' and 'Load On Start' are on by default), so a correctly configured viewer simply shows page one when the level begins. Inspect the included L_Demo level for a working reference setup before you build your own.

Making it readable: double-sided and emissive

A document panel in a 3D space has two readability problems a printed page never has: the player can end up behind it, and your level lighting may leave the page in shadow. Simple PDF Viewer exposes two controls aimed squarely at this.

Enable the double-sided toggle on the viewer so the page renders on both faces of the mesh. This matters for free-standing kiosks and hanging signage where the player can circle around the display, and for any case where you cannot guarantee which side they approach from. With it off, a player who walks behind the panel sees nothing.

Use 'Emissive Strength' to make the page legible regardless of scene lighting. The value is clamped between 0 and 10. At 0 the page is lit purely by your level lights, which can look natural for a paper book sitting on a desk but can also leave a wall panel too dark to read. Pushing emissive strength up makes the page glow as if it were a backlit screen, which is exactly what you want for a monitor, an information terminal, or a kiosk in a dim museum hall. Dial it to taste: enough that the page reads cleanly from the player's normal standing distance, not so much that it blows out and loses contrast in the text.

Together these two settings turn a flat textured quad into something that reads as an intentional in-world display from any approach angle and under any lighting.

Driving multiple viewers from one controller

Kiosks rarely come alone. A museum wing might have a row of identical panels; an archviz lobby might show the same brochure on several screens; a tutorial room might mirror one manual across multiple stations. Re-implementing navigation per actor is how those screens drift out of sync. The plugin's Blueprint function library is built for level-wide control instead.

Call 'Get All PDF Viewers' to collect every APDFViewerActor currently in the level into an array, with no manual references to wire up. From a single controller, hub terminal, or input action you can then call 'Navigate All Viewers To Page' to move every viewer to the same page at once. A 'next' button on one master kiosk advances the whole bank; a chapter selector jumps every panel to the same spread. Because the controller talks to the library rather than to individual actors, adding or removing a panel from the level needs no rewiring.

When you do want a single surface under fine control, drive that one actor directly. The full page-navigation API is 'Go To Page', 'Next Page', 'Previous Page', 'Go To First Page', 'Go To Last Page', 'Get Current Page' and 'Get Page Count'. Bind the events 'On PDF Loaded' (which gives you the page count), 'On Page Changed' (new page and total), and 'On PDF Load Failed' (an error message) so your UI can show 'Page 3 of 12', disable the next button on the last page, and surface a clean error if a file is missing rather than silently showing nothing.

For a slideshow-style surface, use 'Scroll To Progress' and 'Get Scroll Progress' to move through the document by a 0-to-1 value, which pairs naturally with a slider or an automated timeline.

Beyond the drop-in actor: custom surfaces and materials

When the built-in actor's display mesh is not the surface you want, reach for the component. Add a UPDFRenderComponent (it appears as 'PDF Renderer') to any actor of your own, then call 'Load PDF' with a file path and an optional password. Encrypted PDFs are supported through that optional password parameter on load, which is useful for documents you do not want extracted from a shipped build trivially.

From there you drive the same navigation calls and bind the same load and page-changed events as the actor. To show the page on your own geometry, read the current page texture and push it into a material that has a Texture parameter named exactly 'PageTexture', then apply it with 'Set Dynamic Material'. The naming matters: the integration expects that parameter name, and the editor can auto-create a suitable display material (M_PDFDisplay) for you if you would rather not build one by hand. 'Get Dynamic Material' gives you the instance back if you need to tweak other parameters at runtime.

If you need to let a developer or designer pick a file interactively in editor tooling, the library exposes 'Open PDF File Dialog' and an availability check, 'Is PDF Viewer Available', so you can guard your code paths cleanly. The plugin also ships an example Blueprint, the M_PDFDisplay material, and a NoPDFLoaded placeholder PDF so an unconfigured viewer shows something deliberate rather than a blank surface.

Where a kiosk fits in a bigger system

A document panel is often one part of a larger information surface, and a few sibling tools cover the gaps Simple PDF Viewer deliberately does not.

If the PDF you want to show does not live on disk but behind a web endpoint, EasyHTTP lets you fetch it from Blueprints. It buffers the full response, exposing the bytes as a RawContent array of uint8 on its response struct, with progress callbacks reporting bytes received, so you can pull a remote document and write it to a local file before handing the path to a PDF viewer. Note that EasyHTTP buffers the whole response rather than streaming it, so it suits documents you download in one go.

If your kiosk needs live numbers next to the static document, for example a spec sheet shown alongside a real-time gauge, Fast Chart Widgets draws eight chart types entirely in Slate inside a UMG widget. It can sit on the same terminal UI as the PDF surface and chart data your game already has.

And if the documentation you care about is authoring notes rather than a shipped in-world panel, Markdown 4 Blueprints is the right tool, but be precise about its scope: it is an editor-only WYSIWYG documentation tool that saves Markdown notes attached to your Blueprints under the project's Documentation folder. It is not a runtime in-game Markdown renderer, so use it to document the systems behind your kiosk, not to draw text onto the kiosk itself.

Key viewer controls and their ranges

All values are taken from the Simple PDF Viewer Blueprint API; ranges are the plugin's documented clamps.

FAQ