Download

Migration question

Hi Folks!

I would like to understand what migration means. It is possible to transfer assets from one project to another project. But what does it mean? Does that mean that the assets are physically copied to the new destination (and occupy more hard disk space), or does it mean that the assets will be linked?

Thanks in advance for the answers.

Migration copies not only the assets you want to copy to another project, but also the assets they reference. For example, if you want to copy a static mesh to another project, that static mesh references a material, and that material references a texture. So the migrated assets will be the static mesh, the material, and the texture. If you copy things by hand, you may miss something and cause broken references in the new project.

This comes in handy when you are migrating things like blueprints, where they may reference tons of assets. Instead of having to manually locate each one, you only have to worry about the assets you want to copy, then the migration system deals with the rest.

The entire folder structure is copied as well.

e.g. Gen Assets → Meshes → SM_Rock

Migrating SM_Rock will copy the mesh along with the folder structure and all mesh dependencies (Material, Material instance, textures).

When you click migrate a context menu will list everything that’s required for migration.

Thank you. That means all the dependencies are physically copied to the new destination and not simply linked?

Correct. All are physically copied (duplicated).

1 Like

I wish for the next version something like a common repository accessible for all projects. So one can save space when same assets are used in more than one project.

You can do that already. Just put the content in the engine content folder:


This makes them accessible to all projects with the same engine version. Though, you need to make sure that any assets you put in the engine content only reference assets in the engine content.

1 Like

Oh, this is a good news. There are a lot of things I still have to learn… Thanks.

1 Like

Just be aware there are gotchas to using the engine content location! Overall, a central repository was how UDK worked before. So none of this is new to Epic. Its more a case of they didn’t like it, and so switched (and won’t be going back presumably). While it saves disk space sometimes and offers common-linked customized assets, here are some of the gotchas…

Its way too easy to over-save an asset in one project and end-up killing hundreds of others. Its also too easy to zip-up a project to take to work or move to another rig or send to another dev, and 100% forget to include the dependent engine content. Tracking that down can be a PITA.

Disk space is a bigger issue. Lots of devs use HDD’s or cheap external memory / cloud storage to make up for miserly SDD’s that ship with mass produced rigs and just aren’t enough for game dev. BTW: I hated UE’s lack of centrally shared assets. But now I’m a believer. Self-contained project-folders that are independent of other projects and independent of engine installs or versions / versioning solve other problems including project corruption issues1 If you use the engine content location, once you have to upgrade the engine that all breaks anyway. Look at how many versions devs have had to install since 2014 and UE5 isn’t production ready! :wink:

1 Like