FAQ and Troubleshooting

Users who are viewing this thread

mtarini

Sergeant Knight
FAQ & troubleshooting:
Your question is not answered here? Post it!

BASIC USAGE:
to access most functions you must select the object you want to act on (e.g. a mesh), clicking it on the list at the left, and then: either right click on it; or, use the "selected" menu option. Then select the command from the menu.

You can also multiple select objects, by Shift- / Ctrl-clicking on them.
That way you can perform an action on all of them at once (via the context menu, as normal).


BASICS:

What is OpenBRF and what are BRF files?
It is a tool to edit and preview the content of BRF files.
BRF files are a file format used by Mount and Blade game series to hold most game graphical content: meshes, materials, animations, collision boxes, skeletons for animations, etc.
With OpenBRF, you can preview them, import/export them in an array of formats (so that you can edit them in external applications), as well as edit them.
This whould be useful to build game MODs (game modules).

What is the OpenBRF icon supposed to represent?
openBrf_sm.png

The icon was kindly (and skillfully) made by [amade], following a request of mine. Its concept refers to old paper dolls toys (usually for little ladies), where you had to cut out dresses from a sheet of paper, and tie them to cut-out human figurines, by folding flaps. This is intended to jokingly represent one typical activity of a MODder: to design and model outfits.



DOING STUFF:

How do I do stuff?
Many things are in context menus. Select one or more items from the list on the left, then either right-click on them or open the [Selected] menu, then pick your option.

How do I export a mesh/an animation/a skeleton/etc?
Read the answer above.

How to paint vertex-colors on the mesh?
[background: meshes in M&B can have a color specified in each vertex, which is typically modulated with the color specified in the texture]

OpenBRF does not have an embedded interactive vertex painter (at least, not yet). It can paint the mesh for you with an uniform color of your choice, and it can also compute "ambient occlusion" on a mesh (i.e. make the parts that are hidden to light progressively darker, and store it as per-vertex color), or tune Hue, Saturation and Brightness, or other things like that.

For any other use of vertex color, as well as to retouch the results, you'll have to paint the mesh in an external application, and then import it on OpenBRF. Doing that, you need use a file format that encompasses color per vertex, like ".ply".

For example, 3D Studio Max can be used as an external vertex painter. You can use [this] plugin, developed by [Yoshiboy] for this very purpose, to make Blender export ply smoothly. Another vertex painter you can consider to use is the one embedded in MeshLab.

Can I add new animations and skeletons in my mod?
Yes, within certain limits. For animations, see this tutorial,  (by [cdvader]), or this one, (by [dreamterror]). For skeletons, this one,  (by [cdvader]).

How do I move meshes/materials/etc into one BRF file from another BRF file?
Way 1: open the first BRF file, select and copy (ctrl-C) the object(s), open the other BRF file and paste (ctrl-V). Way 2: you can also "import" a brf file into the currently open file, if you want to take in all of its content (with [import]=>[everything from a BRF]).

I see a tool to "recompute tangent directions". What are they used for?
Tangent directions are defined all over the mesh (pretty much as normals) and are needed (at game execution time) to render most kinds of bumpmaps. If you import a mesh, it won't have them defined over the game will have to compute them. In openBRF, you can compute and store them instead, for the game to use. Keep in mind that tangent directions cannot be saved in M&B 1.x mesh format (only in WB or WFaS). If a mesh does not use bumpmapping, it does not require tangent dirs (there is a tool to discard them if they are there)

TROUBLESHOOTING:

My bumpmapped objects are shown black (if I activate bumbmapping)
If all bumbmapped objects are shown black (including native one), then it must be a problem with OpenGL. Try updating the graphic card drivers.

If only a few custom object do that, it could be that you saved the bumpmap in the wrong format. "Blue" bumpmaps must be saved with DXT1 compression, as they do not need the alpha channel. "Green" bumpmaps must be saved with DXT3 or DXT5.
That way, your mod will be optimized (in term of texture space and memory), plus OpenBRF will be able to tell which bumpmap is which kind and will display them correctly.

[background: Green and Blue bumpmaps are two different kinds of bumpmaps M&B uses. I'm calling them by the general color they appear when you look at them as color images. Green is more expensive in term of memory usage (and even GPU computations) but are also more accurate].

Why does it show a white-blue checkerboard instead of my texture?
The checkerboard is a replacement for when, due to problem of any nature, OpenBrf could not load the texture.

(does it happen in native mod too? If so, the solution for you is probably in the last paragraph of this "Spolier").

There are two ways to identify what the problem was:

1- Ask OpenBRF itself:
    under "settings", a "Why the checkerboard pattern?" option appears when the checkerboard is on.
    That helps you diagnose what the problem is.

OR

2- Manually track the error:
    - Start from a mesh giving you a problem.
    - Click on the link to the "material" (inside the Data panel, in the middle). That brings you to the material.
    - Click on the link to the "texture". That brings you to the texture object.
    - Click on the "open it" button. That brings you to the texture .dds file, in file explorer.
    - Can you open that file with any other application?

If a passage is broken, you'll find out where the problem is.

For example, if when you click in the material it doesn't take you to the material , it means that the problem is that your mesh is using a material which is not present anywhere in the mod (for example, due to spelling errors, or you forgot to add the brf file with the material inside "module.ini").

If the problem is nowhere else, then it could be that your system is lacking full API support for OpenGL. Usually (in all cases I've seen) updating the drivers of the graphic card helps. Go to the card vendor site (e.g. NVidia or ATI) and look for a driver update there.

My OBJ files appear flipped when I import them!
Like, weapons in left hands? Import is correct, but your OBJ files contains a flipped mesh.  Happens when it was exported either by pre-0.0.18 versions of OpenBRF or by BBRedit. Whatever the reason, you can use the "mirror" tool to flip it back (a nuisance, but from now on you should see the same orientation: in the game, in OpenBRF, and in the external applications like blender which read exported OBJs).

VIEWING STUFF:

How can I see several meshes combined, like all the parts of a castle together?
You can MULTIPLE SELECT stuff, just as you do in the file system: by Shift+clicking or Ctrl+clicking on the object list. Multiple selections can be visualized is three different modes: side-to-side (for display and comparison), combined into one, or [auto] (the default). Switch this with the small buttons at the bottom. In [Auto] mode, the selected meshes are grouped according to names: the ones with a matching name (up to the "dot") are displayed together.  Note that you can double click on the 3D window to select the meshes in the corresponding box.

ALSO NOTE: commands operating on multiple items (like "combine meshes", "concatenate animations", or "group rename") are available (by right-clicking on the selection) when multiple things are selected!

What do all those flags and numbers in Material, Shader and Texture tab mean, exactly?
This is guesswork, but I've put in OpenBRF all the info available. If you have more info or corrections, it would be great if you posted them at the OpenBRF [flag thread]. See also this tutorial (by [xenoargh]) about this.

What do the bold/colors mean, in the left-most list of names?
Bold blue means that that mesh/texture/shader/skeleton/etc is being used by your module, judging from its txt files.
Either directly or indirectly (right click on it and see "used by" to find out).
Gray means that that thing it is not used (or is only used by other objects, e.g. a material by a mesh, which are, in turn, not used). Lighter gray means that does not seem to be used at all (and can be removed).

Colors? What colors?
Just press F3 to make OpenBrf scan the txt file and color-code the object lists (or [Module]->[Scan module for usages]). Naturally, this only applies if the current BRF file is part of the current module, i.e. if it is listed in module.ini.

SYSTEM RELATED:

How to install?
no installer required. Just unzip in any folder and run!

How can I make OpenBRF the predefined application for my BRF files?
in window explorer, right click on any brf file, "open with...", select "custom application...", "browse" for where openBrf.exe is, select it, check "always use this program to open this kind of file".  Now OpenBRF should open when you double click a BRF file.
However, there seems to be occasional, erratic problems with Window's file association. This is a window issue rather than an OpenBRF one. If your Windows refuses to comply, it was reported (by [Mandible]) that renaming the openbrf ".exe" file to something else can help.
 
A very strange thing happened with this tool. The first time I used it, it worked just fine, but every subsequent time I tried to open it, it said it was missing the "mingwm10.dll" file, even though it's listed as one of the files in the program folder. I tried reinstalling it, and it worked fine the first time, once again, but every subsequent time it displays that same error. Any ideas why?
 
Never encountered this...
That DLL is in the zip and should sit next to OpenBrf.exe. Is that still there?

You are not executing it from the zip, are you? (You need first unzip it inside a folder of your choice, then run it from that folder.)

If the DLL actually disappeared, I'll try a wild guess:
maybe it's your Windows being hyper-protective about "his" DLLs, and auto-reverting them (meaning: deleting the ones which you copied from the zip).
That might the case, if you are picked a folder which Windows consider his own, like (maybe) sub-folders inside "Program Files".
Try using another folder (e.g. C:\openBRF, or anything). Let us know!



 
No, it's still inside the folder, right above the .exe file. But thanks... I didn't think of that before. I'll try it and see how it goes!
 
Hey, I'm having this sudden problem with openBrf, first two times I ran it all went well, but now it just declares;
LoadLibrary failed with error 998: Invalid access to memory location.
I have searched everywhere a solution to this and nothing has come up. It doesn't help where I unzip the folder, it just doens't cooperate anymore.
 
( http://forums.taleworlds.com/index.php?topic=125282.0 ) I've followed the instructions, but everything is good to step III. OpenBrf : when I open openbrf  no error I dont know what  is this ? :mad:, help me


microsoft visual c++ runtime libary


this application has requestedthe runtime to terminate it in an unusual way.
please contact the application's support team for more information
:???:  :???:

lol  :mrgreen:  :mrgreen:  sorry my english bad
 
Is there any way to get OpenBRF to actually recognize customFeminizer.morpher files? It seems it can generate them but not read them which does defeat the purpose a bit.



EDIT: FIXED in 0.0.82 -- mtarini
 
Ruthven said:
Is there any way to get OpenBRF to actually recognize customFeminizer.morpher files? It seems it can generate them but not read them which does defeat the purpose a bit.

Ok, my bad. My very bad.
This is something I accidentally broke in one update or another :sad:

What happened:

I really made a mess this time.
Unfortunately, I lost the last sources (0.0.80) when my computer was stolen, silly me, and the latest surviving source I have (0.0.79) lacks quite a bit of work. Eventually I might go over it and replicate all the changes I made from 0.079 to 0.0.80, but some of them where quite significant and I don't particularly feel like it :sad:.
I'm not sure which version introduced the bug.

tl;dr: that's a bug, and it's not likely to be fixed anytime soon.

A simple work around:

One option is to do whatever you need to do with the auto-feminizer with an older version of OpenBRF, and then revert to the latest version for anything else.
You'll need to get an older version of OpenBRF.
As I said, I'm not sure which version introduced the bug, so this takes some trial and error. If you do find which is the latest working version, please report that!



A more laborious, but probably better, work around:

(1) First, make sure OpenBRF can write your custom femininizer data.
OpenBRF tries to write it in its own directory.
Therefore, if OpenBRF is inside "Program Files" or some protected folder of that sort, you'll need to right click on OpenBRF, then "run it as administrator".
If openBRF is inside a normal, custom folder, then there should be no need for this step.

(2) Create the custom femininization file, as usual, if you didn't do this before
(look under [settings]=>[On Armour auto-femininization] ).
If everything is fine, you'll find some file called
Code:
customFemininizer.morpher
in the same folder where
Code:
openBrf.exe
is.
But, OpenBRF will not be able to find it there.

(3) Now, for the UGLY part.
Say
Code:
OpenBRF.exe
is found inside folder:
Code:
C:\some_folder\openBrf
It will mistakenly look for the custom feminimization file here:
Code:
C:\some_folder\openBrfcustomFemininizer.morpher
(instead of:
Code:
C:\some_folder\openBrf[b][color=red]\[/color][/b]customFemininizer.morpher
 
note the missing slash).
So, in this example, you'll need to manually rename the file from
Code:
customFemininizer.morpher
to
Code:
[color=red]openBrf[/color]customFemininizer.morpher
and then move it in the parent folder, i.e.:
Code:
C:\some_folder\

(4) now you can ask openBRF again to use the custom settings:
    [Settings]=>[On Armour auto-femininization] => [Use custom settings ]
And it will find it and work (hopefully). It should work on any following run, from now on.
Unfortunately, if you create another custom setting, you'll need to redo step 3 above.

Sorry for the inconvenience, and BTW thanks for reporting the bug.

Let me know how it goes!
 
:lol: I love stuff like this. Brilliant workaround. It does load now but the feminized frames are always bigger than the original (looks like the feminizer is working perfectly fine only in reverse.) I'll try some old versions of openBRF and see if it works.

Edit: ah, here's a quote from the bug reports thread:
phlpp said:
OpenBRF will generate but not Load a customFemininizer.morpher. I have the latest version 0.0.80e, and I'm running windows 8.1. I compared the contents of the customFemininizer.morpher files in my openBRF directory that I successfully generate when i do [Settings] -> [On armour auto-feminization] -> [Learn custom setting from selected meshes] with the the femininizer.morpher in the source code and the format of the files is identical (with slightly different values of course). Then i tried old versions starting with 0.0.77. That one and 0.0.78 could both generate and read custom feminizer morphers, but when I actually used them, the result was screwy and always made the feminine morph larger than the masculine morph. 0.0.79 and above is when it stopped loading but continued generating

So the problem was there even in 0.0.77.
 
Oh my. It seems I was on a bug galore when I retouched that morpher thing.

[checks the code]

Yes, correct: I'm swapping masculine and feminine during the "learning" phase of custom feminization.

Ok, I would say /custom/ femininization is officially broken in latest versions (default one works).

BUT, there is an even funnier workaround, if you are willing to do that.

Here:

Background: unfortunately,  M&B (1.011) and WarBand don't agree on which frame is Male and Female. So openBRF has to understand which version we are using in order to decide which is which
(my guess is that I made this mess when I tried to make OpenBRF comply with WarBand and not only with old Mount&Blade -- or maybe viceversa).

This means that if you trick OpenBrf that you are using mount&blande and not Warband, then this should reverse the bug, and it should "learn" the femininzation correclly, .

So, here's how to get your custom femininzation file,
(assuming you are using warband).

(1) rename the warband executable:
      from
Code:
mb_warband.exe
to
Code:
mount&blade.exe
 
      (use exactly that name)

(2) load (or reload) your BRF file, the one with the armor.
    Make sure it is inside <warband_path>/Modules/<some_module>/Resource/<some_file>
    "commonRes" files won't work.
    Now openBRF should think to be in "mount&blade mode", not "warband mode".

(3) Check that this is actually the case, by doing this:
    select any armour with the feminized frame already, and attempt to "[add feminine frame]" to it.
    If should give you this message:
    "Warning: mesh <whatever> has already a feminine frame 0. Overwrite it?"
    (feel free to answer "No").
    If it says: frame 1 instead, it means we failed, we are still in WB mode. Oops.
    (btw that frame number is actually incorrectly reported, but it doesn't matter).

(4) Now make it learn your custom femininization from your own models, see two posts above.
      Follow all steps in that post:
      i.e.: make your custom file, rename it and move it manually.
      Maybe check the creation date of the file, to make sure that it is a new file (just in case).

(5) Now rename the executable back (reverse step 1). And, reopen any BRF file.
    Check: try step 3 again, make sure that now it reads "1" again.
    Welcome back to Warband mode.

    Note: you need to be in Warband mode, as normal, to apply the femininzation.
    Fake M&B mode is only needed to counter the bug when "learning" the custom feminizer.

(6) From now on, you should (hopefully) be able to feminize armours at will your own way.
    Maybe. Unless there is something else.
    Well, if it works, I'd say you earned that:
    it is only marginally less labor-intensive than modelling feminine armours manually :grin: :grin:


If you try this, let me know how it goes.
 
Which version are you using?
(hit F1, or [Settings]=>[About] to find out)

Latest is 0.0.81b.

Unless you are running a very old version, before the edit button was added (can't remember which one was it -- edit: it was ver. 0.0.64, dated 9 Jun 2011), then that is a really mysterious bug.
 
This probably isn't a 'Frequently Asked Question', but well:
I need to take pictures of items using openBRF. Some of those items are heraldic(Tableau shields from CommonRes), so they don't show anything where the banners are supposed to go. Is there any way to set some banner in that place so pictures look decent?

Thanks for any help in advance =)
 
What an interesting little question.

The short answer is no.

This is the reason. The banner system in game is done by instructing the Engine to perform a rendering OVER the shield/armor texture (a classic CG technique sometime referred to as "render to texture"). This rendering paints the flag colors over the object texture. I'm not familiar with the details, but the modding system can direct the process: the mod can specify which part of which texture is rendered on (copyed over) which part of which other texture, resulting in different flag logos being applied over the shield. The alpha channel (associated to the texture of the "naked" shield) does the rest, i.e. the alpha blend results in certain parts of the object texture retain its original color (the unpainted parts), and other parts be overwritten by the flag color.

None of that can be replicated by OpenBRF.

That said, if you take it as a challenge, you can hijack a bunch if unrelated mechanisms of OpenBRF and mimic the results of this process. Inspired by your question, I just tried that, for fun, and I managed.

So the long answer is:

Yes, you can get a similar result, but be warned:
(a) it's a bit long to do, and it is probably not worth the hassle, for just a preview
(b) there's no guarantees that it will look exactly like in game, because manual fiddling of a few parameters is required (in step 4 below). Maybe this can be avoided if someone more knowledgeable of the M&B tableau system provides some information about to pick parameters (copying them from the module system).

Ok, say you want to preview a Tableau-ed shield:

(1) duplicate it, duplicate its material, and duplicate [banners_b] material, the one with the textures for the flags (or any other banner material, pick one).
You will mess with these three objects, so better keep them separated, and leave the original untouched. Maybe rename them or put them all in a separate BRF file.

(2) take the Shield and [Split it in connected components].
This way, you will separate the piece which needs be tableau-ized from the rest, the parts to be left alone.

(3) take the copy of the "to be painted part", make it use the Banner material.
You will see a patchwork of banners over it.
You can discard the other little parts: you will need only the complete shield, and this one part.

(4) Now, you want to enlarge the texture on it, so that only one banner covers it all instead of several.
Select the part to be painted, and "Transform texture coords":
Scale the U by 30% and the V by 15%
(or something, chose how much to crop it, as long as U is twice as V, because the original shield texture had a 2:1 format, the new banner texture is 1:1),
then translate them so to "frame" your favourite banner of the lot.
Fiddle with the numbers. For example, for me, U +0.25 and V +0.42 works.
The "shield_painted" should look like you wanted it to, displaying one logo on it.
Make sure the aspect ratio is correct, i.e. that the logo is not squeezed, and that it is nicely centered where you want it to be.

(5) Now you need to change the Flags of both materials.

You want the other material (not the banner one, the one with the wooded and iron parts)
to be painted OVER the rest, so it must be painted last.
So put Render Order to the top value, +7.
You also want it to be blended, so that it's white parts will be transparent and you'll see the logo
through them. So make sure Transparency is set to "Blend"

(6) Finally, you want the painted piece of the shield to "give way" to the other object, so pick the banner material, edit its flags and select "no Z-write". This makes it so that the "wood and iron" parts of the shield will be actually drawn and not be discarded by the depth test (naturally, they are at the same depth as the painted shield, because it is the same mesh).

(technical note: it would be enough, and actually sounder, to just make the depth test to accept equality values, but there is no flag specifying that and openBRF, by immutable default, uses *strict* inequality for the depth test)

(7) now select both the complete shield and the painted part, make sure they are seen together and not in separate windows  (view mode at the bottom), and this should to the trick.
 
mtarini said:
What an interesting little question.

The short answer is no.

This is the reason. The banner system in game is done by instructing the Engine to perform a rendering OVER the shield/armor texture (a classic CG technique sometime referred to as "render to texture"). This rendering paints the flag colors over the object texture. I'm not familiar with the details, but the modding system can direct the process: the mod can specify which part of which texture is rendered on (copyed over) which part of which other texture, resulting in different flag logos being applied over the shield. The alpha channel (associated to the texture of the "naked" shield) does the rest, i.e. the alpha blend results in certain parts of the object texture retain its original color (the unpainted parts), and other parts be overwritten by the flag color.

None of that can be replicated by OpenBRF.

That said, if you take it as a challenge, you can hijack a bunch if unrelated mechanisms of OpenBRF and mimic the results this process. Inspired by your question, I just tried that, for fun, and I managed.

So the long answer is:

Yes, you get a similar result but be warned:
(a) it's a bit long to do, and it is probably not worth the hassle, for just a preview
(b) there's no guarantees it will look exactly like in game, because manual fiddling of a few parameters is required (in step 4 below). Maybe this can be avoided if someone more knowledgeable of the M&B tableau system provides some information about to pick parameters (copying them from the module system).

Say you want to preview a Tableau-ed shield.

(1) duplicate it, duplicate it's material, and duplicate [banners_b] material, the one with the textures for the flags (or any other banner material, pick one).
You will mess with these three objects so better keep them separated, in a separate file, and leave the original untouched. Maybe rename them or put them all in a separate BRF file.

(2) take the Shield and [Split it in connected components].
This way, you will separate the piece which need be tableau-ized from the rest, which are to be left alone.

(3) take the copy of the "to be painted part", make it use the Banner material.
You will see a patchwork of banners over it.
You can discard the other little parts: you will need only the complete shield, and this one part.

(4) Now, you want to enlarge the texture on it, so that only one banner covers it all instead of several.
Select the part to be painted, and "Transform texture coords":
Scale the U by 30% and the V by 15%
(or something, chose how much to crop it, as long as U is twice as V, because the original shield texture had a 2:1 format, the new banner texture is 1:1),
then translate them so to "frame" your favourite banner of the lot.
Fiddle with the numbers. For example, for me, U +0.25 and V +0.42 works.
The "shield_painted" should look like you wanted it to, displaying one logo on it.
Make sure the aspect ratio is correct, i.e. that the logo is not squeezed, and that it is nicely centered where you want it to be.

(5) Now you need to change the Flags of both materials.

You want the other material (not the banner one, the one with the wooded and iron parts)
to be painted OVER the rest, so it must be painted last.
So put Render Order to the top value, +7.
You also want it to be blended, so that it's white parts will be transparent and you'll see the logo
through them. So make sure Transparency is set to "Blend"

(6) Finally, you want the painted piece of the shield to "give way" to the other object, so pick the banner material, edit its flags and select "no Z-write". This makes it so that the "wood and iron" parts of the shield will be actually drawn and not be discarded by the depth test (naturally, they are at the same depth as the painted shield, because it is the same mesh).

(technical note: it would be enough, and actually sounder, to just make the depth test to accept equality values, but there is no flag specifying that and openBRF, by immutable default, uses *strict* inequality for the depth test)

(7) now select both the complete shield and the painted part, make sure they are seen together and not in separate windows  (view mode at the bottom), and this should to the trick.

Wow, thanks for that quick& in-depth answer! Not sure what I'll do yet, but we'll see I guess...
 
I accidentally deleted openBRF and just reinstalled it today. However, now when I double click a mesh, all related objects aren't selected as well.

For example, I might wish to view "sword_medium," but it's in different parts, like:

sword_medium
sword_medium.1
sword_medium.2

I'll double click "sword_medium" and none of the others will be selected when they used to.

Help?
 
That's a relatively recent feature, missing in earlier versions.
Did you reinstall the latest version? (which is quite old, but still)

Hitting F1, you should read: Ver 0.0.81b
 
Back
Top Bottom