The half head, which doubles up in game, is a vertex animation - it has a number of frames to move facial features to create expressions (facial variations). A whole head static mesh will only have one frame when the game engine is expecting several.I wonder though, why are the actual head meshes all cut in half whereas attempting to use a full head mesh for the head gives compilation errors?
I’ve never exported vertex animations out of OpenBRF. However, Mtarini suggests there may be problems with Blender etc maintaining the vertex order and possible work arounds:I am facing problems with this as well, im using openBrf to export the files to md3 format, and then edit and export them using https://github.com/neumond/blender-md3, with blender 2.79. But even if i dont make any changes, at the moment of re-importing the md3 file, only the last vertex animation frame is applied to the sliders in-game, even when they show up in openBrf. The only difference is that the box "tangent dirs" is not checked. If someone knows why this happens or if i'm using the wrong exporter pls let me know
Vertex animations with openBRF
What a BRF Vertex animation is:
A vertex animation is just a sequence of meshes, one mesh per frame. Each frame is also associated to a timing. But, here's the catch, each frame only redefines positions and normals. All frames share the same: triangles (which triangle connects which vertices), texture coords, rigging (in case mesh is also rigged), etc (this also means that the frames are bound to have the same number of vertices/faces).
Note that the frames must be considered just keyframes. The game is "free" to interpolate between two frames of the vertex animation to get smoother animations (it will exploit that, for example when it animates bows).
How are they used in M&B:
For many things!
... and maybe other things too.
- animated icons on the map (in this case the 1st frame is unused, the second is the stance pose, the rest is the walking sequence)
- weapons animations (like the bow string).
- armours: the 1st frame is unused, the second frame is the male version, the third the female version
- quivers and the like: each frame represent a different number of arrows left
- shields: a frame for when they are fastened around the arm, a frame when the belt is loose
- scabbards: first frame is with sheathed weapon, second frame without it
- hands/gloves: first frame open, second half-closed, third closed in a fist/grab
- customizable heads: frame 0 is the base head, each frame is the effect of a "slider", like "eye-to-eye distance".
How to make your own in OpenBrf:
UPDATE: since ver 0.38 (Aug 2010) you can also export/import vertex animations as MD3 files (the format introduced by Quake3).
The other option, descried in the following, is still available:
You stack them frame by frame. So, typically, you export a frame, edit it, reimport it and attach it to your animation.
The Cut and paste way: with ctrl-alt-x, ctrl-alt-c, ctrl-alt-v (as you can see in the edit menu) you perform cut and paste operations that refers to individual frames (and apply to the currently selected frame). So you can import a mesh, and stack it to your animaton by cut and paste. You can also redefine frame order, duplicate frames, etc.
Direct frame import and attach: when your frame is in an external file, as a shortcut, you can also import a static mesh directly as an additional frame of the currently selected mesh (menu "import").
Remember to edit manually the times (in the "data" box) of each frame, at the end of the process.
The problem with frame by frame stacking, and possible solutions:
What makes the process messy (if you tried in other occasions, like in OpenBRF you know), is that when you assemble frames you are assuming that not only the vertex number, but even their internal order has been kept the same by all import/export operations. Otherwise... say vertex N.412 is on the head in frame 1, but on the foot in frame 2: then it kills everything! Textures, triangles, interpolations... result is a mess. That's because, remember?, triangles/text-coords/etc are shared by all frames. So, if you have a triangle connection vertex N.412, N.51 and 413 together, that applies to all frames.
In OpenBRF you have two options to merge a frames into an animation.
Option 1: you pray that the vertex order is kept unmodified by your mesh import/exports (openBrf will comply, but who knows what, say, Blender or Wings3D will do). This is the "old way". Works, sometimes.
Option 2: you resort to use texture coordinates as unique identifiers of vertices. You just assign to each vertex of your mesh an unique u-v point in texture space. (((Note that sometime you want different points to share the same texture coords: for example, if you have a quiver, each arrow is a copy of each other arrow including uv coords, and if you have a symmetric something, the left half will use the same texture coords of the right half. In these cases, just displace the text each vertex by a little tiny bit in your mesh editor. Half a fraction of a texel (a texture pixel); it won't make any practical difference, but it will be enough for OpenBrf to tell vertices apart.))) Once your texture coords identify the vertices in frame 1, don't touch them anymore. Feel free to edit mesh 3D shape for all other frames!
You select which one of the above is your favourite option, 1 or 2, in the option menu ("Option" => "On assemble vertex animation").
Note that the system is somewhat robust: if Option 1 fails (e.g. different number of vertices) it will fallback to option 2 automatically. If Option 2 fails (e.g. same texture coords for different points), it will fallback to option 1 (for that vertex only).
Let me know how your experiments go!!!
There was the problem, thank you, i missed the step of manually set the times of each frame in openBrf, they were all on the same frame.I’ve never exported virtual animations out of OpenBRF. However, Mtarini suggests there may be problems with Blender etc maintaining the vertex order and possible work arounds:
Ah! Next occasion times are the problem, try copying the native head and pasting its timings onto yours in OpenBRF - should save manually seting each frame.There was the problem, thank you, i missed the step of manually set the times of each frame in openBrf, they were all on the same frame.