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

[mtarini]

Even if I import an existing animation and export again without any changes (so it still retains the first frame being the skeleton T pose) it is flipped.

That makes me curious. What happens if you re-import the SMD, which was exported by 3DS, back into 3DS again?
Will it be flipped?

If it is flipped, it means that it definitely a bug in the 3DS smd-exporting plug-in (*), because it exports something it cannot correctly re-import back.

If it isn't flipped, it means that now you have two smd files: the one exported by OpenBRF and the one exported by 3DS. They would both look correct when imported in 3DS, but would look different (one correct the other one wrong) when imported by openBRF. I would be very curious to see why (by looking at the two files), and then make openBRF smd-import procedure more complete, by including that information.


(*) (In that case, I think it could be easily fixed. The orientation of first bone of the skeleton, which is attached to nothing, has a different encoding than the orientation of any other bone, which are encoded with respect to the bones they are attached to. I guess that's where the problem is. The fix would be to add an import mode in OpenBRF that "fixes" it.)

 

[Lumos]

Actually, Nokia's QT solution for translations is quite robust.

You just need to finish the translation you are doing, even if it is relative to an older version of OpenBrf. Then you send me the resulting .ts file. Using it, not only OpenBRF will be translated in Hungarian for the most part (i.e. for all the menus and stuff that were there in the older version), but also it will produce a new .ts file, containing all that you have translated, and the new menus/etc ready yet to be translated. So, I would put that file online and you'll be able, whenever you'll fell like it, to start from there and complete it.

All right, I'll keep working then.

Hungarian

Bulgaria!

Spoiler

 

[mtarini]

Hungarian

Bulgaria!

Spoiler

 

[Yoshiboy]

Even if I import an existing animation and export again without any changes (so it still retains the first frame being the skeleton T pose) it is flipped.

That makes me curious. What happens if you re-import the SMD, which was exported by 3DS, back into 3DS again?
Will it be flipped?

If it is flipped, it means that it definitely a bug in the 3DS smd-exporting plug-in (*), because it exports something it cannot correctly re-import back.

If it isn't flipped, it means that now you have two smd files: the one exported by OpenBRF and the one exported by 3DS. They would both look correct when imported in 3DS, but would look different (one correct the other one wrong) when imported by openBRF. I would be very curious to see why (by looking at the two files), and then make openBRF smd-import procedure more complete, by including that information.


(*) (In that case, I think it could be easily fixed. The orientation of first bone of the skeleton, which is attached to nothing, has a different encoding than the orientation of any other bone, which are encoded with respect to the bones they are attached to. I guess that's where the problem is. The fix would be to add an import mode in OpenBRF that "fixes" it.)

When re-importing back into max the orientation is fine. Here are my two SMD files - both of which import into max fine, but one of which (the 3ds one) is flipped when imported in openBRF:

theorangeduck.com/other_stuff/jump_loop.rar

Hope that helps!

 

[Vornne]

I'm not sure if I've found a bug in this program, or if I'm just using it wrongly...


Basically, every mesh that I export blender and back is missing exactly one face. I'm not really much of an artist, just been tweaking some of the native meshes to suit my purposes, but I'm pretty sure it isn't becuase I forgot to triangulate the mesh or to redo the UV mapping; it happens even if I don't change the mesh at all, just export from openBrf - import to blender - export from blender - import to openBrf. I also tested with version 0.42 (the oldest I have), as well as with 0.49 - both are the same. The missing face always seems to be the same for a particular mesh - one of the original faces, making me suspect it is the first one. After a while, I decided to try simply export from openBrf then import straight back in; this triggers an assertion:

File: ioObj.cpp
Line:248
Expression: "t.c<(int)norm.size()"

So I guess openBrf is missing out a value somewhere, then blender adds an empty bit back in to make it work - though all the faces seem to show up fine in blender... so I don't really know.

For an example: Start openBrf, open native destroy.brf, export destroy_heap, import into blender then export without changing anything, import back into openBrf, fix up the material name, and this is the result:

Another little thing: when importing from an .obj file, the flags field is set to 0, which makes the client and server crash on startup; I have no idea what it means or where to find that out, but making it the same as the original mesh (seem to be mostly 30000 or 30001) means that everything runs fine. It would be nice if the flags value could default to something that at least allows the game to start.

Oh and I'm running on linux with wine, in case that makes any difference... if you can't reproduce the bug, it might be just me.

 

[mtarini]

Hope that helps!

It sure did!
I found the problem (openbrf got confused by an extra bone that 3ds put there for no reason and should be ignored).
Fixed now, in a mini update...

but the repository seems to be (temporarily?) down so I cannot upload it.
No it is up again. The new exe is there.

Oct-8-2010 ver 0.0.49b: (very minor update)
- fixed a few minor bugs (texture loss on language change, SMD import made more robust)
- updated chinese translation [by foxyman!]

(The texture loss bug was spotted by foxyman)
(I won't update the 1st page, just lazy)


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

After a while, I decided to try simply export from openBrf then import straight back in; this triggers an assertion:

Strange, not here, apparently. What do you do, exactly? You export it from openBRF, static mesh, as "obj", then import it as a "static mesh", and it crashes? Funny, it does not do that here.... hum...

Or, you need blender for that to happen? I don't have a recent blender installed here. I would be curious to see the mesh as exported by blender, the one that causes the "hole" when imported in OpenBRF.

 

[Vornne]

The crash is unrelated to blender, just import / export as you said. For exact steps: start openBrf-49, open Warband/CommonRes/destroy.brf, right click on destroy_heap, select "Export static mesh", save, select "Import" - "Static mesh", select the file, assert. If you can't reproduce or understand why, don't worry, it is not something I need to do, just thought it might help show why the other problem is happening.


For the missing face problem, it happens with any and every mesh imported, as far as I can tell. To make it simple: start blender, export the default cube / make a cube and export it - enabling triangulate - which generates these:

Spoiler: 2.54

# Blender v2.54 (sub 0) OBJ File: ''
# www.blender.org
mtllib cube.mtl
o Cube
v 1.000657 -0.999878 -0.996605
v 1.000657 -0.999878 1.003395
v -0.999344 -0.999878 1.003395
v -0.999343 -0.999878 -0.996606
v 1.000657 1.000122 -0.996605
v 1.000656 1.000122 1.003395
v -0.999344 1.000122 1.003394
v -0.999343 1.000122 -0.996605
usemtl (null)
s off
f 1 2 3
f 1 3 4
f 5 8 7
f 5 7 6
f 1 5 6
f 1 6 2
f 2 6 7
f 2 7 3
f 3 7 8
f 3 8 4
f 5 1 4
f 5 4 8

Spoiler: 2.49

# Blender3D v249 OBJ File:
# www.blender3d.org
mtllib cube_old.mtl
v 1.000000 -1.000000 -1.000000
v 1.000000 -1.000000 1.000000
v -1.000000 -1.000000 1.000000
v -1.000000 -1.000000 -1.000000
v 1.000000 1.000000 -1.000000
v 0.999999 1.000000 1.000001
v -1.000000 1.000000 1.000000
v -1.000000 1.000000 -1.000000
usemtl Material
s off
f 5 1 4
f 5 4 8
f 3 7 8
f 3 8 4
f 2 6 3
f 6 7 3
f 1 5 2
f 5 6 2
f 5 8 6
f 8 7 6
f 1 2 3
f 1 3 4

After importing the first one (the other one has the same effect) into openBrf, a face is missing:

Spoiler

Export it from openBrf:

Spoiler: openBrf 1

#
# Exported by OpenBRF -- marco tarini
#
s cube
newmtl (null)
Ka 0.8 0.8 0.8
Kd 0.2 0.2 0.2
usemtl (null)
v 1.00066 -0.999878 -0.996605
v 1.00066 -0.999878 1.00339
v -0.999344 -0.999878 1.00339
v -0.999343 -0.999878 -0.996606
v 1.00066 1.00012 -0.996605
v 1.00066 1.00012 1.00339
v -0.999344 1.00012 1.00339
v -0.999343 1.00012 -0.996605
vn 0.816497 -0.408248 -0.408248
vt nan 1
vn -0.816497 -0.408248 0.408248
vt nan 1
vn -0.408248 -0.408248 -0.816497
vt nan 1
vn 0.333334 0.666667 -0.666667
vt nan 1
vn -0.816496 0.408248 -0.408249
vt nan 1
vn -0.333333 0.666667 0.666667
vt nan 1
vn 0.816496 0.408249 0.408249
vt nan 1
vn 0.447213 4.26496e-07 0.894427
vt nan 1
f 1/1/1 3/2/2 4/3/3
f 5/4/4 8/5/5 7/6/6
f 5/4/4 7/6/6 6/7/7
f 1/1/1 5/4/4 6/7/7
f 1/1/1 6/7/7 2/8/8
f 2/8/8 6/7/7 7/6/6
f 2/8/8 7/6/6 3/2/2
f 3/2/2 7/6/6 8/5/5
f 3/2/2 8/5/5 4/3/3
f 5/4/4 1/1/1 4/3/3
f 5/4/4 4/3/3 8/5/5

Now import it back in, another face is missing! Same orientation:

Spoiler

Export it again:

Spoiler: openBrf_2

#
# Exported by OpenBRF -- marco tarini
#
s cube_1
newmtl (null)
Ka 0.8 0.8 0.8
Kd 0.2 0.2 0.2
usemtl (null)
v 1.00066 -0.999878 -0.996605
v 1.00066 -0.999878 1.00339
v -0.999344 -0.999878 1.00339
v -0.999343 -0.999878 -0.996606
v 1.00066 1.00012 -0.996605
v 1.00066 1.00012 1.00339
v -0.999344 1.00012 1.00339
v -0.999343 1.00012 -0.996605
vn 0.333334 0.666667 -0.666667
vt 0 1
vn -0.816496 0.408248 -0.408249
vt 0 0
vn -0.333333 0.666667 0.666667
vt 0 1
vn 0.816496 0.408249 0.408249
vt 0 0
vn 0.816497 -0.408248 -0.408248
vt 0 0
vn 0.816496 0.408249 0.408249
vt 0 0
vn 0.816496 0.408249 0.408249
vt 0 0
vn 0.447213 4.26496e-07 0.894427
vt 0 1
vn 0.447213 4.26496e-07 0.894427
vt 0 1
vn 0.816496 0.408249 0.408249
vt 0 0
vn 0.447213 4.26496e-07 0.894427
vt 0 1
vn -0.816497 -0.408248 0.408248
vt 0 1
vn -0.408248 -0.408248 -0.816497
vt 0 0
f 5/1/1 8/2/2 7/3/3
f 5/1/1 7/3/3 6/4/4
f 1/5/5 5/1/1 6/6/6
f 1/5/5 6/7/7 2/8/8
f 2/9/9 6/10/10 7/3/3
f 2/11/11 7/3/3 3/12/12
f 3/12/12 7/3/3 8/2/2
f 3/12/12 8/2/2 4/13/13
f 5/1/1 1/5/5 4/13/13
f 5/1/1 4/13/13 8/2/2

And if I keep repeating the export / import, each time one more face disappears.

 

[mtarini]

Thanks for the detailed explanation!
Correcting bugs after they have been pinpointed with such accuracy is easy!
So I did. Version 0.0.49c.

Oct-8-2010 ver 0.0.49c: (very minor update)
- fixed a bug importing obj-s as static meshes

But, I'm really surprised!
Import static meshes from obj is very common.
Everybody surely has been doing it for a long time, including me.
The bug would appear only occasionally, true. But still I'm surprised that it wasn't noticed before.



Edit:

...but I'm pretty sure it isn't becuase I forgot to triangulate the mesh ...

BTW, strictly speaking, you don't need to, as OpenBrf will triangulate it on import (up to hexagonal faces).

 

[Vornne]

Wow, thanks heaps; you certainly give good customer service... I was getting ready to have a go at compiling this for linux and debugging it from there, in case it was a problem that only happens in wine; but I tried the latest version, and it imports perfect unholy meshes .


As for why nobody saw it, I checked back over some of the meshes I imported and thought were fine; I found missing faces that were either very small or on the underside where I didn't notice.

 

[Mikey]

...but I'm pretty sure it isn't becuase I forgot to triangulate the mesh ...

BTW, strictly speaking, you don't need to, as OpenBrf will triangulate it on import (up to hexagonal faces).

It does? Now that's neat, and takes a step out of the process, at least for testing purposes. Of course, for optimization reasons it might be a good idea to go in there and do the tri's yourself, but that all depends on the model in question, whether there's going to be one, a few or potentially lots visible at the same time, etc.

 

[Yoshiboy]

Hope that helps!

It sure did!
I found the problem (openbrf got confused by an extra bone that 3ds put there for no reason and should be ignored).
Fixed now, in a mini update...

but the repository seems to be (temporarily?) down so I cannot upload it.
No it is up again. The new exe is there.

Oct-8-2010 ver 0.0.49b: (very minor update)
- fixed a few minor bugs (texture loss on language change, SMD import made more robust)
- updated chinese translation [by foxyman!]

(The texture loss bug was spotted by foxyman)
(I won't update the 1st page, just lazy)

Brilliant, thanks!

 

[Swyter]

But, I'm really surprised!
Import static meshes from obj is very common.
Everybody surely has been doing it for a long time, including me.
The bug would appear only occasionally, true. But still I'm surprised that it wasn't noticed before.

I noticed the missing face along all versions, I forgot reporting you that one. Sorry.
BTW I did another revision of the <Ñ> translation. It polishes almost everything. You can find it at the usual place.

PS: Can you make some dialog buttons translatable? So I can hit the 100%.
For example "Close"(Cerrar) at finding diag.  and the "Save"(Guardar), "Discard"(Descartar), "Cancel"(Cancelar), "Ok"(Aceptar) ones.

I'm pretty satisfied with the current translation quality so far. They're only cosmetic details.


PS2: I noticed that the latest versions does not include an accept button for the new shader window. It turns the function unusable.

Spoiler: ✖ Amazing Pictures inside!

PS3: Finally I noticed that the specularity it's pretty brilliant, making the flat objects almost white. Maybe it's an OpenGL problem with my hardware. Also notice that the alpha channel of the image it's used as reflexion-mask in the game. for both, the specular_shader and iron_shader.

Spoiler: ✖ Amazing Pictures inside!

That's all... for now

 

[mtarini]

Thanks! All useful news... I'll have a look asap.

Especially the specularity problem. It has been privately reported already. Too bad in my computer it works perfectly.
Difficult to fix until I can find a computer where it does not work. It could be a million things.

Meanwhile you can disable alpha-shininess (and alpha-transparency) under [Settings] -> [Meshes Rendering],
so at least you can avoid the problem.

 

[Mad Vader]

A couple of minor bugs:
- "Scan module for errors": in Warband, erroneously reported missing beard and hair materials (skins.txt)
- "Show unreferenced texture files" is case-sensitive, e.g. it will report "Mytex.DDS" if it's registered as "mytex.dds", which should be ok

Otherwise, impressive work - it already helped me find and remove unused materials from POP3 brfs that I didn't know about. Keep it up!

 

[mtarini]

Thanks MadVade, fixing these also.

- "Scan module for errors": in Warband, erroneously reported missing beard and hair materials (skins.txt)

I'm a little undecided here. I knew about this.

In skins.txt these a list of alternative materials (for beard and hair) do appear, but the game seems to be using only the 1st one.

My understanding is that, in some older version of M&B, the game would use the others when you selected different "hair color".
Then, Armagan & team changed their mind, and now use only one material (to make red-haired, dark-haired etc, they multiply the color). So only the 1st material is used by the game now.

Now, not sure about what I should do.
Should I make OpenBRF ignore the rest of the list and (only check only the 1st item)?

Reporting the others as an error was supposed to be a way to warn modders that listing any material after the 1st is useless
(on seeing that error, modders would remove the other materials from the list, in the .py file).
Feel free to suggest.

 

[Mad Vader]

I suggest you don't report any Native errors. A Native scan should always be successful, so modders can see if THEY did something wrong, and not get confused or obliged to fix Native errors.
I do have a checkbox in FMV to explicitely turn on Native error reporting, so that's another option.

Edit: also please don't report _Lx,_R and _Rx meshes unused if there is a _L mesh that's used (hand armor).

 

[Someone_forgotten]

thanks again for the great tool mtarini

 

[mtarini]

Edit: also please don't report _Lx,_R and _Rx meshes unused if there is a _L mesh that's used (hand armor).

Good catch! I did that for "hand" and "calf" body meshes, forgot to do that for gloves.
BTW: why warband has glove meshes fixed in closed position, instead of having the usual vertex animation (open-hand -closed-hand)?


BTW: if anybody (MadVader?) knows of any "hardwired" objects (meshes, texture, materials... anything) that the game uses, even if they are not listed anywhere, please let me know. So far, the list includes anything from "core_" files, plus "skel_horse" .
I think map materials fall in this category too, not sure what the complete list is exactly (for M&B and WB). Is there anything else?

 

[mtarini]

Double post and update!

Fixed the recently reported bugs.
Thanks to MadVader and Seyter, who reported these bugs!

From the download page...

Oct-8-2010 ver 0.0.49d: (very minor update)
- fixed undue case-sensitivity in redundant texture files (dds) identification
- fixed usage of glove meshes (from items.txt)
- slightly improved error reporting (less errors in native)
- fixed "create new shader" dialog
- updated spanish translation [by swyter!]

The reported bugs/request that where not fixed, are
- the "translatability of the last few buttons"... sorry, convincing QT to translate these is surprisingly tedious
- the "wrong" shininess... sorry I still need to find a computer where I can see that error
  Meanwhile, if it is wrong for you, please report it, and
  you can disable it with [settings]->[mesh rendering]->[always use default settings]

Also, don't miss reading the request in the last sentence of my post above...
(about hardwired objects).
For example, if you remove an object from your brf file (a mesh, a texture, etc), which OpenBRF described as "not used", but then it turns out that the game actually needed it (e.g. will complain that it is not there), please report so!

 

[xenoargh]

Awesome stuff!  The new file-checker is really useful