Chapter 26: Publishing
Preview (Chapter 18) shows you the template inside the editor. Publishing compiles it into a movie on the render backend, in the project the template lives in, so it can be rendered on demand — with different variable values each time — and played by the FX Player.
Publishing a template
- Save the template. File ▸ Publish… is disabled until the template has a file path.
- Open File ▸ Publish….
- Set the output. The General tab holds what most publishes need; the Audio tab holds the audio encoding, which starts at the template’s values and rarely needs changing:
| Field | Notes |
|---|---|
| Name | The movie’s name in the project. Defaults to the template’s name |
| Resolution | Pick a preset or type width × height. Both must be even whole numbers between 2 and 8192 pixels. A value outside that range is not applied — the field shows a hint and snaps back when you leave it; an odd value is applied but shows an error and disables Publish until you fix it |
| Frame rate | 24, 25, 29.97, 30, or 60 fps. A template imported with another rate (23.976, 50…) keeps it and shows it as an extra entry |
| Audio sample rate (Audio tab) | 44.1 kHz or 48 kHz. Defaults to the rate set in File ▸ Template Setup… (44.1 kHz unless changed) |
| Audio bitrate (Audio tab) | 64 to 320 kbit/s. Defaults to the bitrate set in File ▸ Template Setup… (128 kbit/s unless changed) |
- Click Publish. The dialog shows progress, then a success panel with a link to the movie in the console — or an error panel listing what went wrong.
Publishing the same name again replaces the published movie. The template file itself is untouched: publish produces a movie from the template, it does not move or convert it.
What gets published
The movie. The template is compiled into an SDL movie and saved into the project the template belongs to. Variables stay variables: the published movie records which ones it uses, and each render supplies values for them.
What can be prepared in advance. The movie also says which values each variable is expected to take, so the render service can prepare (“pre-encode”) the scenes whose variables have a known, small set of values, and render the rest live. This happens in the background after publishing; publishing does not wait for it. The success panel says quietly how many scenes can be prepared, with a details link to the Pre-encoding section of the Variables panel. Value lists and the budget are explained in Chapter 13.
Smart-object artwork. Smart objects and other generated vector artwork are rendered to assets and uploaded alongside the movie, in batches, so the render service does not have to run browser code.
Click hotspots. Every layer with a Click Action (Chapter 25) becomes a time-windowed hotspot in the movie’s overlay manifest. A hotspot on a layer with a visibility condition carries that condition with it and is armed per render, against that render’s variables.
The endcard. If a scene is marked as an endcard, it is published as its own movie — the still the player shows after playback, with its own hotspots. The endcard image itself is produced on demand at render time.
The success message tells you how many hotspots and whether an endcard went out, so you can check the interactivity landed.
Poster frames
A project template also keeps a poster frame — the still the console shows for it. It is captured in the browser from the canvas, refreshed automatically once editing has been idle for a while, and refreshed again when you publish. There is nothing to configure; if the poster looks stale, publish or leave the editor idle for a moment.
The frame captured is the scene’s poster time — set it in the Scene tab if the first frame of the scene isn’t representative.
Where the movie goes
Into the project that owns the template. Nothing separate is bookkept: a project template’s published movies live in its project, and the success panel’s link takes you straight there in the console.
Publishing vs. rendering
| Publishing | Rendering | |
|---|---|---|
| When | Once per version of the design | Once per output, potentially thousands of times |
| Where | From the editor, File ▸ Publish… | From the API, the console, or the player |
| Variables | Declared | Supplied |
| Result | A movie definition in the project | An MP4 (or a still, for an endcard) |
That split is the point of the whole tool: design once, publish once, render per recipient.
Optimize for Rendering
File ▸ Optimize for Rendering… speeds up live renders of a published template by pre-composing the parts that never change into files stored beside the template. The renderer then reads those files instead of recomputing the same frames every time. Save the template first: the menu item is unavailable until it has been saved, because the pre-composed files live next to it.
The dialog first plans the run and shows:
- how many cells would be pre-composed, and how many are already up to date from an earlier run;
- a modelled estimate of the time per frame before and after, for published renders on the production renderer. It comes from a cost model, not a measurement: the real saving may be larger or smaller;
- one row per scene, with what the render service will do with it when you publish.
What the scene rows say. A scene the render service prepares in advance (✓, see Values and Pre-encoding) is served ready-made and needs nothing more — Optimize never pre-composes it. A scene that renders live (–), or may be prepared only in parts (~), says why — a variable treated as free text, more value combinations than the budget, a length that follows a variable — and what pre-composing would add to it. Click a variable’s name to set its values right there (Auto, List or Free text, as in the variable dialog) and Apply: Optimize plans again, and a scene that can now be prepared in advance drops out of the work. The Budget per scene field below the rows is the same setting as in the Variables panel.
If nothing in the template is worth pre-composing, the dialog says so and Optimize stays unavailable: either every scene is prepared in advance when you publish, or the template already renders as fast as Optimize can make it.
Click Optimize to start. Progress is shown frame by frame. Cancel stops the run and keeps every cell already finished; the rest renders live. The dialog cannot be closed while pre-composing.
Editing the template afterwards makes the affected cells render live again until you optimize again; cells you did not touch stay pre-composed.
Live renders only use the pre-composed files once the template is published again. When the run finishes, the dialog offers Publish…, which opens the Publish dialog.
From the Publish dialog. The Publish dialog has an Optimize… button too. It opens Optimize on top of the Publish dialog; when the run finishes, Back to Publish returns to your publish settings, ready to publish.
Pre-composed cells are made at the template’s own size and frame rate. Publishing at another resolution or frame rate uses none of them: everything renders live.
The pre-composed files are stored in a precomp/ folder beside the template. Do not delete it, or any file in it, while the template is published: the published movie reads those files on every render. Files from earlier runs are not cleaned up automatically yet, so the folder grows with each run.
Troubleshooting
File ▸ Publish… is greyed out. The template has no file path yet. Save it first.
“Render dimensions must be even numbers”. Video encoders require even width and height. Nudge the odd one by a pixel — the message suggests the nearest even size.
“Render dimensions must be whole numbers between 2 and 8192 pixels”. The template’s stored size is zero, negative or fractional. Open File ▸ Template Setup… and set a real size; a template that arrives with such a value is reset to 1920×1080 when it loads.
The publish failed with a list of errors. The error panel lists what the compiler objected to. Missing media references are the usual cause — check that every image and video layer resolves, particularly in imported scene layers, whose media lives with their source template.
“Cannot publish: N TTS voiceover(s) need attention”. A voiceover whose script contains a variable is spoken fresh for each viewer rather than baked into the movie, so the published movie refers to the recording instead of containing it. Publishing checks that every such recording still matches its script, and stops if one does not. The message names the scene and the item, and says which of these it is:
- missing — the script has never been recorded. Open the scene and generate the voiceover.
- out of date — the voice, the settings or the wording changed after the recording was made. Generate it again.
- made with different credentials — the recording was made on a different text-to-speech account than the one in use now. Generate it again so it exists under the current account.
- scripted only from variables with no default — the script is nothing but placeholders, and the template’s default values leave it empty, so there is no wording to record. Give those variables default values in Variables, then generate the voiceover. Without one the scene would be silent for every recipient.
- unverifiable — the check itself could not complete. This is a fault on our side rather than something wrong with your template; try again, and report it if it persists.
Publishing never records a voiceover for you, so it can’t spend your text-to-speech allowance without being asked.
Fewer scenes are prepared in advance than expected. Open Variables ▸ Pre-encoding. Each scene rendered live names its reason: a variable treated as free text (give it a List if its values are known), a variable with more values than the budget (raise the budget or accept it), or spoken text. Nothing is wrong either way — live scenes render correctly, just not prepared ahead.
The published movie is missing a scene. Check whether it is marked as an endcard. Endcard scenes are deliberately excluded from the video.
Clicks don’t work in the player. Confirm the layers have Clickable ticked, republish, and check the success message’s hotspot count. A hotspot on a conditional layer only arms when its condition holds for that render’s variables.
The console shows an old thumbnail. Poster frames refresh on publish and after an idle gap. Publish again, or wait.
← Previous: Conditions and Interactivity | Next: Importing and Exporting →