Mobs X and B3D files

Wiki Top Minetest MT Worlds Bucket Game Trolltest Contact Downloads Devel Center

minetest.org minetest.io 9,000 gits CoderChat EdgyNet

---

This subject area (Mobs X and B3D files):

Mobs Mobs Devel This page Codermobs

---

Introduction

This page is for mobs developers and world hosts. It discusses Minetest mobs models with a focus on ".x" and ".b3d" files.

You should probably look at the Mobs Development page as well.

X and B3D formats 

Mob models exist in a source format, typically a ".blend" [Blender data] file, and in a published format, typically an ".x" or ".b3d" file. The source file can't be used directly in Minetest. Somebody needs to use a tool to create a published file from a model source file. The published file can then be used in Minetest.

".x" is an older ASCII format related to DirectX. The format is deprecated because it's very space inefficient. ".b3d" is a newer and preferred model format that is typically much smaller.

Where possible, these days, X published models should replaced with B3D published models.

Replacing X with B3D

Regrettably, there is no simple way to convert X to B3D that preserves animations. The best way to deal with an ".x" file is to obtain the original ".blend" source file and to create a new ".b3d" file from that.

If the ".blend" file can't be obtained, there is an alternative way to convert ".x" to ".b3d" but it's for experts:

One can convert a ".x" file to an intermediate file using -- losing the original animation -- then import that file into Blender and recreate the animation manually. After that, one can export the result to ".b3d" using joric's b3d export plugin. For Blender versions newer than 2.8, the best fork varies over time. For a list of forks and their compared progress over time, click "Insights" then "Network" of any of the root repos such as:

• https://github.com/RainWarrior/B3DExport/network
• https://github.com/joric/io_scene_b3d/network
  • Warning: joric's may not work. RainWarrior's fork has at least the following differences:
    • Avoids a later joric commit that changes the "up" axis of the model and makes the model rotated incorrectly when displayed in Minetest (or Irrlicht).
    • Strips textures from the model to avoid Minetest missing texture warnings (Removing the path(s) is ok since the Lua file will assign the texture(s) as usual, and the Minetest engine will use its own method to find the assigned texture(s) in the texture cache).

As of Blender 3.4, the best fork appears to be: https://github.com/Kippykip/B3DExport

To convert ".x" to an intermediate file, one can use Poikilos's fork of b3view. Press stop and set frame to 0 first.

An intermediate file means a file that can be used to make something else. In this case, it is a file without animations, generally an OBJ file. After exporting frame 0 using Poikilos' b3d fork as described above, to Blender import the file (Click "File", "Import", "Wavefront (OBJ)") then animate the object manually. Tutorials can be found on Poikilos' free books site: https://expertmultimedia.com or various videos and sites online.

In the case of restoring the animations of a previously-animated mob, one must proceed as follows:

• Click the "Output Properties" (printer picture button) side tab on the right. In this panel, change the following two settings:
  • Change Blender's "Frame Start" setting to 1 to use the same numbering as Minetest (Lua lists start at 1, and Minetest animations start at 1)
  • Change "frame rate" to the "speed" indicated in the Lua file (However, See the "Optimization" section below).
• Each of the animations (walk, run, stand, etc.) must start and end on the same keyframes found in the mob's Lua file. These keyframes in the old file (such as X file) can be visually previewed for reference by opening the old file in Poikilos' b3view fork (This fork displays the frame number and allows using arrow keys or typing to navigate to any part of the animation).

Optimization

Many upstream X or even B3D files are unnecessarily large due to a high frame rate. Because of a shortage of knowledgeable 3D animators in Minetest, there are few people who understand that Irrlicht does "tweening" and that you only need keyframes to achieve 60fps or more. For example, if a file is at 12 fps, the animations can still run at 60fps smoothly due to "in between" frames generated by Irrlicht in realtime. This is called "tweening". In many cases you reduce the frame rate to half or less to reduce space by a similar factor! In that case, change the Lua file's "speed" to half, then half all of the start and end frames and line up the Blender animations you created. This requires detailed work and is only recommended if you are very comfortable with Blender. This can help with server performance. Files less than 1 MB may already seem small, but this solution is applicable to countries where people cannot afford a recent computer or for people using a Raspberry Pi or similar device. The solution can also apply to any server where users are added to the server rapidly, especially when there are several needlessly large files that add up. Fast animations with arcing motions may need to be at a higher frame rate, but most animations do not. You can even set a different "speed" for different animation sequence in the same animated 3D file. For example, the attack animation sequence can be 24 fps, but the "stand" animation sequence can be 4fps and look smooth due to 60fps or higher tweening by Irrlicht! Such a low framerate will only look correct for simplistic movements such as the "stand" or idle animation. An attack animation at 4fps will still be tweened, but the result is that the weapon will swing in straight lines instead of an arc since tweening only provides new frames that have linear movement from one frame to the next. In other words, every frame is used as a "keyframe" in Irrlicht, even if there are only a few keyframes in Blender where Blender does linear, non-linear or smooth tweening before baking the frames to the B3D file that Irrlicht will use.

Walk Cycles

To make realistic walk (or run) animations, the feet must move at a steady rate that matches their actual speed (In Mobs Redo this is dubbed "velocity", whereas "speed" refers tot the animation playback rate) so they don't appear to be "moonwalk" (foot sliding regardless of direction). A detailed article by Poikilos is at: Why Game Characters Moonwalk: How to Prevent Foot Sliding

SAM Viewer

For working with player models, which are similar to mobs models, there is a more advanced viewer that can simulate Lua values for testing wield item settings and other settings:

SAM-Viewer

This is by stujones11, long disappeared, and may not work. There is a Poikilos fork that is only a copy of the upstream repo for now (Feb 2020) but may be updated later.