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

Users who are viewing this thread

Yeah, all of those bugs are fixed now. Also, the bug what Highelf meant is described in this video I made. It basically works... It just seems that the bones seem to rotate like 45 degrees to the right.

I'm using 3ds Max 2009.
http://www.megaupload.com/?f=Z2V0P42C

EDIT: Odd bug. I downloaded an add-on for Firefox and then when it asked me to restart Firefox, I pressed yes and then Open BRF crashed.
 
Update!!! From the first page:

ver 0.0.8 (12 Aug):
  Added back compatibility with M&B 0.808 materials and skeletons.
  Export/import of rigged meshes (SMD):
        - added a x10/x0.1 scale factor for coherency with what old BrfEdit exported.
        - (also, now if a vertex is connected to >4 bones it tries to fix it, instead of complain and die.)
  Export of animations (SMD):
        - changed stuff a bit, to see if now 3DSMax likes them better.
        - added a file format option to correctly import SMD files that were originally produced by old BrfEdit (or their derivatives)
  Bug fixes on load, GUI improvements...

So, now I expect that most (all?) valid BRF files are accepted by OpenBRF.
The other main improvements concern import of rigged-meshes and animations as SMD files...


amade: the new version should load the rigged mesh correctly. The "problem" was just a scaling problem that BrfEdit added
for some reason on export. Anyway, now I add it too, so OpenBrf will happily inherit SMD rigged meshes left by BrfEdit.
Niiiiice rigged armor, btw. Impressive!  And thanks for the test data.


Tul: problem with the import of rigged mesh "kind of" fixed. It was related to that >4 bones per vertex. But, even if now it load them, it is a bad idea to allow >4 bone per vertices as M&B will not use them. Thanks for the data!


cdvader: thanks for the reports. You must have downloaded a version I mistakenly put up and left up for a short time. As you know, fixed now. (the problem was that it just did not load "reference models" on startup).

Dain I.F. and HighElf and cdvader: 3DS is being worked on. I don't know yet if I managed to make OpenBRF export SMD files that it likes... It could be. A test? (Dain: a lot more info in the other forum, as you know).


That's all.
Oh, if you import an SMD animation and it looks all garbled, try improting it as a "old brf-style animation instead".
 
Excellent news! I will start testing immediately. By the way, I made a tutorial about adding new animations in using your OpenBRF. It's in my signature.

EDIT:
Bug 1 - I opened uni_throws.brf and added in my own animation, saved it and it all worked, however, when I closed OpenBRF and later tried to reopen uni_throws.brf, it crashed on me with this error. (The error started from the previous version, I hoped this would fix it but doesn't seem like so.)

43460845.jpg


Bug 2 - Not sure if it's really a bug, but I don't have skel_horse or something like that in my skeletons.brf when viewing it with OpenBRF. I do have skel_human. If I recall correctly, skeletons.brf used to have a skel_horse.

Status update 1: OpenBRF still doesn't export the .SMD file 3ds Max likes. Here's a video of the bug. http://www.megaupload.com/?f=Z2V0P42C
 
thanks for the detailed report!

I would need the SMD animation file you imported...
unless... I suspect I know the problem: maybe the SMD file you imported had all frames timestamped at 0?


Try redownloading openBrf and repeat the sequence of operations.
Now openBrf enforces strict increasing timestamp order on import, so, if that was the problem, this time it should work.

PS: the BRF file you saved might be compromised already... in case you don't have a copy, I temporarily put a replacement here:
uni_throws.brf
 
Okay. The crash with the exactly same error happens again, even when I re-downloaded the new version.

This is what I do: I open 'uni_throws.brf', select 'throw_javelin.smd', Export it as Skeletal Animation. I then rename it to 'throw_braveheart.smd' and re-import it to OpenBRF. All is fine, it seems to work. I Save the .brf file, close OpenBRF and when I come back to OpenBRF and try to open 'uni_throws.brf' once again, I get that error.

It happens with every .brf file where I import a custom Skeletal Animation file. And the SMD file you requested is at my MegaUpload folder - http://www.megaupload.com/?f=Z2V0P42C as 'throw_braveheart.smd'.

By the way, thanks for re-uploading the uni_throws.brf for me.
cdvader

EDIT: Also, a note, the game can read the new animation (Added it in with the Module System), but it seems I simply can't open it in OpenBRF.
 
Confirmed! It works perfectly now. Thanks! I wish I would know C++ better (so far I can only create very simple programs like basic calculator, fahrenheit to celsius converters etc. Not huge and awesome stuff like this..)

cdvader
 
I've encountered a new (fun) bug. Basically, open uni_strikes.brf . Select the second choice, should be "strikes3_head". Now don't press anywhere and go to File > Open and open uni_strikes3.brf . And now, look at the render screen. Fun, huh? If you do the same exact thing but select the third choice, then three meshes appear.

In one-word: restrict the "choice" only to one at a time. Hope I was clear enough. :smile:
cdvader

EDIT: Can also someone please re-send me "ani_death.brf" ? :razz: Seems that I messed that up, too, when I was using the old version.
 
mtarini said:
amade: the new version should load the rigged mesh correctly. The "problem" was just a scaling problem that BrfEdit added
for some reason on export. Anyway, now I add it too, so OpenBrf will happily inherit SMD rigged meshes left by BrfEdit.
Niiiiice rigged armor, btw. Impressive!  And thanks for the test data.

Thanks for the compliment :grin:
Import works fine now for all SMDs of various sources (except for one case, see bug report below), but export is still mostly wonky.


BUG REPORT

I tried to export skeletons to make new animations and got this:
openBRF008_bugrpt_3.jpg

Going back to the rigged mesh SMDs:
openBRF008_bugrpt_2.jpg
This was exported from a rigged mesh that was already in a BRF (I'm following the same test as I did with ver 0.0.7) - the scale is right, I checked with old SMDs, but the bones are still pointing the wrong way in Blender. To further test this SMD, I moved some vertices around and re-exported it from Blender into SMD and then import it back into openBRF. Blender's export works fine so I expected it to still work alright by unmessing the bones like in the previous version but it gave me a new error when I tried to import:
openBRF008_bugrpt_5.jpg
So I reimported the SMD back into Blender to see if I can still open it but Blender gave me this error instead:
openBRF008_bugrpt_6.jpg
Weird... since when was there a named bone? All bones were numbered instead of named. So I checked the SMD I exported out using openBRF in Blender again and found out that all the bones have been renamed:
openBRF008_bugrpt_4.jpg

openBRF008_bugrpt_4-b.jpg
As you can see in the weight paint mode, the verts are all still properly rigged but the bones and vertex group names have been renamed. I don't know if this is the cause of the problem.

I tried to import openBRF's exported SMD using BRFedit, it imports fine but it looks like this:
openBRF008_bugrpt_7.jpg
openBRF008_bugrpt_7-1.jpg
As expected from how the bones are shown pointing the wrong way in Blender.

There's still an import problem related to exporting. I can import an SMD into BRF but when I try to export it out I get this error:
openBRF008_bugrpt_1.jpg
SMDs I tested included native's, blender's, and openBRF's own exported SMD (ver 0.0.8 ).

One more exporting issue: It seems that it changes the SMD's material name to "material_name"? This gave me quite a bit of headache when I needed to import into Blender with textures (usually I import without textures but I need to import with textures to preserve the UV info), but it's an import script related problem which I managed to solve by copying a DDS file and renaming it as "material_name" and placed it in the same directory as the SMD. Though it'd be nice if in the future openBRF exports with the material reference given in the BRF, I wouldn't have known what the problem was if the import script didn't tell me what to look for!

Tul: problem with the import of rigged mesh "kind of" fixed. It was related to that >4 bones per vertex. But, even if now it load them, it is a bad idea to allow >4 bone per vertices as M&B will not use them. Thanks for the data!
Good info, I'll keep that in mind.

...

Whew!

Sorry for the long winded bug report, took me about a couple of hours to write it up with countless edits so hopefully it isn't confusing. There's bound to be some contextual errors I left in it. At any rate, great progress so far. At the very least I can still use this to import rigged SMDs+vertex animation (now I can import those female armors, yeehaw!)*. Keep up the great work!

*I just found out the Blender export script I use can't export animation sequences, I found another export script that can but need to test it thoroughly first.
 
Yeah, I forgot to mention it, too. Exporting with BRFEdit, the skeleton was "numbered". This time it's named. Did you add that feature, mtarini?

cdvader

EDIT: If you look in skeleton_bodies.xml in Mount&Blade/Data, you can see they're named there, as well.
 
:grin: WOW Today is a remarkable date in the M&B history  :wink:, an Open B... R... F... editor (oh my mum :razz:) thats cool. And with skeletal anim support...  :eek: :eek: :eek:. Youre a crack (Really a good soft) I have waiting for this a lot of time ago...

PD: Thanx to releasing the code, I will modify it. What license type have the software  :smile:  GNU... :cool: CC... post it... and you are a genius, guy.
 
Thanks for the very detailed report, will be very useful!



Part one:
  [skeleton: OpenBrf => Blender]  causes wrong looking bones.

(that is, the skeleton as exported by OpenBrf reimported by Blender)
(first image on your report). I thnk I understood what geos wrong...

But, help me understand (I'm not familiar with blender):
it is that the bold segments (with a larger point at the end) should be oriented differently, right?...
If so, I try to fix that.
It is not the fact that bones are diamond shaped, right? If so: they are just random 3D shapes I put there.
(If you prefer to have a skin (collection of rigged mesh) to cover the skeleton, there is an option to do that).




Part two:
  [rigged mesh: OpenBrf => Blender (edit) => OpenBrf ] = assertion failed (crash)
  [rigged mesh: OpenBrf => Blender (edit) => Blender ] = "error: invalid literal"

I understand that blender was not able to understand its own output either.
If so, it seems a problem with Blender export.
By looking at the error messages of both appliation, I think blender is mistakenly putting bone names instead of bone numeric-ID in the exported rigged meshes.

Old M&B skeleton format did not have bone names, so old BRFedit assigned to the bone number 0 the name "0", and the problem did not arise.
But the new skeleton format in M&B intedoduced bone names (I guess it was for ragdolling), so now blender cannot get away
with that error. (btw openBRF can read old format Brf skeletons).

As a fix, I could make BrfEdit export skeletons with numeric names as before, but losing original name information would be bad in other scenarios. I'll have to put it as an option. Unless, your new blender script stays clear from that porblem... let me know

Can I have the SMD file that was exported by blender to check this hypotesis?


Part 3:
  [Rigged mesh: BrfEdit => OpenBrf ] = ghost looking animation.

I would need the SMD data to see how it works..


Part 4:
  [Rigged mesh: anyApply => OpenBrf => ... ] 
  including:
  [Rigged mesh: OpenBrf => OpenBrf => ...  ] 
  casuse assertion failed on the second "=>"

Good find. I can replicate this on my own, right?


Part 5:
  Material names... good to know. W
  ould you prefer to have the material name there, or the texture name? If the latter, with or without the ".dds"?

 
Part one:
Sorry 'bout that, here's a clearer image using octahedron bones:
openBRF008_bones_bugrpt.jpg
Yep, it's the bold points in the image from the earlier post. For reference, the model is supposed to be facing us (along +y axis - the green arrow in the image).

Part two:
I don't think it's worth fixing this for openBRF if it only affects this particular script, especially since the script can't export animation sequences. The script's output still works well with BRFedit. If you're interested, the script is available here: http://forums.taleworlds.com/index.php/topic,53186.msg1462302.html#msg1462302
Looking at the code may or may not shed some light on the problem. I don't have the SMD that gave the error in the previous post but another reoutputted SMD with the same problem is available here:
http://amade-wossname.com/tmp/mnb/BRF_openBRFexport_blenderImport_blenderExport.smd
(the naming convention here is the order in which the SMD went through before it's in its final output)
I think you're right that the problem is more with the script. Also, I think I prefer named bones better than numbered ones.

Part 3:
This one you can replicate yourself actually, the SMD (any valid model) has to be exported from any existing BRF using openBRF. Then, if you import it into a BRF using BRFedit you get the error:
openBRF008_bugrpt_7-1.jpg
I guess it's related to the problem in Part 1. BRFedit reads it the same way as Blender did: bones rotated the wrong way. Sorry if I wasn't clear before.

Part 4:
Yeah, I reckon you should be able to replicate it yourself. As a summary of my error, as long as the SMD has been imported by openBRF (regardless of its original source), openBRF won't export it back out.

Part 5:
Hard to say... the import script is quite old, I think it was back before Blender can natively read DDS files. The error for the missing material varies with SMDs of various sources but I sometimes get an error which tells me that a ***.DDS file was missing and when I put it in the same directory as the SMD the import script works fine and I can even see the texture in Blender. So I think when openBRF exports the SMD it should give the material name according to the texture file's full name (includes the DDS extension). I'm not sure how other program's importer would work so it's best to take a sounding on this before you make any changes and break it for them ;')

Another bug I just noticed while looking through Revenge of the Berserk's BRF was that sometimes the texture does not show up although the material and texture reference was correct (and the DDS is present in its folder).
openBRF008_bugrpt_8.jpg
Viewing the same BRF in BRFedit shows the textures correctly for both models.
 
Can I just request you warn us if you make alterations to fit blender in? Because import/export are working perfectly for me atm
 
Dain Ironfoot said:
Can I just request you warn us if you make alterations to fit blender in? Because import/export are working perfectly for me atm

Really? What program are you using?
 
Dain Ironfoot said:
Can I just request you warn us if you make alterations to fit blender in? Because import/export are working perfectly for me atm

Of course I will!
At worst, I'll make differentiated import/export procedures, but I don't think that will be needed.
If everything goes as I expect, the new ways should make everybody happy, and could fix the other problem with root bone positioning too.
 
mtarini, I've found an extremely big bug. On the main page it says "version 0.0.8 Alpha" but in OpenBRF it says "version 0.0.9 Alpha".

:lol: cdvader.

EDIT: Ok, on a more serious note, it seems that OpenBRF displays animations "flipped". Basically, the sword is in the left hand and the shield is in the right. The perfect example of this is the animation "right_swing" in "uni_swings.brf" . It's supposed to swing with the right hand, but instead, it's all flipped and swings with the left.

It's just like how BRFEdit seemed to flip textures.
 
Yep, BRFedit mirrors the mesh. Not the textures, they just get mirrored along with the mesh.
So the anim we see in openBRF is "correct" as we'll see it mirrored in game.

cdvader said:
mtarini, I've found an extremely big bug. On the main page it says "version 0.0.8 Alpha" but in OpenBRF it says "version 0.0.9 Alpha".

:lol: didn't notice that one!
 
Back
Top Bottom