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

[yellowmosquito]

Has anyone else experienced textures not showing up in-game even though it shows up fine in openBRF?

I've got a few models in a BRF file; mesh, textures and material all previously set up using BRFedit... and later the BRF was edited in openBRF - there was some import/copy/delete stuff done within the BRF but other than that the mesh, materials and textures of the original models weren't messed around with. Upon loading the game however the original meshes loaded up alright but the textures aren't loaded and everything is white instead.

I've double checked and triple checked to make sure the DDS is in the right place. Reopening the BRF in BRFedit shows that the material/texture reference is still correct but somehow after the BRF was edited in openBRF the textures just won't load in-game. After I've replaced the BRF with a backup of the original the textures loaded up normally once more. I compared the original BRF with the one edited in openBRF but there was no difference between them as far as I can see. I'm wondering if anyone else has encountered similar problems or if my case is an isolated one.

edit: I was able to reproduce this bug by editing another old BRF by importing a random model into it and saving the file. The models inside the BRF that were left unedited was affected, their textures won't show up in-game even though they worked perfectly before.

Yes, I believe am experiencing this.  I decided to switch from BRFEdit to OpenBRF tonight.  For some strange reason, when I open my old BRF files (created in BRFEdit) in openBRF, I can't see any textures (just checkerboard).  After saving one item, everything that was in the BRF file now appears white (textureless) in game.  The materials and textures are present in the same BRF and all of my textures are DX1, DX3, or DX5. 

Anyone know if this is a bug, or if I am just doing something wrong?

 

[amade]

Spoiler

Has anyone else experienced textures not showing up in-game even though it shows up fine in openBRF?

I've got a few models in a BRF file; mesh, textures and material all previously set up using BRFedit... and later the BRF was edited in openBRF - there was some import/copy/delete stuff done within the BRF but other than that the mesh, materials and textures of the original models weren't messed around with. Upon loading the game however the original meshes loaded up alright but the textures aren't loaded and everything is white instead.

I've double checked and triple checked to make sure the DDS is in the right place. Reopening the BRF in BRFedit shows that the material/texture reference is still correct but somehow after the BRF was edited in openBRF the textures just won't load in-game. After I've replaced the BRF with a backup of the original the textures loaded up normally once more. I compared the original BRF with the one edited in openBRF but there was no difference between them as far as I can see. I'm wondering if anyone else has encountered similar problems or if my case is an isolated one.

edit: I was able to reproduce this bug by editing another old BRF by importing a random model into it and saving the file. The models inside the BRF that were left unedited was affected, their textures won't show up in-game even though they worked perfectly before.

Yes, I believe am experiencing this.  I decided to switch from BRFEdit to OpenBRF tonight.  For some strange reason, when I open my old BRF files (created in BRFEdit) in openBRF, I can't see any textures (just checkerboard).  After saving one item, everything that was in the BRF file now appears white (textureless) in game.  The materials and textures are present in the same BRF and all of my textures are DX1, DX3, or DX5. 

Anyone know if this is a bug, or if I am just doing something wrong?

For the checkerboard pattern, read this: http://forums.taleworlds.com/index.php/topic,72279.msg1918258.html#msg1918258

If your textures are all correct (i.e. it shows up alright in BRFedit) even though it shows a checkerboard pattern in openBRF try and load the model and textures in game. If it still shows up as white then you're probably encountering the same issue as I am. This only affects BRFs that have been edited and saved using openBRF.

 

[Red River]

Spoiler

Has anyone else experienced textures not showing up in-game even though it shows up fine in openBRF?

I've got a few models in a BRF file; mesh, textures and material all previously set up using BRFedit... and later the BRF was edited in openBRF - there was some import/copy/delete stuff done within the BRF but other than that the mesh, materials and textures of the original models weren't messed around with. Upon loading the game however the original meshes loaded up alright but the textures aren't loaded and everything is white instead.

I've double checked and triple checked to make sure the DDS is in the right place. Reopening the BRF in BRFedit shows that the material/texture reference is still correct but somehow after the BRF was edited in openBRF the textures just won't load in-game. After I've replaced the BRF with a backup of the original the textures loaded up normally once more. I compared the original BRF with the one edited in openBRF but there was no difference between them as far as I can see. I'm wondering if anyone else has encountered similar problems or if my case is an isolated one.

edit: I was able to reproduce this bug by editing another old BRF by importing a random model into it and saving the file. The models inside the BRF that were left unedited was affected, their textures won't show up in-game even though they worked perfectly before.

Yes, I believe am experiencing this.  I decided to switch from BRFEdit to OpenBRF tonight.  For some strange reason, when I open my old BRF files (created in BRFEdit) in openBRF, I can't see any textures (just checkerboard).  After saving one item, everything that was in the BRF file now appears white (textureless) in game.  The materials and textures are present in the same BRF and all of my textures are DX1, DX3, or DX5. 

Anyone know if this is a bug, or if I am just doing something wrong?

For the checkerboard pattern, read this: http://forums.taleworlds.com/index.php/topic,72279.msg1918258.html#msg1918258

If your textures are all correct (i.e. it shows up alright in BRFedit) even though it shows a checkerboard pattern in openBRF try and load the model and textures in game. If it still shows up as white then you're probably encountering the same issue as I am. This only affects BRFs that have been edited and saved using openBRF.

Great work so far. Since Aug29 versions all textures outside native showing as checkboard for me now. I can see the textures in the tabs though. That applies to all mods I have. The textures used to show at least on some models before... Keep up good works!

 

[Lumos]

[*] ruler tool: [DONE] (new 0.0.16)designed to pinpoint the precise reach of weapons (best used without textures IMO) [Fei Dao suggestion]

Awwww, that makes my Metring Stick (almost) totally unusable. But who cares?

Nice program. Really nice program. But how do you import textures and materials, etc.?

 

[cdvader]

Under the Import menu, you have the materials, texturers and shaders option.

 

[mtarini]

Icon and graphics:

I owe I enormous THANK YOU to Swyter who made terrific banners, logo and icons for OpenBRF. Great work!
I'll definitely use logo and banner in the website and doc. They look great. I'm tempted to use it on a splash-screen, but I'm against splashscreens in general. As for the icon, I was working on one of my own design... Oops! I would stick to that one. But if mine won't look good, I've got a fallback option now!



"Texture not showing up in game" Bug... maybe I know: is it the case that the BRF file you (amade) used contained both the mesh and the Material (and the texture, maybe?).... if so, it could be an ordering problem inside the brf file. Yes, that must be it. If that's correct, I'll fix in in a snap!  Nice ship model, BTW. If that's a mod, I'm looking forward to play it.




Texture misalignement problems:   Thanks amade, your bug reports are, as always, very usefully detailed. What's even more useful, enriched by exemplar data. So I'll try to fix it, even if right now I've no idea about what that could be. Do I understand that they are small misalignement, not total texture screw up, like the ones reported by Highelf [link]? Was anyone able to reproduce that bug? Is it still on?




Vertex animation compositing: You are right. Frames should be inserted after, not before, current one! I'll fix that... thanks amade (once again)!



Ruler suggestions : Length up to 550? No prob and thanks for pointing it out, Fei Dao.
Ability to measure among other axis... good suggestion, Yellowmosquito, that's probably useful for a variety of purposes.
I'll add it on the todo list for now: "a general tool to find 3D coordinates realtive to a mesh" (or to an animation frame).
Probably I'll leave the current "weapon reach" ruler tool as is, and add a new, more general tool.



"Texture not showing up in openBRF" Bug [Red River]: (checkboard patterns instead of texture) where are the materials, the brf textures, and the dds textures of your "non-native" meshes? I assumed dds texture files to be inside <mod dir>/textures, while brf material and brf texture items to be inside brf files listed inside <mod dir>/Module.ini. Should I make OpenBRF look in other places as well? which ones?



Lumos: you don't import texture, material or shaders. Either you "add new" texture/material/shaders, or you duplicate existing ones and then edit them (including rename). If you "add new" istances of texture/materials ("import" menu), you have to option to use a dds texture file as a starting point to speed up the process (a material/texture with that name will be produced).



Collision meshes: did anyone tested them in game? There could be problems that emerge only in game. Also, I've no idea about what the flags and the field I've called "sign" (because it is either a plus one or minus one in all native files) does.



Edit: Warband BRF: Thanks fei-dao and cdvader for the data. It is really, really tempting to proceed with the reverse eng and see how they differ... for now I must postpone (work).



Edit: PS: highelf  I knew you would have liked it  . PS: did you test the "recompute normal" thing on your dwarf_body (thanks for the data, which I used to test it)? It should work now.

 

[Red River]

...


"Texture not showing up in openBRF" Bug [Red River]: (checkboard patterns instead of texture) where are the materials, the brf textures, and the dds textures of your "non-native" meshes? I assumed dds texture files to be inside <mod dir>/textures, while brf material and brf texture items to be inside brf files listed inside <mod dir>/Module.ini. Should I make OpenBRF look in other places as well? which ones?

I have everything in the default locations for all mods. There's 3 or 4 tabs when open a brf. One for meshes, one for textures and one for materials. They all look fine and I can see the textures under the Tex and Mat tab but they don't show up on the models themselves unless they use the native textures.
It used to work for most models before the last few updates as stated earlier.

Again, everything is in the default locations as far as mod folders and brf/dds files are concerned...

 

[mtarini]

I see. I should include the content of the currently open BRF in the list of known materials.

In any case, the following should work even in current version (could you check?): include your new BRF file in the module.ini file, using an "load_mod_resource" command (note: not a "load_resource"). I'm talking about the "module.ini" file inside module dir, which you can edit using a text editor.  Once you edited and saved the module.ini file, refresh module (F5) in OpenBrf (or close it and reopen it). Then it should work.

 

[Red River]

I see. I should include the content of the currently open BRF in the list of known materials.

In any case, the following should work even in current version (could you check?): include your new BRF file in the module.ini file, using an "load_mod_resource" command (note: not a "load_resource"). I'm talking about the "module.ini" file inside module dir, which you can edit using a text editor.  Once you edited and saved the module.ini file, refresh module (F5) in OpenBrf (or close it and reopen it). Then it should work.

I tried that and it didn't change a thing. Still no textures...

 

[amade]

"Texture not showing up in game" Bug... maybe I know: is it the case that the BRF file you (amade) used contained both the mesh and the Material (and the texture, maybe?).... if so, it could be an ordering problem inside the brf file. Yes, that must be it. If that's correct, I'll fix in in a snap!  Nice ship model, BTW. If that's a mod, I'm looking forward to play it.

I think you've nailed it. As we know the same is true when loading the BRFs in the module.ini, we have to load BRFs containing textures first before material and before the mesh. So I tried separating the texture, material and mesh into different BRFs and loaded them in the module.ini in the proper order; it works! The texture showed up in game and as a result I was also able to confirm that vertex animation compositing worked great! The ship icon was made using option 2, and yes, it's for a mod called Hari Ragat. Thanks!

Another thing... when importing new textures it automatically gave my texture the flag 0 (shown as 00000000 in BRFedit) while textures imported using BRFedit had a flag of AA000 (000AA000 in BRF edit). I've no idea what the hex flags do for textures, but I thought I should mention it anyway.

Texture misalignement problems:   Thanks amade, your bug reports are, as always, very usefully detailed. What's even more useful, enriched by exemplar data. So I'll try to fix it, even if right now I've no idea about what that could be. Do I understand that they are small misalignement, not total texture screw up, like the ones reported by Highelf [link]? Was anyone able to reproduce that bug? Is it still on?

For my case it's always been very minor misalignments, though it could be because I like to map my UV coordinates differently with minimum stretching perhaps? Tests with native static meshes yielded larger misalignments (probably because they are mapped to a smaller texture space).



Also, re Checkerboard patterns for when openBRF can't locate the textures: For me, I am able to view my textures most of the time since the last few updates. The one time I couldn't view the textures was when I was doing the vertex animation BRF. I imported a texture, and then created a material using that texture. When I tried to apply the texture to the model (which was in the same BRF) the name autocomplete didn't list the newly added texture and material. Even after saving the file and reloading it it still won't list the new material for the mesh. Manually entering the name of the material into the mesh's material field didn't work, openBRF still shows the checkerboard pattern.

Using the same method as described above where the mesh, texture and material was separated into different BRFs and loaded in the correct order the textures do show up on in openBRF's 3D preview (though, still misaligned).

And a couple minor requests if possible:
-Can we have a wider display field for the shader's dropdown menu? It's hard to find shaders with longer names such as "tex_mul_color_mul_factor_alpha", a minor problem that was also present in BRFedit.

-For vertex animation importing, can we have openBRF display a warning message if it detects that the vertex IDs are not the same during/after import? With BRFedit, it gave me a warning each time I try to import a frame that doesn't have matching vertex IDs, so I can quickly pinpoint which frames are way off and fix them, though with the option to use texture coordinates as unique identifiers of vertices this might not be a problem any more after all.

 

[mysstick]

At me not as there does not pass an error http://i025.radikal.ru/0908/90/71ffdceffaa5.jpg explain what to do?

 

[mtarini]

At me not as there does not pass an error http://i025.radikal.ru/0908/90/71ffdceffaa5.jpg explain what to do?

Mysstick: I can only imagine three problems: the file you are trying to export to is actually being held open by some other application preventing OpenBRF to write on that file (solution: close this other application), OR, the path/filename is in a read-only folder (like one on a CD, or a system directory -- I think vista won't let you save in C:\ for example --, OR, the filename contains funny non-ascii things like weird accented letters or symbols or has shortcuts in the path and that confuses OpenBrf (if so, please tell me. To test this hypothesis, try exporting to somewhere more simple like "C:\games\MountAndBlade\test.SMD" or whatever.


Amade: texture flags: good to know. I comply to the BrfEdit way, one never knows. For the rest, I'll see.

Red River: still no luck? hum. What does it says in the lower left corner? It should display your mod name if everything is fine.
And the title bar? Does it says "[not in module.ini]" next to the filename when you open the BRF file with the material? (it shouldn't, if everything is fine). Just to understand what's going wrong.

Amade and Red River: the next version should be a little better at these problems anyway...

 

[Red River]

At me not as there does not pass an error http://i025.radikal.ru/0908/90/71ffdceffaa5.jpg explain what to do?

....
Red River: still no luck? hum. What does it says in the lower left corner? It should display your mod name if everything is fine.
And the title bar? Does it says "[not in module.ini]" next to the filename when you open the BRF file with the material? (it shouldn't, if everything is fine). Just to understand what's going wrong.

Amade and Red River: the next version should be a little better at these problems anyway...

it displays the name of the mod and how many files were scanned as well as time. it does say not in module ini at the top next to the brf name though.

good stuff..

 

[mysstick]

Thanks!!!! The way to a folder really was accessible only to reading

 

[mtarini]

Minor update! From the 1st page...

Ver 0.0.18 (30 Aug):
- minor update: "missing textures in game" bug fixed; "obj import text coord misalign" bug fixed; now v. animation frames are appended after current one; not it uses current brf to locate materials too; ruler made longer...

The OBJ texture coord bug forced me to abandon the OBJ lib I was using and writing one from scratch. I tested my code a little, but there could well be errors.

The texture bug could have caused both the small aligment problems and the large, extreme texture coords problems that were reported... are they gone now?

As for the different shading after OBJ import, that's just due to how blender/maya/3Dmax/wings3D decide to export the normals (if you don't like theirs, you can always try and see if you like the ones re-computed by BRF any better).

Edit: another few updates and I'll call it a beta.



Another UPDATE:

If you redownload now, you get a "10-minutes-later" version. I've started reverse engineering the Warband files... and so far it was very easy. I only had animation files with me, but they do load perfectly now! Dunno about other kinds. Might work as not.

Have a look, the animations there are really terrific! But, if you save them, make sure you don't overwrite the original warband files, because, as for saving goes, OpenBRF would save them in the old "M&B 1.011" brf format and warband won't probably be happy about this (unless it is back compatible). Warband files should re-saved in OpenBRF should be usable in M&B, however. I'll add a flag to chose which format to use when saving files.

 

[amade]

Texture on OBJ import: Texture now aligns properly, awesome! A couple of minor bugs though, the models are renamed as "1" upon import and are also mirrored. They load the wrong way around in-game e.g. a falchion's edge is facing the other way.

In-game textures: Resaving the "bugged" BRFs in ver 0.0.18 fixes the missing in-game textures. Textures and materials can also be viewed in the 3D preview without having to separate them into different BRFs anymore.

Vertex animation: I really have to thank you for this, there's a lot of things I want to do with it now that you've perfected it!

Some stability issues: These have been appearing over the past few updates.

• Selecting another mesh after deleting a different mesh sometimes cause openBRF to crash. Currently I take precautions by always saving first, and avoiding selecting another mesh by clicking different tabs or something. Copy/pasting meshes after some messing around sometimes cause a crash too.
• Importing textures or materials while viewing a mesh/material/textures quite often (almost always) cause a crash too - temporary work around is by NOT selecting anything upon loading the BRF, import the material/textures, save and reload.

Despite that, great update! With the recent bugfixes I can already completely replace BRFedit.

 

[yellowmosquito]

Thanks a ton for getting the texture issue cleared up for us.  Now textures and materials in the same BRF work great for me! 

I'm officially waving goodbye to BRFEdit now. 


EDIT: I think to completely solve the texture issue, it may be necessary to...

1) Check for materials and textures in all brf files in the given module.  (I think that is what BRFEdit did?)
2) Check for textures in the CommonRes folder for those of us that reference native textures in our models.  (I think that is just materials.brf, materials_face_gen.brf, textures.brf, and textures_face_gen.brf).


EDIT: Found another bug with the latest version - If I import a static mesh with the last item in the list selected, the program crashes.

 

[mtarini]

the models are renamed as "1"

Uhm... Not here. Anyway, it must be that I made it so that the mesh assumes the nambe of the object inside the obj (not of the filename). It seemed the right thing, but I'll revert to make it use the filename.

[imported meshes] are also mirrored.

[Unless I'm mistaken...] It is just that the old exporter (as well as brfedit exporter) produced mirrored meshes. In fact, we saw objects mirrored in Wings3d/blender. The old importer mirrored them back. The new importer and new exporter shouldn't mirror anything. In short: before importing an OBJ produced by the prev versions or by BrfEdit, mirror it on the X inside you modelling app (say, blender). From now on, we should see the same thing in wings3d, openBRF, and in-game. Confirm?

Some stability issues: These have been appearing over the past few updates.

Thanks, I'll have a look.

EDIT: I think to completely solve the texture issue, it may be necessary to...

It does more than that. It reads all brf (from common res or from specific module resource path) included in the module.ini.
Plus, it reads three common-res BRF files (starting with "core_") which, apparently, the game always implicitly loads but are not listed in the ini file. Plus, it "knows" any material present in the currently open BRF, whatever it is included in the module ini or not. Let me know if that fails.
It already does 1, and checks ALL files in CommonRes whch are included in the

 

[Red River]

I still get not in module.ini with some brf files. Still lots of textures missing here and there... It seems to have problems reading some dds textures.

 

[mtarini]

> I still get not in module.ini with some brf files.

If you get that, it has nothing to do with the BRF file itself. It means that it didn't find a

load_mod_resource yourfile.brf

in your module.ini (or, that it didn't find module.ini).
Note, load_mod_resource is not the same as load_resource. The former makes openBrf (and M&B) look in module "Resource" folder. The latter, in "CommonRes" folder.

Apart from modules in brf filse in module.ini, OpenBRF also knowns about materials which are in the same BRF file as the mesh using them.

> It seems to have problems reading some dds textures.

That's easy to check. If you load the material (or texture) itself, does it show it? If not, either it is a problem with dds file, or the dds file is not where it is expected to be (in either one of the "Textures" folder: the common one or the module one). Let me know!