M2u interactive sync script for Maya -> UE4

Hi there,
I’m currently working on a UE4 implementation to interactively sync Maya’s… let’s say “level building data”.

I started the original m2u (short for Max/Maya to UDK) over a year ago with a friend as a student-project, as the name says, for UDK.
It was quite a hassle communicating with UDK via the windows-UI :smiley:

But UE4 has full source code access, so this should be much more powerful in the long run. To get an Idea of what I’m talking about:

features you see in the video:

  • syncing the persp viewport camera
  • fast fetching selected objects from the Editor (uses ExportSelected to FBX)
  • syncing transforms of objects
  • duplicating of objects
  • hiding/showing of objects (a bit buggy)
  • deleting objects
  • parenting of objects (still very WIP)
  • renaming objects (unused and used names)

I’m actually working on this for my master’s thesis, but that means I have to write the nonsensical text-stuff soon, so I won’t have much time to actually improve the code until the end of August.

I will keep you posted, and I would like to hear from you guys what you think of it, what you think the most necessary features would be and so on. :wink:

what’s under the hood?
m2u itself is a modular python script
the UE4 frontend is a c++ editor plugin
communication between the python and UE4 side is done via a TCP port

Maya? I’m a Max-user!
Sorry to hear that :smiley:
My focus is currently only on Maya->UE4. But m2u was planned to be completely modular. We had a very basic 3DsMax implementation for the UDK version. Technically it is possible to write an implementation for any 3d-Authoring Program out there as long as the calls to the python library with the necessary data is made. Maybe my Friend who worked with me on the first m2u will get onboard when he has more time to spare, maybe some other guy will make a Max-implementation when the whole project is a little bit less WIP, we will see :wink:

Can I take a look at your code?
Of course, I have nothing to hide. :smiley:
The m2u python scripts are here: https://bitbucket.org/m2u/m2u/
I’m currently working on the feature/ue4 branch, the develop branch will always be updated when certain features have been added or bugs have been fixed. The master branch will only be updated when a bigger set of features is working as expected on mac and windows. So, when you want to try this, always check out the develop branch
The plugin code is here: https://bitbucket.org/m2u/m2uue4plugin
This code is very monolithic at the moment. I don’t have time to do nice refactoring currently, but I definitely will!

More videos:

Feature Status:

  • syncing the persp viewport camera
  • fast fetching selected objects from the Editor (uses ExportSelected to single FBX file)
  • syncing transforms of objects (now correct even with modified pivots)
  • duplicating of objects
  • hiding/showing of objects (due to the nature of how isolate select works in maya, this may not always be 100% correct)
  • deleting objects
  • renaming objects (unused and used names)
  • syncing display layers (a bit buggy sometimes)

work in progress:

  • a modular pySide based UI (some of the pipeline-tasks depend on this)
  • allow and auto-detect Maya-Y-up space
  • getting ‘known’ meshes from the file system (importing the fbx file associated with a static mesh by checking the project structure on the file system. This allows to build levels in maya, and send the whole stuff to UE at once)
  • sending ‘new’ meshes from maya to UE (export to fbx, create asset, place in level. Thought further, this allows to quickly edit meshes and get the changes in the engine with one click)
  • getting ‘unknown’ meshes which are not on the file system but exist as static meshes in UE
  • parenting and grouping of objects
  • support for other objects than meshes (namely lights)
  • making mass operations like selection and duplication faster (currently only one operation per tick)

to be investigated some day (no idea when I will come to this):

  • transferring collision data (UCX prefixed meshes)
  • transferring dependent textures (automatically import/export)
  • sending skeletal mesh posing data (interactively get posing response in engine viewport when editing animations in maya)
  • syncing cameras on playback (for creating camera paths in maya and seeing an interactive preview in the editor)
  • two way interactive sync for simple stuff like selection (select something in UE will select the same in Maya)

Please tell me what you think of it :slight_smile:

This is great, i would use it on a regular basis. What are the limitations on scene size? Any idea on when it will be finished and how much will it be?

awesome work! very impressive, that’s going to be part of my workflow now.

Heck! That’s awesome. I’ll definitely need to give this a go, once I have some free time. Thanks for sharing and looking forward to seeing more!

This is amazing work. Well done. It’s definitely going to help a lot of people save time editing meshes in the projects.

Fantastic job ! This is for sure going to be a time saver for users. Keep up the great work!

What wizardry is this? Looks really interesting! So does this work with UE4 brushes or what would be the general workflow of laying out a level like this?

Exciting, looking forward to seeing more.

This looks amazing! Sent it to the animators and riggers and everybody was pretty excited at the possibilities.



thx for the nice comments :smiley:

Did some investigation into DisplayLayers today, maya doesn’t provide many callbacks, when it comes to that. That means we are in for another session of CommandCallback and string-parsing :slight_smile:

Good to hear :slight_smile:
Limitations on scene-size? It will only be a matter of performance. The more objects are synced, the more communication and especially executing commands will have to be done. So in theory there is no limitation of how much stuff you can transfer or sync, it may only take some time for the job to fish.

When will it be finished? Don’t know if it will ever be “finished”… there will probably always turn up new features to be implemented. If the current state is all you need, just grab the code and compile it for yourself :wink: Until all the features are built in that I currently have planned… probably in two months or so (won’t have much time for programming next month)

It will be free, at least I currently have no plans on monetizing it… maybe if I come up with the-ultimate-feature™ I might think about it, but… I’m more a friend of free-stuff to help people make good games :smiley:

Currently it uses the existing static meshes from a Level (export to FBX, import in maya) and syncs by the name of the objects. So for laying out a level you would currently at least have to start by placing the required static meshes in UE first.
Moving a whole scene from maya over to UE with one click (or maybe a few more) is planned for the future.

I will keep you posted :wink:

a little update

Batch export meshes from maya.
this will check objects for an “AssetPath” attribute, which points to an .fbx file for this mesh, relative to the project’s asset-source directory. (You will be able to set that directoy through a UI or settings file in the future) If no path is given, the user’s Temp-Folder will be used. (That’s the darn long paths you see in my video, OSX temp directories). If no “AssetPath” attribute is found (because the meshes were not created with such a pipeline in mind), the script will autogenerate one based on the name of one of the same objects. Object matches are identified by checking the vertex-topolgy.
All that information has to be presented to the User in a UI, but currently there is none. So just automatic export to temp-directory for now :wink:

Silently automatically import fbx files as assets in UE.
The script will tell UE which .fbx file to import to which location in the projects content path ("/Game/…").
Silently means, that there are no popup-dialogs from UE asking about static-mesh settings or overwrite-warnings.
Problems, like overwrite, may be send to the script-ui (maya-side) to ask the user what to do, depending on user choice. Especially giving the user the option to change the name of the file/asset. This is not implemented yet, because there is no fancy UI for maya yet.
Internal FBX-import problems (errors while importing the mesh) will still cause popup dialogs in the Editor.

Automatically assemble the level.
With all assets imported, it will create a new Actor for each mesh sent from maya.
All objects in maya using the topologically same geometry will reference the same static mesh. (the info for that is taken from the “AssetPath” attribute)
The object names in maya have to be unique within the scene! Nested Transforms are not interpreted corretly! In short that means: NO GROUPS. Make sure all your objects are parented to the world only.

this will allow you to switch between interactive syncing and sending (and in some future version really two-way-syncing) the whole level to UE.
There is still some work to do to make sure that names between maya and UE will be synced. But if you just want your already built geometry in UE, the current version of the script should already be usable for you.

The Batch-file parsing stuff shown at the end of the video was mainly integrated for JBaldwin’s max-script.

If you want to use it now, you will have to compile the plugin yourself. Possibly you will have to make changes to work with the UE4 version you are using, because I’m still on 4.1. I think I will be able to update to 4.3 this weekend.
get the tag from here: https://bitbucket.org/m2u/m2uue4plugin/commits/tag/v0.1

To get the maya script, get this tag:

put the m2u folder somewhere maya can find it (maya script path) or add the path to sys.path
and execute this in mayas script editor (python of course)

import m2u

from m2u.maya import mayaInternalUI

I will keep you posted :slight_smile:

This looks insane! I’m sure this would benefit a lot of people, working like this would significantly speed up a modular workflow.

This is very very cool, I am tempted to try and port it to Cinema4D (why is there not more hours in a day!!)

any news?

thank you

I following your works with a big interest. Keep going =).

Absolutely amazing. As an old follower of I am glad to know someone else is taking over the task of finishing this. Keep it up!

edit: Also this will import correctly collision models along with the assets and correctly collide in UE4 right?

please go ahead, all you actually need to provide is a cinema4D python implementation for m2u (and, until there is a UI built on pyside, a cinema4d internal UI) please check out the m2u repository or fork it and get going. (cinema4d can talk python, right? if not, you probably would have to write something standalone up to the point where commands are sent over the TCP port)

Yes, the old work of was our initial inspiration to do start the project back then in UDK times. We wondered why never continued his work, probably had something else to do :smiley:
Collision is not actively supported currently, but since it is natively implemented in the UE-FBX-pipeline it might work out-of-the-box or shouldn’t be hard to get working. But there are other parts I want to look into before that, since the main idea of m2u is that configured assets already exist on both ends of the pipeline :wink:

What happens if you move the pivot point from the model or create a group ? The sync is broken or ?

I got the pivot thing working two days ago. This also works in hierarchies, as long as the hierarchies are the same in the UE.

The problem is, UE has only a very… simple… implementation for hierarchies (aka. nested transforms, grouping, attaching) because they obviously decided to go for the horrible invisible-locked-groups-thing from 3DsMax :smiley:

Objects in a hierarchie in UE will not be duplicated, when the parent is duplicated.
When I send a transformation to UE it has to be relative to the parent. If the parent does not exist in UE (or the object is not attached to that parent) the transformation will be off.
Therefore, groups from maya have to be mirrored in UE by creating an empty transform, for which there is no real useful actor there.
I could create StaticMesh actors without a mesh… they will be displayed as a warning in the analyze window when building the level.
I could create a Note actor instead… they will be displayed as a Note in the analyze window.
Both options are annoying.
The other actors possible would be TextRenderActor or TargetActor, which both are dynamic, and thus you cannot attach static meshes to them.
Creating a StaticMesh Actor with a static mesh but setting it to be hidden in Editor and in Game could be another solution, but those will show up in FBX files when exporting and so.
Providing a “MayaStyleGroupActor” (all we need is a transform node) with the Plugin is no option because the plugin should be editor-only and not required for shipping the game.

After testing a little, I came to the conclusion that it is possible to set Actor’s mobility to static, via code, although it is hidden in the editor. So I will probably go with creating TargetActors for Groups and setting them tho static.

The complete other solution would be to not reproduce grouping information at all in UE and always use world-space transformations, but I think grouping information is not only important for transformations, but also for cleaning up the outliner. That is why i will go with the TargetActor as an empty transform way. Until UE comes with a simple TransformActor that the user can toggle dynamic or static if that is needed for matinee animations or so.