Download link and main info! [latest ver 0.0.82e -- 19 Jun 2016]

Users who are viewing this thread

I have a problem, when I import other models from other brf to a new brf, the models are so brighter than native-original. How can I fix it?

mb_warband2010-08-0109-31-04-09.jpg
 
Hey, in the very first screen of this program it shows something in "skin" and "skeleton" menus, while mine freshly installed prog has nothing, and I want to try out some of my items in motion. What should I do?
 
Halvarez:

havarez said:
Maybe somebody knows how to attach head(not helmet) model to reference data.

Usually the model of the face features only on half of it, right?
The way I do it is:
- duplicate the head (find it, select it, ctrl+C, ctrl+V).
- Right click on second copy, "mirror".
- select both copies (hold shift for multiple selections), right click, "Combine meshes".
  Now you have a full head.
- select combined mesh, right click, "add to reference skin" (mount on "head" when prompted)
  (Or, instead of combining the two halves, just add them both "to reference skin" separately.)
- Feel free to close your brf file without saving the above changes
  (OpenBRF will save the mesh among its reference meshes)

-----------------------------------

Gothic Knight (shield problems):
oh now I see it. It is just the usual problem of vertex animations.

The problem is that in a vertex animation all frames must have the same vertices, in the same order, and the same connectivity (i.e. the same triangles connecting them).
[[Tech note: that's because each frames just redefines vertex positions and normals, while triangles, u.v. coords, etc are shared by all frames.]]

Even if you just did some basic editing, like lowering a part of the mesh, this can happen: the external 3D application (e.g. Wings3D) will sometimes change the internal vertex ordering, and this even if you just import the obj and export it right away.

Solution 1: make sure that in your original mesh each vertex has a separate u-v texture position, shared by all frames.  The idea is to make it possible for OpenBRF to tell which vertex is which by looking at their u-v positions. 
That is: whenever any two parts of the mesh use the same part of the texture, just jitter them a little in u-v space, to make positions different, if slightly. Note: even very small changes in u-v space will be enough, so small that it won't make any visible difference.

Then, you just edit the xyz positions the way you like to make all frames (e.g. the different positions of the belt of the shield), just make sure leaving u-v coords alone.

Now, back to OpenBRF, ask it to:
"Settings"->"On Assemble Vertex animations" -> "Trust texture positions to be unique".
And try assembling your animation, e.g. by importing all the frames (or by cutting and pasting separate frames individually, see under "Edit" menu).
If you didn't leave ambigiuities in the u-v positions, it should work.


Alternative solution: hope that Wings3D or Blender or whatever you are using, will consistently export OBJs, always in the same way (with the same internal vertex ordering).
Export OBJ for all frames (not just the one you changed, all of them).
Then, in OpenBRF, set
"Settings"->"On Assemble Vertex animations" -> "Trust vertex ordering to be the same".
and proceed to assemble the so called "animation" of the shield from scratch, importing all frames including the first, all from equally exported OBJs (import the first as a static mesh then attach the others importing them as "vertex animation frames").
But, this works only assuming that the 3D application you are using is self-consistent in the way it export stuff.

EDIT!: To be sure, you'd better also make sure that OpenBRF is set with "Settings" -> "On Import Meshes" -> "Do Nothing", 'cos otherwise it *might* change the vertex count and by merging redundant vertices (if there are any) when you import the first frame, thus screwing up the vertex animation.


Let me know how it went!

-----------------------------------
Damn:

Damn said:
Hey, in the very first screen of this program it shows something in "skin" and "skeleton" menus, while mine freshly installed prog has nothing, and I want to try out some of my items in motion. What should I do?

Like, a rigged armour? It should be possible to just select which animation to use in the View tab.

If you don't see that option in the view bar in the middle panel (it should be at its bottom), it could be for any of the following reasons:

A- OpenBRF cannot find its "reference" skeletons and animations, which are kept in a "reference.brf" file sitting next to the exe. Is it there?
(to check this, you can edit that data with "Settings"->"Edit reference data", then you can "Settings"->"Stop editing reference data" at any time).
(you can also add animations to the set used)

B- the selected mesh is not rigged (if it is, you can select "rigging color", in the "View" box in the center, else it is grayed)

C- the mesh is rigged to a number of bones too large for any of the skeletons/animations in reference data (human skeleton uses 20 bones)



 
Didn't go well. Another piece of info is that I usually don't move the strap to a new position, but I do separate the strap from an older copy of the model and then use that one. Also...I seem to be getting 2k vertices when I import sometimes.
59209437.jpg
 
Gothic Knight said:
Didn't go well. Another piece of info is that I usually [...] do separate the strap from an older copy of the model and then use that one.

ahh... I'm afraid that's the wrong approach to do "vertex animations" in Mount and blade. In M&B, each frames of the "animation" has exactly the same number of vertices, the same triangles connecting them, the same texture coordinates, etc.
Repeat: only vertex positions/normals are redefined per frame.

So you need to make your shield so that each frame is obtained from the basic frame just by moving vertices. That's the way it is.

You can use tricks.
If you want a sub-piece to appear only in the "equipped" frame of the shield "animation", you still need to have all the vertices and faces of that piece in the other frames, but you can move vertex position to make it really small and maybe inside the body of the shield, so that it disappears.

Whatever you do, don't hope to design two diffrent frames independently (adding and removing polygons) and get it to work in a M&B vertex animation. Repeat: only vertex positions (and normals) can change from a frame to the next.

Repeat 2: it is not enough that the number of vertices/faces of all the frames is the same. They must be the same faces connecting the same vertices in all frames, using the same text coord. So the only way to do that is to prepare a base frame first, then obtain the other frames ONLY by displacing vertices. Even then, care must be taken (see my last post) so that OpenBRF understands which vertex of frame A is which vertex of frame B.



Sorry for this limit, but it is a M&B issue, not OpenBRF. The source of the problem is that M&B is using "vertex animations", something designed for icon movement and also ideal for face customization and "hand animations" and "bow animations", also for other things, for which they are not as ideal. Namely, for defining array" of meshes, like the so called "quiver animations", "shield animations", and "weapon scabbard animations". This is a cool idea but has drawbacks, like the ones you are experiencing.

Gothic Knight said:
Also...I seem to be getting 2k vertices when I import sometimes.

About this, see the "EDIT!" part of my last post.
 
Well, it could be Openbrf's fault, due to the fact that I put it as do nothing and import the objs and the verts number as 1800-2000 for some reason. The difference of verts could mess up my animations as well as the bugged imports.
75245211.jpg

95494279.jpg

But nevermind, I'll fix it on my own eventually since your willingless to aid me has somewhat dissipated in the duration of 1 post.
 
Update! From the 1st page...

ver 0.0.38 (6 Aug 2010): 
- added import/export of vertex animations as MD3 files ("Quake" files)

Thanks to Swyter for suggesting that.

So, you can still compose your vertex animations staking frame by frame, (either importing each frame as a static mesh, or cutting and pasting separate frames, that is, by copying a mesh and pasting it as a separate frame, see "Edit" menu). BUT now you can also make the entire animation somewhere else and export it as a MD3 file, (using e.g. 3D studio Max), and import it in BrfEdit. You can also export existing BRF vertex animations into new MD3 files.

MD3 files are used by quake and there are exporters/importers around.

Note that MD3 vertex animation do not have a "timing" value associated to their frames. That info is stored in the frame "names" instead, using name like for example "T1" "T100" etc ("T" followed by the msecs). If you name your MD3 frames accordingly, OpenBrf will use that value (else, it uses default timings).

You can read this old post of mine for more info about vertex animations in  M&B and OpenBrf (what they are used for, etc).



---------------------

@Gothic: I think you might have missed this part, above: <<To be sure, you'd better also make sure that OpenBRF is set with "Settings" -> "On Import Meshes" -> "Do Nothing", 'cos otherwise it *might* change the vertex count and by merging redundant vertices (if there are any) when you import the first frame, thus screwing up the vertex animation.>>
That said, I'm afraid that the only way to be sure to get animations right is: make the first frame, and then make subsequent frames as vertex-position modification of that first frame only.

 
Tested 0.38.  Fails with a runtime error when I attempt to open many BRF files.

Oh, shi-

I've deleted 0.37, and I didn't keep a backup!  Aaaaaaaah!

<shakes head>

Does anybody still have 0.37 around?  I can't use this version at all, it crashes when I try to open most files.  I can't believe I just beta-tested without a backup, lol.

OK, I've figured out what causes the bug.  Any files set as a "Warband BRF" cause a crash now.

Tested:  this also occurs with Native files that are in the Warband BRF format.

Please, somebody, post a link to 0.37.  Until Mtarini has time to fix, I am pretty well screwed.  I just need OpenBRF.exe, the other stuff hasn't changed.

Tested s'more (since, well, my evening of modding is hosed, other than coding):  saving as Warband BRF does not cause a crash, and the BRF isn't being corrupted.  So it's the loading process.
 
oops!
Will fix this is a minute...

Edit: ok done. Re-download. I was experimenting with a few newer warband files apparently following a slightly different mesh format, then forgot to remove the changes.

@xenoargh: thanks for reporting this! (but no need to panic).
@everybody: afraid you'll have to re-download.
 
While using the 'recompute normals' function, is there any way to get the texture seams to become soft edges instead of hard?  It would save me redoing a whole ton of smoothing groups in 3dsmax if there is (*fingers crossed*).

Either way, thanks very much for all the time and effort you've put into this, mtarini  :mrgreen: 
 
Thank you, Marco! Now making face keys is trivial. For those who want to know more about this. I'll post some useful links with info and working imp/exporters...


TUTORIAL:
How to make Character Face Keys, by Thorgrim:
http://forums.taleworlds.com/index.php?topic=15707.0
Basically they're the same steps with the exception of exporting the frames as MD3, forget the VTA.

MD3 IMPORTERS:
» 3ds Max All Versions [Max Script]*
» Blender Universal Imp/Exp All Versions [SVN repository, look for it]


MD3 EXPORTERS:
» 3ds Max 2010 x86*
» 3ds Max 2010 x64
» Blender Universal Imp/Exp All Versions [SVN repository, look for it]
» Blender 2.43+ [Tutorial Included]


_________
* Tested by me.
 
Back
Top Bottom