io_scene_psk_psa: Unreal PSK and PSA files inside Blender
A Blender extension for importing and exporting Unreal PSK and PSA files
At a glance
- What is it?
- This Blender extension imports and exports meshes and animations in the PSK and PSA formats used by many versions of Unreal Engine, and it is candid about the format's rough edges, from the absence of a unit system to smoothing groups instead of vertex normals. The documentation does more than most in explaining why your model looks the wrong size.
- Who is it for?
- io_scene_psk_psa fits a Blender artist or technical artist who has to move skeletal meshes and animation between Blender and an Unreal Engine pipeline, and who wants the format's rough edges explained rather than hidden. It is the wrong choice for a Blender version below 4.2 unless you accept the legacy line, which the documentation says is no longer maintained.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 41 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A format bridge, not a game engine integration
The README describes the project as a Blender addon that allows you to import and export meshes and animations to and from the PSK and PSA file formats used in many versions of Unreal Engine, with a link to the Beyond Unreal wiki page for those formats.
The scope is deliberately narrow, and that is what makes it useful. PSK is the skeletal mesh format and PSA is the animation format, and both are old enough that they persist across many engine versions, which means a studio moving between engine versions, or between Blender and an engine pipeline, still has assets in them.
The software is licensed under GPLv3, with the COPYING file at the repository root, and the project is published through the Blender Extensions platform, which is where the download badge in the README points. There is also a ko-fi badge, so the project takes direct support.
The repository layout is a Blender extension package, with the `io_scene_psk_psa` directory holding the addon, a `tests` directory, a `test.sh` script, a Dockerfile, and a pyproject.toml that exists mainly to configure the test run rather than to package anything for distribution.
The audience is specific: a Blender user working in a game pipeline where Unreal assets need to move in and out. It is not a general importer and it does not try to be.
Installation moved to the Blender Extensions platform
The Installation section is two sentences and a version boundary.
For Blender 4.2 and higher, you download the latest version from the Blender Extensions platform. For Blender 4.1 and lower, the README points at a Legacy Compatibility section.
That section explains itself plainly. It is a table of the latest addon versions compatible with older versions of Blender, and the versions in it are no longer maintained and may contain bugs that have been fixed in newer versions, with the recommendation to use the latest version of the addon for the best experience.
So there are two populations of users here. Anyone on a current Blender takes the extension from the platform and gets fixes. Anyone on an older release is pinned to a frozen copy of the addon with known issues, and the documentation is honest that this is a fallback rather than a maintained path.
The install itself is the platform's job, which is a real convenience. A Blender extension is installed through the extensions manager rather than by copying files into an addons directory, and the version pinning that an old Blender install needs is handled by whatever release of the addon the platform still publishes for it.
PSKX carries data that only survives one way
The feature list is where the format's real behaviour shows, and the most interesting entries are the asymmetric ones.
Non-standard model data, in the .pskx file format, is supported for import only. That data includes vertex normals, extra UV channels, vertex colors and shape keys. And non-standard animation data is supported for import only as well, in this case scale keys.
The direction matters. The reason is the format itself. The README is blunt about the next entry: the PSK format does not support vertex normals and instead uses smoothing groups to control shading, and a mesh's Custom Split Normals Data will be ignored when exporting to PSK. So vertex normals can be read in from a .pskx file, since a file written by something else may contain them, but they cannot be written back out. The same reasoning applies to scale keys.
The data that does survive a round trip is the PSA sequence metadata, for example the frame rate, which is preserved on import so that the data can be reused on export. That is a deliberate design decision about what to keep faithful, and it is one of the reasons to use this addon rather than a general purpose interchange format: it knows which fields matter for a game engine and which do not.
Collection exporters are the workflow the addon wants you to use
The Export section opens with a recommendation rather than a command: it is highly recommended to use the provided Collection Exporters workflow, since it allows for highly reliable, repeatable exports of both PSK and PSA files. The traditional export workflow is available as well.
That recommendation is the thread running through the whole feature list. A collection is a Blender container, and exporting a collection is a way of naming a set of objects once and exporting them the same way every time, which is exactly what a pipeline needs when the same character or prop is exported on every build.
The features support that workflow in specific ways. Bone collections can be excluded from PSK and PSA export, which is useful for excluding non-contributing bones such as IK controllers, and excluding a whole bone collection at once keeps IK controllers out of the export. Material slots can be manually re-ordered on export, since the order of materials in the mesh has to match what the engine expects.
For animation, PSA sequences can be exported directly from actions, or delineated using a scene's timeline markers, pose markers, or NLA track strips, which is what allows direct use of the NLA when creating sequences. Sequences can also be compressed via resampling ratios or frame quotas, and importing can be fine-grained so you pull in only the sequences you want, which matters when the file is large.
PSK has no unit system, and that is your problem to solve
The FAQ answers the question every new user asks, which is why imported models look wrong, and the answer is unusually clear about the cause.
The PSK format, unlike other more modern formats, has no explicit or implicit unit system. Each game has its own convention as to what the base distance unit will represent, and as such the addon makes no assumptions about the unit scale of imported PSKs.
Two remedies are given. The preferred one is to change the Blender scene properties to match the unit system and scale for the game you are using, which is non-destructive and ensures that the unit scaling of any PSK or PSA exports from Blender will match the source file from which it was derived. The second is to change the `Scale` value on the PSK import dialog, which scales the armature by the factor provided. The README notes that this is more destructive, but may be preferable if you do not intend on exporting PSKs or PSAs to a game engine.
The distinction between the two is a useful one to internalise. The scene-scale approach is a statement about your document, the import-dialog scale is a transformation applied to one object, and only the first one survives into your exports. A pipeline that imports at one scale and exports with the other quietly changes the size of every asset it touches.
Shading is smoothing groups, and UE Viewer does not preserve them
Two FAQ entries deal with shading, and together they are the strongest argument for reading the documentation before importing.
The first is that the PSK format does not support vertex normals and instead uses smoothing groups to control shading, and that a mesh's Custom Split Normals Data will be ignored when exporting to PSK. The recommended way to control shading is therefore to use sharp edges and the Edge Split modifier, since that is what a smoothing group is derived from, rather than painting normals that will be thrown away.
The second is more awkward. If preserving mesh normals matters to your workflow, it is not recommended to export PSK files from UE Viewer, because UE Viewer makes no attempt to reconstruct the original smoothing groups, so the normals of imported PSK files will be incorrect and will need to be manually fixed. The README mentions a pull request to add support for exporting explicit normals from UE Viewer, and notes that the maintainer has seemingly abandoned the project.
That last detail is worth weighing. If your existing assets came out of a tool that discards smoothing groups, the addon cannot recover them, and the fix is manual work per asset rather than a setting. The addon is careful to say so, which is more useful than a tool that silently imports wrong normals.
The test environment runs Blender inside a container
The Dockerfile in the repository root is the most informative file in it, because it shows how the project tests an addon that only runs inside Blender.
The base is Ubuntu 22.04, and the image installs the graphics and input libraries a headless Blender needs, including libxxf86vm-dev, libxfixes3, libxi-dev, libxkbcommon-x11-0, libgl1, libglx-mesa0, libxrender1 and libsm6, along with python3 and python3-pip. Two helper packages do the heavy lifting: `blender-downloader` fetches a Blender build and `pytest-blender` derives the matching interpreter path.
The Blender version is a build argument:
FROM ubuntu:22.04
ARG BLENDER_VERSION=5.1and the two paths are exported as environment variables so the test run can find them:
$BLENDER_PYTHON -m pip install pytest pytest-cov psk-psa-py==0.0.4The dependency pinned there, `psk-psa-py==0.0.4`, is the only third-party package the addon itself relies on for the format, and pinning it exactly is what a test suite should do. The container ends by running the test script from the repository:
ENTRYPOINT [ "/bin/bash", "-c" ]
WORKDIR /io_scene_psk_psa
CMD ["source tests/test.sh"]The pyproject.toml points pytest at the addon directory with `blender-addons-dirs` set to `io_scene_psk_psa` and `testpaths` set to `../tests`, and it configures coverage with branch tracking enabled and error ignoring on, plus a pyright section for the type checker.
Version 7.1.0, GPL-3.0, and a branch pushed in September
The licence is GPLv3, stated in the README and shipped as the COPYING file at the repository root. For a Blender addon, the GPL is the norm rather than an exception, since Blender itself is GPL and addons are expected to match.
The recent releases are 7.1.0 from 2024-07-18, 7.0.0 from 2024-03-26 and 6.2.1 from 2024-03-26, so two of the three shipped within a day of each other, which reads like a maintenance release and a follow-up fix.
The repository is not archived and the last push was on 2026-09-12. There is a CI badge pointing at a workflow called main.yml, so the test suite described above runs on every change, and the top-level entries include a .github directory, a .vscode directory and a .gitattributes file.
The gap between the newest tag and the branch is the thing to keep in mind when you install from the platform. The extension build on the Extensions platform is what users get, and it tracks the released versions, while the branch may carry work that is not yet published. The README's advice to use the latest version of the addon applies within that constraint, since the newest published version is the newest supported one for your Blender release.
Editorial conclusion
io_scene_psk_psa fits a Blender artist or technical artist who has to move skeletal meshes and animation between Blender and an Unreal Engine pipeline, and who wants the format's rough edges explained rather than hidden. It is the wrong choice for a Blender version below 4.2 unless you accept the legacy line, which the documentation says is no longer maintained. Verify first that the Blender Extensions version matches your Blender release, decide whether you need the one-way extras such as vertex colors and shape keys, and set your scene unit scale before the first import rather than after.
Frequently asked questions
How do I install the io_scene_psk_psa Blender extension?
For Blender 4.2 and higher you download the latest version from the Blender Extensions platform. For Blender 4.1 and lower the README points to a Legacy Compatibility table, whose versions are no longer maintained and may contain bugs fixed in newer releases.
Why is my imported PSK model the wrong size?
The PSK format has no explicit or implicit unit system and each game has its own convention for the base distance unit, so the addon makes no assumptions. The preferred fix is to set the Blender scene unit scale to match the game, and the alternative is the Scale value on the PSK import dialog, which is more destructive.
Does the addon support vertex colors, shape keys and extra UV channels?
Yes, through the non-standard .pskx model format, but for import only. The same one-way rule applies to non-standard animation data such as scale keys, while PSA sequence metadata such as frame rate is preserved on import so it can be reused on export.
How do I control shading when exporting to PSK?
The PSK format does not support vertex normals and uses smoothing groups instead, and custom split normals are ignored on export. The README recommends using sharp edges and the Edge Split modifier to control shading.
Why don't my imported PSA animations play on the armature?
Importing a PSA creates Actions for each selected sequence but does not apply them to the armature, because a PSA can contain several sequences and importers generally should not modify the scene unexpectedly. You apply the actions yourself in the Action Editor or the NLA Editor.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/darklightgames-io-scene-psk-psa)Was this useful?