Modelling blocks for Medieval Engineers is a process
that involves a lot of intermediary files and manual parametrization.
This add-on simplifies the steps you need to take to get from a 3D mesh in Blender to
Medieval Engineer’s own .mwm
mesh-format. To do that
-
The add-on provides property panels for all the special data ME stores inside an
.mwm
file directly in Blender. -
You use Blender layers to define the main model, the collision model, mount-points, mirroring-settings, level-of-detail models and construction stages.
-
The workflow that configures and runs the conversion-tools (Havok, MwmBuilder) for you is customizable to suite your needs.
The add-on (and this documentation) expect you to know how to work with Blender. So if you are new to 3D modelling you should probably learn how to do that first before you continue. | |
If you are modding Space Engineers, you will want to use Harag's se-blender add-on, which this is based on. |
Installation
Getting the tools
To get started first you need to download and install all the required tools.
- Blender
-
Get version 2.79 (100MB). (2.80 brings a lot of changes and will be supported in the future.)
- The Havok "Content Tools for Game Artists and Designers"
-
Get version 2013.1.0 - 2014.1.1 (64bit or 32bit should work)
The free offering of these tools has been discontinued. Currently there are no legitimate sources any versions of HCT (such as the popular havokcontenttools_2014-1-0_20140830_64bit_pcxs version). Please also take a look at this forum thread to see if the situation has changed. |
Havok provides the filter manager hctStandAloneFilterManager.exe
that’s used
to create rigid-body physics data.
The default install location is C:\Program Files\Havok\HavokContentTools
- The Havok FBX Importer
-
Havok 2013 FBXImporter.exe (3,5MB)
Havok 2014 FBXImporter.exe (3,5MB)The .zip contains just one executable file. It’s probably a good idea to put it into the Havok Tools directory.
- MwmBuilder
-
This one comes with the Medieval Engineers ModSDK (available on Steam through the "tools" tab) and is located under
MedievalEngineersModSDK\Tools\VRageEditor\Plugins\ModelBuilder
.
If you try to export and MwmBuilder fails with the error message
"Error loading unmanaged library from path: Assimp32.dll"
this is a strong indication that you are missing a software library on your system.
You can
download
that from Microsoft.
Get the VSU_4\vcredist_x86.exe package.
|
Installing the Add-on
Once you got the current version (50kb) install it in Blender like any other third-party addon by going to the user preferences, switch to the "Add-Ons" tab, click on "Install from File…" and point Blender to the downloaded .zip.
Alternatively, you can extract the `medieval_engineers` folder and place it in \AppData\Roaming\Blender Foundation\Blender\2.79\scripts\addons\
.
Then hit the refresh button on the add-ons panel in blender.
Like any add-on you need to enable it after you’ve installed it. You can find the add-on by using the search box or going to the Category "Medieval Engineers". After you’ve enabled the add-on open its settings by clicking the arrow on the left. You need to provide all the paths in the list.
Don’t forget to "Save User Settings". |
If you also have the Space Engineers Blender add-on installed, you may want to disable it while working on ME projects to stop the interface from getting cluttered.
Using the Add-on
File layout
The add-on only has one mandatory requirement in regards to the folder layout:
The .blend file(s) must be in the base-folder of your mod. |
This is necessary so that all relative paths (textures, models, etc.) are calculated correctly.
Scene Layout
The addon only provides its tools to scenes that are marked as containing a block.
You do that on the Medieval Engineers Block panel of the Scene properties-tab.
Here you also find the settings that are relevant for the basic layout of the block:
-
Is the block a large or a small block?
-
Should the export automatically create a small version of your block if it is a large one?
-
What is the dimension of you block in in-game grid-units?
The layers of the scene contain the different components of a block. Below is the default layer-setup that is described in the following sections.
Main Model
The first layer contains the model of the fully-built block. You don’t need to restrict yourself to only one mesh-object on this layer. If it’s useful to split your block into several objects — probably to apply modifiers to some of them — by all means do so.
Collision Model
The second layer contains the simplified meshes that represent the block’s collision shape. If you don’t provide any collision meshes the resulting .mwm file will not contain collision data and ME will default to a simple collision box that encompasses the volume of the whole block.
Havok, the physics engine of ME, requires some settings to do its work.
You provide those on Blender’s Physics tab by enabling Rigid Bodies
for
your collision meshes.
Only the settings Shape
, Mass
, Friction
and Bounciness
(Restitution) are exported to Havok.
Of those settings Shape
is the most important because it has a significant
performance impact.
Whenever possible try to only approximate the shape of your block.
Use primitive shapes like Box
or Cylinder
. Use Convex
Hull
only if necessary. Avoid Mesh
collisions.
Make sure you apply object transformations to all collision objects before export. As a rule of thumb the add-on never modifies your objects on its own so you have to do this yourself. If you don’t the collision shapes will most probably be rotated or positioned wrong. |
Blender offers a Cone primitive shape but Havok has no support for
that.
If you use a Cone shape it will be silently treated as a Convex Hull on export.
|
Mount Points
The third layer defines the mount points of your block. The meshes on this layer are not directly exported but are used instead to calculate the mount point definitions .
This works by creating rectangular faces that use the material MountPoint
and
are aligned to one of
six sides of the block. To quickly create the material and an object that has one mount
point face for each
of the six sides use the corresponding button on the Tools panel of the 3D view.
Duplicate, resize and move those faces in edit mode to create more mount points for a side
of the block.
You can also split out faces to several objects if you want to apply
modifiers like 'mirror' or 'array'
to some of the mount point faces.
For mount point editing it is a good idea to switch to ortho-view
(Numpad
5
) and
turn on 'snap to grid'.
You can also tell the add-on to show the block’s bounding box by enabling the option
on the
scene tab .
It’s dashed, orange lines represent the space your block occupies in-game.
This should help you to position the mount points correctly.
If you don’t provide mount points none will be calculated. The game defaults to full mount points on all sides of the block in that case.
Construction Stages
Layers 11-13 are used for the construction stages of the block. There is one layer for each stage of construction, from earliest to latest. If you change the number of construction layers you increase or decrease the number of construction stages. A block is allowed to have no construction stages at all.
If you don’t have meshes on a construction layer it will be skipped and your block will have one stage less. |
By default the construction stages reuse the same collision shape your main block model uses. It’s possible to change that using different export settings. But keep in mind that can be dangerous to a ship or the player if a block changes its physical dimensions when it is welded to completion.
A Blender mesh-object can be assigned to several layers. So if your construction models get more and more detailed you can start with the basic shape as one object that is visible on all construction layers and then progressively add more objects towards the final construction layer. |
Levels of Detail
Layers 6-8 are used to model versions of your main model that have progressively less detail. The game can display those models when the block is too far away to see the small details of your main model. This way less triangles need to be rendered which is good for performance. The default distances at which the models are switched are 10, 30 and 50.
If you don’t have meshes on a LOD layer it will not be included in the export and the game will not switch models at that distance. |
DirectX 11 Textures
ME now uses DX11, which employs Physically Based Rendering (PBR) to render 3D objects. This is represented by a set of three or four textures.
PBR textures
The ColorMetalTexture
(_cm
) and NormalGlossTexture
(_ng
) correspond with the common
metal/roughness
workflow
where glossiness is just the inverse of roughness. Here the normal map uses the OpenGL
convention,
i.e. in comparison to the DirectX convention the green channel is inverted.
AO, Emissivity and Recoloring
The AddMapsTexture
(_add
) combines additional greyscale maps in its
four channels:
-
The R-channel contains a baked Ambient Occlusion (AO) map where a value of 255 means 'no occlusion' and 0 means 'fully occluded'.
-
The G-channel contains the emissivity. 255 is fully emissive, 0 is non-emissive.
-
The B-channel is used for the parallax heightmap.
-
The A-channel contains the re-coloring mask. The difference with the DirectX 9 equivalent is that the parts of the ColorMetalTexture that are selected by this mask are usually colorless.
Transparency
The AlphamaskTexture
(_alphamask
) is optionally used to make parts
of a texture transparent.
It has a single greyscale channel which really only differentiates between two states:
fully transparent below a value of 128 or fully opaque at 128 or above.
This is most useful for things like foliage and small details like facial hair.
If you want to use this texture you need to also set the technique of the material that uses
it to Alphamask
.
Materials
Texturing
Materials are what you use to tell ME which texture-files to use for the faces of your meshes (and you use UV-mapping to tell the game which part of a texture to use for a face).
In Blender there are several types of materials depending on the renderer selected. Blender Render is the default option, however for the node-based ME materials to work you much switch to the Cycles renderer.
This add-on needs you to use node-based materials because it sets up several nodes to preview the textures in Blender. To generate these nodes, after creating a new material you should click the button. You need to repeat this for each new material you define.
By doing that you get four texture-slots for the different kinds of textures ME expects.
Point them each to the texture-file corresponding with its name.
You will also see two sets of sliders for Parallax and Wind. These are explained below.
You won’t be able to see any textures on your meshes until you set your viewport-shading to Material. Setting it to Rendered looks even better but requires a lamp in the scene or everything will be black. |
In a previous version of the add-on the Blender Render and its
texture-slots were used. If your .blend still uses it there is an operator
Upgrade All Materials to use Nodes you can use to get to the new
material setup.
It’s not available on any panel, you need to use Blender’s quicksearch (Space )
to access it.
|
Texture Paths
The game resolves texture-paths relative to two different base folders.
The first is the game’s Content/
folder (so you are able to reuse the
game’s textures),
the second is the root-folder of the mod. This is why the add-on expects the .blend file
to be in the root-folder
because it then automatically knows the location of that folder without you telling it.
When exporting .mwm files the add-on derives the correct relative texture-paths by comparing each texture’s absolute path against the root-folder of your mod and additionally to the game’s location (as configured in the add-on preferences).
Don’t use texture-files that are not inside the mod folder or the game’s
Content\ folder.
Neither Blender nor the add-on will prevent you from doing so but this will not
work when exporting .mwm files.
|
The add-on does not check if the path of a texture actually points to an existing file. But it’s easy to spot missing texture-files when you configure the 3D view to display meshes with their materials. |
Parallax
Parallax mapping is a new feature to ME that creates an illusion of depth on a flat surface. To get parallax working you will need a greyscale heightmap in the blue channel of the AddMaps file. You will also need to set the Parallax Height value in blender. This value sets the scale of the parallax effect. The second slider, Offset, is used to offset the "back plane" of the parallax. It is best to play around with these values and see the effects in game to understand what they do.
Wind
ME has an option to apply a wind animation to your models. You can see this animation on the leaves of some plants and trees in game. To use the wind animation, simple set the wind Scale and Frequency for the mesh material you want animated.
Glass Materials
Glass materials are handled specially by the game.
They have some extra settings that are not contained in an .mwm file
but are instead stored in a file called TransparentMaterials.sbc
.
It makes no sense for this add-on to support editing the content of this file
because the settings cannot be viewed in Blender, anyway.
What you get if you change a material from Normal
to Glass
are the
settings that are stored in the
.mwm file on export. For the meaning of these settings please refer to Keen’s
tutorial
on transparent materials.
Empties
Location Markers
ME uses empties to represent predefined points of interest on a model like interaction areas and
effect origins (smoke, fire, etc). The purpose of each empty is determined by its name — i.e.
detector_inventory
or detector_furnace
for example.
Volumetric Handles
Some empties only serve as location markers. Some others like the aforementioned detector_inventory
have some volume to them and you need to point your crosshair inside the volume to
interact with the empty in the game.
The size of that volume is determined by the scaling of the empty.
The add-on needs to know if an empty is a volumetric handle because it needs to scale it down in size if the option is used to create a small block version from a large block. To turn an empty into a volumetric handle use the corresponding button This will display the empty as a box with the exact size it will have in-game.
Exporting
Naming Conventions
All names that are used during export are derived from the scene name:
BlockPairName |
|
|
SubtypeId |
|
|
ModelsDir |
the chosen export-path from the scene properties |
|
Model |
|
|
Construction Model |
|
|
Level-of-Detail Model |
|
|
Icon |
|
The BlockPairName and the SubtypeId are globally visible to all parts of the game. So it’s important that you choose a sufficiently unique name for the scene to avoid naming-collisions with other mods. It’s probably also a good idea to not use spaces in your names. |
You can customize the SubtypeIds of blocks by enabling the corresponding option in the scene properties. This is primarily meant for mod authors that want to use the add-on but need their existing blocks to keep their ids to remain backwards-compatible. Otherwise there is hardly a good reason to change them.
Configuring the Export
The addon needs to know which folder models should be exported into.
You can configure this per scene via the Export Subpath
property in the scene
properties.
How the meshes of your scene are exported is configured via a custom Blender node-tree.
Initially your .blend file contains no such node-tree and your scene’s default
settings-name MwmExport
will be displayed as invalid. You can create the default settings by clicking on the
+
next to the settings-selector.
Clicking "Export scene as block" will then immediately export the scene to the chosen folder.
Holding down Alt
while clicking the button will export all the scenes in your
.blend file.
In this case each scene will use its own folder and settings.
The chosen export folder needs to be a subpath of the folder containing your .blend file. Otherwise references to your models will be calculated wrong (CubeBlocks.sbc, LODs). |
Exporting .mwm files
By default the export runs through theses steps:
-
Export the collision-meshes to a
.hkt.fbx
file -
Convert the
.hkt.fbx
file into a.hkt
file via Havok’s FBX-importer -
Run the
.hkt
file through Havok’s filter-manager to calculate and add rigid body data to it -
Repeat the following steps for the main layer and all construction and level-of-detail layers
-
Export the meshes to a
.fbx
file -
Export the info for materials and linked levels-of-detail to a
.xml
file with parameters for MwmBuilder -
Use the
.fbx
,.xml
and.hkt
files as input for MwmBuilder to produce the final .mwm file
-
The add-on logs the result of each step of the export in Blender’s
info-log .
In addition the output of external tools is logged to separate log files that are named
like the file that is
exported by the step with .log appended.
If an external tool fails for any reason or does not produce the expected file
you should consult these log-files.
|
Block Definitions
When you export .mwm files the add-on also creates a corresponding .blockdef.xml
file for each exported block.
This file contains all the information that is available in Blender and that is relevant
for a block’s <Definition>
inside your mod’s
CubeBlocks.sbc
:
<Definition>
<Id>
<SubtypeId>ExampleBlock_Large</SubtypeId>
</Id>
<Icon>Textures\Icons\ExampleBlock.dds</Icon>
<CubeSize>Large</CubeSize>
<BlockTopology>TriangleMesh</BlockTopology>
<Size x="1" y="1" z="1"/>
<ModelOffset x="0" y="0" z="0"/>
<Model>Models\ExampleBlock_Large.mwm</Model>
<BuildProgressModels>
<Model BuildPercentUpperBound="0.33" File="Models\ExampleBlock_Large_Constr1.mwm"/>
<Model BuildPercentUpperBound="0.67" File="Models\ExampleBlock_Large_Constr2.mwm"/>
<Model BuildPercentUpperBound="1.00" File="Models\ExampleBlock_Large_Constr3.mwm"/>
</BuildProgressModels>
<MountPoints>
<MountPoint Side="Left" StartX="0.30" StartY="0.00" EndX="1.00" EndY="0.40"/>
<MountPoint Side="Left" StartX="0.00" StartY="0.00" EndX="0.30" EndY="0.10"/>
...
</MountPoints>
<MirroringX>HalfY</MirroringX>
<BlockPairName>ExampleBlock</BlockPairName>
</Definition>
This definition is incomplete. It only contains the parts Blender knows about.
You have to add missing properties like <TypeId> or <Components>
yourself.
|
Updating CubeBlocks.sbc
You can use the "Update block definitions" operation to tell the add-on to take the same XML data
it writes to a .blockdef.xml
file and merge it with matching <Definition>
sections of your mod’s CubeBlocks.sbc
.
That saves you the trouble to do this by hand.
Updating CubeBlocks.sbc will only work for blocks that are already present
in the file.
The add-on searches for them by their <SubtypeId> .
|
Customizing the Export
The add-on uses a custom Blender node-tree to drive the export. The connections between the nodes of that tree describe how the objects in the scene flow through the export.
The sockets of the nodes are color-coded to quickly recognized which sockets can connect to each other. The color-coding also signals if the connection between two nodes is dysfunctional by turning the sockets dark-grey. This happens if the nodes detect that no objects would flow between them — most probably because there are no objects. If an illegal connection is detected the affected sockets will be colored bright red.
Text Nodes and Sockets
Several of the other nodes require text-input to name the files they produce. You can provide that text either directly via the corresponding white input-socket of each node or, if you want to reuse a text snippet, you can instead use a text-node and connect that to the input-socket. To avoid having to define an export node-tree for each scene all text-fields can use parameters that get substituted with information stored in the scene:
Parameter Name | Description |
---|---|
|
Contains the name of the
scene. The suffixes |
|
Normally derived from the scene-name and the cube-size but can be explicitly configured in the scene properties. |
|
Either |
|
The sequence-number of the source-socket. See the next section for details. |
Object Filters
This kind of node determines the objects that should get processed. There are several variants. They all have an object-input socket so that you can build filter chains with them. If that input socket is not connected to anything it will use all objects in the scene as input.
Layer Mask Filter
This node uses a layer mask to filter out objects that are not on the marked layers.
Object Name Filter
This filter matches objects by their name. You can either choose an exact name or switch the node to use a regular expression. You can also invert the match so only objects get included that do not match the pattern.
Group Name Filter
This filter works just like an Object Name filter, only on the names of groups the object is in.
Block Size Filter
This node has two input sockets and selects between them depending on the currently exported block-size. This is useful if you have objects in your scene that should only be exported for one block-size but not for the other:
Layer Splitter
This node adds one output-socket for every layer you select.
Each of those sockets only provides the objects from the corresponding layer.
This is useful for sequential groups of meshes like construction stages.
The node also implicitly numbers the output-sockets starting at 1
.
The number is available for text-substitution as parameter ${n}
.
Havok Converter
This kind of node produces a .hkt
file by taking the objects from its input-socket
and running them first through
Blender’s FBX exporter, then through Havok’s FBX Importer and after that through
Havok’s Standalone Filter Manager.
The node ignores objects that don’t have Rigid Body enabled on their
Physics property-tab.
|
MwmBuilder
This kind of node produces a .mwm
file by taking the objects from its input-socket
and running
them through MwmBuilder. The node uses Blender’s FBX exporter internally.
The settings for the exporter are only available in the properties section of the node-tree’s
N
side-panel.
The default settings can be used as-is to export a block to SE. If you change the settings, you can save them as a preset. There already are presets to do character and animation exports and also to restore the default block settings.
The node will also include the collision data of a Havok Converter node if it is connected to
one.
And lastly a MwmBuilder node can receive the output of other MwmBuilder nodes.
Those nodes will then serve as the level-of-detail models and
the produced .mwm
will contain references to them.
Block Definition
An export-tree can only contain a single node of this kind. The node takes the output from several other nodes to generate the block-definition for the scene. Of special note are the input-sockets for mount-points and mirroring-settings which are not consumed anywhere else in the export-tree.
Updating CubeBlocks.sbc will be disabled if the export-tree contains no node of this kind. |