-
Notifications
You must be signed in to change notification settings - Fork 14
03. Importing Into Animation Software
MiEx exports out into USD (Universal Scene Description) which is supported by most animation software, so in theory you can import in the generated .usd file into any of the animation software and it just works. Unfortunately, not all animation software properly support importing in materials (which MiEx also exports out for you). Normally, you'd need to manually set them up after importing in a world, however for MiEx we've created some addons and scripts to work around this issue, so that you can just directly import in your exports and have everything set up as it should be. This does mean that you need to set things up a certain way when exporting your worlds out. This page will explain what you need to do for various animation software.
The main difference with different animation software has to do with the materials. MiEx will export out the materials for you based on material templates, but each render engine and animation software has their own set of shading nodes. Therefore, MiEx will need to generate materials using the shading nodes of that render engine and animation software. This basically means that we need different material templates for different render engine and animation software combos. We provide a bunch of different materials templates as example resource packs, which you can download using the "Download Example Resourcepacks" tool found in MiEx.
If you are referencing the export out directly into USD, rather than importing it into an animation software thereby converting it into that animation software's data format, then you won't have to do a whole lot. The base_resource_pack already comes with material templates for MaterialX materials which is supported by multiple render engines. Alternatively, you could enable the UsdPreviewSurface resource pack which provides UsdPreviewSurface materials, although these materials won't show up correctly due to being very limited in what you can do with a UsdPreviewSurface material.
In most cases though, you would want material templates for the render engine that you use. The Renderman example resource pack provides such material templates for Pixar's Renderman. Note that it's Renderman and not the RendermanForMaya example resource pack. RendermanForMaya creates Maya materials and not USD materials.
If you want to import in your worlds into Blender, then we have created an addon that you can install. This addon only supports Blender 4.0 and up. This addon adds in an importer for MiEx .usd exports. The importer imports the .usd file in using the normal USD importer, but then it will also automatically import in the materials as regular Blender materials using Blender shading nodes, so that you don't have to. If not all of the textures show up after importing, then there most likely was an error during the importing of the materials. In that case, enable the System Console in the Window menu. The error should show up in there when importing an export in. Please include this error when opening up an issue or creating a post in the Discussions page.
In order for the addon to be able to import in the materials as regular Blender materials, it needs MiEx to export those Blender materials out. These materials are exported out into an accompanying _materials.json file, which the addon reads in. In order to get MiEx to generate such a _materials.json file, you need material templates that are set up for this. Luckily, we have two example resource packs called BlenderEEVEE and BlenderCycles that you can download using the "Download Example Resourcepacks" tool. These two example resource packs contain material templates for Blender materials and will cause MiEx to export out that _materials.json file. The two resource packs are very similar, but specialised for either EEVEE or Cycles. Do not enable both of them at the same time! Only one of them should be enabled at a time, so you either export out for EEVEE or for Blender.
The main difference is that Cycles does not support backface culling (also known as single sided geometry). Minecraft terrain is all rendered out with backface culling and the block models therefore are created for that. So, the BlenderCycles example resource pack tells MiEx to export out the world as double sided geometry (without backface culling). This makes things show up normally in Cycles, but some blocks will look slightly different from Minecraft (but most won't notice the difference at all).
Of course you can always make your own versions of the BlenderEEVEE and BlenderCycles resource packs to get whatever materials you want.
Autodesk Maya has Maya-USD, which lets you work with USD natively. In that case, follow the directions above for the Native USD workflow. If instead you want to import the world into Maya directly, rather than keeping it as USD data, then we have an import script that you can use to import the MiEx .usd files into Maya. This import script will import the USD file in via the Maya-USD importer, but it will also import in the materials as regular Maya materials using Maya shader nodes.
In order to the import script to be able to import in the materials as regular Maya materials, it needs MiEx to export those Maya materials out. These materials are exported out into an accompanying _materials.json file, which the script reads in. In order to get MiEx to generate such a _materials.json file, you need materials templates that are set up for this. Luckily, we have various example resource packs in the form of *ForMaya, that you can download using the "Download Example Resourcepacks" tool. These example resource packs contain material templates for Maya materials and will cause MiEx to export out that _materials.json file.
The StandardSurfaceForMaya example resource pack is the main resource pack and provides you with materials for use in the viewport. It uses the cpvColor node to get the biome colours, which isn't supported by render engines. Therefore, these materials are solely for the viewport. The other example resource packs like ArnoldForMaya, RedshiftForMaya, and RendermanForMaya provide materials for their respective render engines. These materials are hooked into the render engine specific surfaceShader attribute, rather than the generic surfaceShader attribute. The idea is that you always have the StandardSurfaceForMaya example resource pack for viewport materials and then either ArnoldForMaya, RedshiftForMaya, or RendermanForMaya to provide the actual materials used by the render engines.
Of course you can always make your own versions of these *ForMaya resource packs to get whatever materials you want.
Unfortunately, we currently do not have an import addon or script available for Cinema4D (if anyone would want to create one, please feel free to!) This doesn't mean that you cannot import worlds into Cinema4D at all, it just means that it will take some more time to fix things up after the import.
You'll most likely get the best results by enabling the UsdPreviewSurface resource pack that should already have been installed. Then import in the .usd file into Cinema4D using the normal USD importer. Hopefully, you will have materials with the textures on them, but they most likely won't look that great. This is where you'll then need to manually fix up the materials.
In some cases, you might want to export out a very large region of a world (think over 4000 blocks wide). Some animation software might struggle with such a large export. Here are a couple of tips to improve the responsiveness of your animation software:
- Make use of atlases. MiEx creates a material for every texture used. You could end up with hundreds of materials in some cases. Animation software really struggle with this. Atlases combine textures together into larger textures, thus reducing the amount of materials needed. MiEx comes with an Atlas Creator tool that you can use to make the atlases.
- Enable Level-of-Detail. LOD will simplify the world the further away chunks are from the LOD region, thereby reducing polycount. The LOD region is the area that should remain in full detail. Outside of that, MiEx will progressively reduce the resolution of the world. This can look weird up close, but when far away you won't be able to notice. A good width and height for the LOD region is generally about 1024x1024 blocks.
- Increase the chunk size. With very large worlds, you could end up creating a lot of export chunks, which also means a lot more objects to manage by the animation software. Reducing the amount of export chunks created, reduces the amount of objects. For very large sets, a chunk size of 64 could be a good value.
- Enable
useGeometrySubsetsinmiex_config.json. Normally, MiEx creates an object for each material, but with this setting enabled, MiEx will create a single object for each export chunk with multiple materials assigned to it. This can help further reduce the number of objects.
MiEx directly references the textures in the resource packs, rather than copying them over into a folder next to the export file. This does mean that MiEx by default will use absolute paths for the texture files (unless you specify the USD prefix). This does mean that you won't be able to zip up the exported USD files and share them with others. Luckily, it is relatively easy to set MiEx up so that it will generate portable exports that use relative file paths for the textures.
Enable environment setting MIEX_PORTABLE_EXPORTS using the "Edit Environment Settings" tool. This will cause MiEx to copy over all used textures into the export's chunks folder.
Another way to create portable exports, is to set it up so that it creates relative paths to the resource packs rather than copy everything over:
Step 1: Set up the resource pack prefix. MiEx exposes a couple of environment variables and command-line arguments. If you set the MIEX_RESOURCEPACK_USD_PREFIX environment variable or -rpUSDPrefix <string> command-line argument to be ./resources/, then all texture paths will use that relative path rather than an absolute path. This assumes that all of the resource packs are located in the resources folder next to the MiEx jar file. If you have it located somewhere else, a different relative path would be needed.
Step 2: Export out your world like normal, but export it out into the same folder that the MiEx jar file is in. The relative path that we specified in step 1, is relative to the exported USD file. So, if we exported it out into C:/Users/user/Documents/MiEx/export.usd then it will the relative path of ./resources/ would be C:/Users/user/Documents/MiEx/resources/.
Now you can zip up the exported USD file, together with the resources folder, and send it to other people. These instructions are meant for when you need to share it with random people, not when working in a team at something like a production company. In that case, either things would already be set up that the absolute file paths already work for everything and thus nothing would have to be done, or the resource pack prefix should be set up based on the specific pipeline used.