Your Altium 3D models don't show up in KiCad.
You migrate the board, open the 3D viewer, and it's empty — "No 3d models present." The copper and the footprints came across; the 3D bodies and STEP models didn't. It's a documented Altium → KiCad import gap, and it's the kind of thing you find in a design review instead of on a report. This page explains why it happens, and what Crosspad does about it for your specific project.
Free analysis on one Altium .PcbDoc — one board file, not a project. Files are processed as described in our Security policy.
The board comes across. The 3D models often don't.
Altium keeps a component's 3D presence in two places: 3D bodies drawn into the footprint (extruded shapes and generic 3D bodies), and STEP models embedded in or linked from the library. A standard Altium → KiCad migration can bring the 2D footprint across cleanly while leaving that 3D layer behind — so the pads and courtyard are right, but the part has no model on the board. This is documented in KiCad's own public issue tracker: 3D and STEP models not imported from Altium is tracked as #15058, and it is open as of KiCad 10.0.6. Separately, KiCad's own import documentation states that Altium's 3D package placement data is read but not applied — so even where a model does resolve, its position and rotation on the board may not. Library 3D models are the second half of the problem: KiCad resolves 3D models through its own model paths, so an association that was implicit in the Altium library frequently doesn't reconnect after import, and the footprint lands with no model attached.
Scoped honestly: #15058 is open as of KiCad 10.0.6 (2026-08-29); the placement limitation is a standing documented behavior of the importer, not a version-specific bug. We re-verify both each release.
What you actually see.
You finish the migration, the board opens, DRC looks sane — and then you press the 3D view. Instead of your assembly you get an empty board, or the status line "No 3d models present." Sometimes it's every part; sometimes it's the ones whose models lived in the library rather than in the footprint; sometimes the models are there but sitting at the wrong height or angle because the placement offset didn't carry. Nothing errored. The migration reported success. The gap only shows up when you, or a mechanical engineer checking fit against an enclosure, go looking for the 3D — which is exactly the wrong time to find out a model is missing.
A board that opens isn't a board whose 3D is intact.
Every 3D-model reference accounted for — and the missing ones named.
Crosspad reads your Altium source directly and builds an inventory of every 3D-model reference it carries — the 3D bodies on each footprint and the STEP models the library points at. After the migration, it checks that inventory against the result: for each referenced model, is it present on the migrated board, or not? The ones that didn't carry are flagged, per component, as an explicit action — with the reference that's missing named, so you know precisely which parts to re-attach a model to rather than discovering it later. Being honest about the boundary: this is an accounting-and-flag capability, not geometric reconstruction. Crosspad does not claim to rebuild dropped 3D geometry or to restore a model's exact placement — it tells you, provably, which referenced models are missing from the result and which are present, so nothing about your 3D disappears in silence. Where a model is present but its placement couldn't be confirmed against the source, that's surfaced as a decision, not passed as done.
Crosspad names each missing 3D-model reference as an action to take, never passes it as complete.
If a 3D model your source referenced isn't present in the migrated board, Crosspad shows it to you — it doesn't quietly leave the board empty.
Frequently asked questions.
Why are my Altium 3D models not imported into KiCad?
Because a standard Altium → KiCad migration can move the 2D footprint while leaving the 3D layer behind — the 3D bodies drawn into the footprint and the STEP models the library referenced. It's documented in KiCad's public tracker as #15058 (open as of 10.0.6), and KiCad's import docs also note that Altium's 3D placement data is read but not applied, so even models that do resolve can land at the wrong position. The board opens and reports success, so the gap usually surfaces only when you open the 3D view and see "No 3d models present."
Can Crosspad restore the 3D models Altium dropped?
Crosspad accounts for them: it inventories every 3D-model reference in your source and flags, per component, the ones that aren't present on the migrated board — so you get a precise list of what to re-attach instead of finding out in a design review. It does not claim to reconstruct 3D geometry or perfectly restore placement; the honest promise is that a missing model is a named finding, not a silent gap. Point Crosspad at your project to see exactly which parts are affected.
See which of your parts lose their 3D model.
Point Crosspad at an Altium project and get a per-component account of which 3D-model references carried into KiCad and which didn't — before it costs you a fit check.
Free analysis on one Altium .PcbDoc — one board file, not a project. Files are processed as described in our Security policy.
Keep reading
- Back to all known import issues
- Migrating Altium libraries to KiCad
- Altium → KiCad migration, end to end
Last updated 2026-08-31. Anchored to KiCad 10.0.6 (2026-08-29). #15058 is open as of this version; the 3D-placement limitation is a standing documented behavior of the importer. This page is refreshed on each KiCad point release that changes Altium import. Source: KiCad's public issue tracker and import documentation.