Requirements and Compatibility¶
Which Unity versions, platforms and hardware FaceCue works on, and which parts of it work where. Read this first if you are deciding whether FaceCue fits your project.
The short version: playing a baked performance has almost no requirements, and everything on this page that does have one is about producing the bake rather than playing it.
Unity Versions¶
Unity 2021.3 through Unity 6, for both the runtime and the baker.
The floor is a compile requirement, not a recommendation. FaceCue's editor code is written against C# 9, which Unity supports from 2021.2 onward, and 2021.3 is the Long Term Support release in that line. On anything older the package does not lose features, it fails to build.
The upper figure is where testing reaches, not where support ends. Where Unity has moved an API since 2021.3, FaceCue calls the current one or the older one depending on the editor it finds itself in, so a newer version needs nothing done to it.
What Runs Where¶
| Windows | macOS | Linux | iOS | Android and Quest | WebGL | |
|---|---|---|---|---|---|---|
| Baked performances | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Live amplitude | ✓ | ✓ | ✓ | ✓ | ✓ | ✓* |
| Live viseme | ✓ | ✓ | ✗ | ✓ | ✓ | ✗ |
| Microphone input | ✓ | ✓ | ✓ | ✓ | ✓ | ✓* |
| Baking | ✓ | ✗ | ✗ |
* With a microphone solution of your own. WebGL provides no microphone API, so FaceCue cannot open one there. The loudness path reads the audio it is given rather than the platform's microphone, so a feed you supply should work, though it is not something FaceCue tests.
Baking has no entry for the three platforms with no editor to run it in. It happens in the Unity editor on a desktop, and the result of it plays everywhere. Baking on the other desktop platforms is on the roadmap.
Playing a baked performance carries no platform limitation, because nothing analyses audio while it plays. Consoles are not in the table because their toolchains sit behind agreements FaceCue ships nothing for, but baked playback has no requirement they would fail to meet.
Where the Two No Columns Come From
Live viseme on Linux is unavailable because its recognizer ships native binaries for Windows, macOS, iOS and Android, and there is no Linux one.
Live viseme on WebGL is unavailable for the same reason: the recognizer is a native plugin, and there is no browser build of it. That one is a hard limit.
Microphone input on WebGL is unavailable because the platform provides no microphone API. Bring a microphone solution of your own that delivers audio into a clip and the loudness path should run on it, since that path reads the audio it is given, not the platform's microphone.
Baked performances work normally on WebGL, so a browser build is an ordinary target as long as its dialogue is baked.
Live Paths Need Decodable Audio
Anything analysed while it plays requires the clip's import setting to be Decompress On Load. Baked performances have no such requirement, since nothing reads the samples at runtime.
Baking Is Editor Only, on Windows¶
The baker runs in the Unity editor, on Windows. It is not in a player build and it never runs at play time.
This is less restrictive than it sounds, because baking is a production step and not a runtime one. Your team bakes on Windows, the cue files go into the project like any other asset, and the game plays them wherever it runs.
Other Desktop Platforms Are on the Roadmap
Nothing about the baker is tied to Windows by design, and the runtime underneath it has macOS and Linux builds. It has simply not been ported or tested there, which is a real piece of work and not a packaging change.
Widening that is on the roadmap, long term. The GPU side would not carry across evenly even then: DirectML is a Windows technology, and CUDA exists on Linux but not on modern macOS, so CPU baking is the part that would be ported first, before exploring GPU support.
Baking Hardware¶
CPU works on every machine and is what an install bakes on until you choose otherwise. Both GPU backends ship with the package, so there is nothing to install and no vendor SDK to chase. DirectML uses any modern graphics card and CUDA uses an NVIDIA one, considerably faster.
Covered in full in Backends.
Render Pipelines and Scripting Backends¶
All three render pipelines. FaceCue drives blendshapes and bones, which are pipeline-agnostic, and the runtime references nothing from Universal or High Definition. Built-in, URP and HDRP are all fine, and so is a project that switches between them.
Both scripting backends. Mono and IL2CPP, including the targets that offer nothing but IL2CPP.
Package Dependencies¶
FaceCue adds none. Importing it does not pull anything into your manifest.
Two Unity packages are used when you already have them and ignored when you do not:
- Addressables, if you would rather load cue files that way than through the built-in registry.
- Timeline, if you want the phoneme, emotion and gaze tracks.
Neither is required, and neither is installed for you.
The one third-party piece is Meta's OVRLipSync, which powers live viseme and the universal language path. It is free and it ships with FaceCue, so there is nothing to fetch.
English Is Included, the Rest Download on Demand¶
English ships with the package, so a first bake works with nothing downloaded and nothing configured.
Every other speech model installs with one click inside the editor, so you only fetch what you use, and they all run locally on your machine once they are there. That covers the other per-language recognizers, text to speech, the voice changer and speech recognition.
Which ones you need depends on which languages you bake. See Backends, and check yours against Language Support.