Highlander
Marquis
Pretty awsome. Just noticed it today. Already imported my first animation successfully into game.
Download link and main info! [latest ver 0.0.82e -- 19 Jun 2016]
- Thread starter mtarini
- Start date
Users who are viewing this thread
Marquis
New version out! 0.0.10... I still need to update the first page, but it is already there online.
I tried to fix bugs and inconsistencies... the changes were quite deep I must say. Another struggle with quaternions matrices etc.
ATTENTION!!! The new version won't understand SMD files exported by previous versions!
Sorry about that... if that is a problem, I can make a temporary differentiated import.
In my intentions, the files it now export should still make 3DS as happy as before, and blender happier. Check?
General note: a few rigged meshes also have a "vertex animation" on. Frame 0 seems unused, frame 1 seems the masculine version, frame 2 the feminine version. When you export rigged mesh, OpenBrf export the frame currently displayed on screen. Be aware that frame 1 (the masculine version) seems identical to frame 0 (unused?) but usually it has better normals. So you may want to use that one instead.
amade:
I tried to fix all the bugs you reported, apart from the missing-texture one
(looking for textures in the appropriate disk space is for another day...
However, do I understand that the helmet worked while the armour didn't, in a identical situation? that would be weird. Maybe a corrupt). But, I didn't test how blender likes it now (hopefully, better).
As for the material names in SMD files... I've made so that when you re-import it, you'll find the material name correctly setup. So it is the material (not the texture), without path or ".dds".
cdvader:
The flipping of the animations... well, that's is just a preview issue...
I would keep it "manga-in-western-world" style for now. However, I'm curious.
All the rigged mesh I have are symmetrical so it is not easy to understand,
but I suspect that it could just be that the bone named "right-hand" is actually
the left hand... (the skin that comes bundled with the exe was just made by me
using OpenBrf itself... you can do your own. When you add a non-rigged part to it,
like weapon, hands, and hemets, OpenBrf will ask you "to which bone you want to attach that"...
I attached the weapon to the bone named "right hand", so if that was really the left hand...)
Dian:
Can you check if that error on root bone position is still there?
I never replicated that bug. I tried exporting and reimporting that animation and it worked fine...
Not having 3DS, I cannot test it more than that.
To summarize: checklist:
- export/import in 3DS? (is it still ok?)
- export/import in blender?
- root-bone position problem?
- are the rigged-mesh flipped, or is it just a bone-naming glitch in M&B?
(the other bugs which I could verify on my own should be ok)
I tried to fix bugs and inconsistencies... the changes were quite deep I must say. Another struggle with quaternions matrices etc.
ATTENTION!!! The new version won't understand SMD files exported by previous versions!
Sorry about that... if that is a problem, I can make a temporary differentiated import.
In my intentions, the files it now export should still make 3DS as happy as before, and blender happier. Check?
General note: a few rigged meshes also have a "vertex animation" on. Frame 0 seems unused, frame 1 seems the masculine version, frame 2 the feminine version. When you export rigged mesh, OpenBrf export the frame currently displayed on screen. Be aware that frame 1 (the masculine version) seems identical to frame 0 (unused?) but usually it has better normals. So you may want to use that one instead.
amade:
I tried to fix all the bugs you reported, apart from the missing-texture one
(looking for textures in the appropriate disk space is for another day...
However, do I understand that the helmet worked while the armour didn't, in a identical situation? that would be weird. Maybe a corrupt). But, I didn't test how blender likes it now (hopefully, better).
As for the material names in SMD files... I've made so that when you re-import it, you'll find the material name correctly setup. So it is the material (not the texture), without path or ".dds".
cdvader:
The flipping of the animations... well, that's is just a preview issue...
I would keep it "manga-in-western-world" style for now. However, I'm curious.
All the rigged mesh I have are symmetrical so it is not easy to understand,
but I suspect that it could just be that the bone named "right-hand" is actually
the left hand... (the skin that comes bundled with the exe was just made by me
using OpenBrf itself... you can do your own. When you add a non-rigged part to it,
like weapon, hands, and hemets, OpenBrf will ask you "to which bone you want to attach that"...
I attached the weapon to the bone named "right hand", so if that was really the left hand...)
Dian:
Can you check if that error on root bone position is still there?
I never replicated that bug. I tried exporting and reimporting that animation and it worked fine...
Not having 3DS, I cannot test it more than that.
To summarize: checklist:
- export/import in 3DS? (is it still ok?)
- export/import in blender?
- root-bone position problem?
- are the rigged-mesh flipped, or is it just a bone-naming glitch in M&B?
(the other bugs which I could verify on my own should be ok)
cdvader
Hooray, I shall start testing immediately...
cdvader
EDIT:
Status Update 1: The new version actually seems to still understand old SMD files exported by previous OpenBRF versions.
Status Update 2: In 3ds Max, the SMD is still bad.
Status Update 3: In Blender, the SMD is still bad.
Status Update 4: The rigged meshes are still flipped. Btw, they're only flipped in OpenBRF. Nowhere else, so it's not really that much of an problem.
cdvader
EDIT:
Status Update 1: The new version actually seems to still understand old SMD files exported by previous OpenBRF versions.
Status Update 2: In 3ds Max, the SMD is still bad.
Status Update 3: In Blender, the SMD is still bad.
Status Update 4: The rigged meshes are still flipped. Btw, they're only flipped in OpenBRF. Nowhere else, so it's not really that much of an problem.
Percus
Squire
"tools -> about (F1)" shows:
0.0.9 alpha
(12 August 2009)
did you forget to change it, or did I just downloaded the old version 1 minute ago?
btw: it is totally awesome that you do this! I love this tool and I didn't even use it yet! haha!
having custom animations... oh yea, it gets me all excited!
BYE BYE TWO HANDED OVERSWING ANIMATION, HAHAHAHA
once I find the time, I want to create some good looking animations... and as a fellow kendoka I totally have to create Kendo-stances for this game
0.0.9 alpha
(12 August 2009)
did you forget to change it, or did I just downloaded the old version 1 minute ago?
btw: it is totally awesome that you do this! I love this tool and I didn't even use it yet! haha!
having custom animations... oh yea, it gets me all excited!
BYE BYE TWO HANDED OVERSWING ANIMATION, HAHAHAHA
once I find the time, I want to create some good looking animations... and as a fellow kendoka I totally have to create Kendo-stances for this game
oops, it was the old version online... I must have messed something up with filezilla...
fixed now... care to check again? (it should say "version 0.0.10" in the menu)
Edit: it seems that kendo-combat moves can be added to kendo-sword with the module system, but it is not clear yet if a kendo-stance can be put in, without making it the only stance (regardless of which weapon is used). Let us know if you find a way.
Edit 2: the animations are still even supposed to be flipped.
fixed now... care to check again? (it should say "version 0.0.10" in the menu)
Edit: it seems that kendo-combat moves can be added to kendo-sword with the module system, but it is not clear yet if a kendo-stance can be put in, without making it the only stance (regardless of which weapon is used). Let us know if you find a way.
Edit 2: the animations are still even supposed to be flipped.
cdvader
Alright, re-testing.
cdvader
EDIT:
Status Update 1: The new version still seems to be able to read the old SMD files created by previous OpenBRF's.
Status Update 2: In 3ds Max, SMD's are still bad.
Status Update 3: In Blender, SMD's are still bad.
Is it still the old version online?
EDIT2: Says version 0.0.9 in the menu ... Just checked...
cdvader
EDIT:
Status Update 1: The new version still seems to be able to read the old SMD files created by previous OpenBRF's.
Status Update 2: In 3ds Max, SMD's are still bad.
Status Update 3: In Blender, SMD's are still bad.
Is it still the old version online?
EDIT2: Says version 0.0.9 in the menu ... Just checked...
Ooops then I'm dumb. Triple checked this time. It is the new version now.
(beside, didn't 3DS max exports looked fine even before?)
Edit: thanks for the patience Cdvader and Percus!
I share the blame with 7zip, which, on an attempt to update a zip file which is already open, silently freezes making me think that it did update it -- probably a Vista issue
(beside, didn't 3DS max exports looked fine even before?)
Edit: thanks for the patience Cdvader and Percus!
I share the blame with 7zip, which, on an attempt to update a zip file which is already open, silently freezes making me think that it did update it -- probably a Vista issue
cdvader
[quote author= mtarini](beside, didn't 3DS max exports looked fine even before?)[/quote]
Nope.
Anyway,
Status Update 1: New version doesnt read old SMD files exported using previous OpenBRF's.
Status Update 2: 3ds Max still doesn't like the SMD files OpenBRF exports.
Status Update 3: Blender still doesn't like the SMD files OpenBRF exports.
I double checked - The SMD files OpenBRF exports are only "good" in Fragmotion. But I dislike that program greatly, so I'm still waiting for a 3ds Max SMD exporter.
[quote author= mtarini]thanks for the patience Cdvader and Percus![/quote]
No problems.
cdvader
Nope.
Anyway,
Status Update 1: New version doesnt read old SMD files exported using previous OpenBRF's.
Status Update 2: 3ds Max still doesn't like the SMD files OpenBRF exports.
Status Update 3: Blender still doesn't like the SMD files OpenBRF exports.
I double checked - The SMD files OpenBRF exports are only "good" in Fragmotion. But I dislike that program greatly, so I'm still waiting for a 3ds Max SMD exporter.
[quote author= mtarini]thanks for the patience Cdvader and Percus![/quote]
No problems.
cdvader
cdvader said:
But! but! I wasn't aware that we had a 3DS problem. Dian Ironfoot was already using 3DMax!
What does 3DS do? Does it open them? What is the problem?
cdvader said:
I was hoping differently... are bone like before, or are they on a different wrong direction?
They should at least be different! And I was really hoping it was the correct one.
cdvader
[quote author= mtarini]But! but! I wasn't aware that we had a 3DS problem. Dian Ironfoot was already using 3DMax!
What does 3DS do? Does it open them? What is the problem?[/quote]
Well, I think I posted that 3ds had the bone problem too. But anyway, if I export a skeleton, animation or anything regarding bones from OpenBRF and Import it in to 3ds Max, I get the extremely messy bones. Click me! A video about the problem. I'm using 3ds Studio Max 2009 along with the Import/Export scripts I got from Wunderboy.
[quote author= mtarini]I was hoping differently... are bone like before, or are they on a different wrong direction?
They should at least be different! And I was really hoping it was the correct one.[/quote]
Well, the bones currently look exactly like Amade posted them.
What does 3DS do? Does it open them? What is the problem?[/quote]
Well, I think I posted that 3ds had the bone problem too. But anyway, if I export a skeleton, animation or anything regarding bones from OpenBRF and Import it in to 3ds Max, I get the extremely messy bones. Click me! A video about the problem. I'm using 3ds Studio Max 2009 along with the Import/Export scripts I got from Wunderboy.
[quote author= mtarini]I was hoping differently... are bone like before, or are they on a different wrong direction?
They should at least be different! And I was really hoping it was the correct one.
[/quote]Well, the bones currently look exactly like Amade posted them.
amade
Grandmaster Knight
Blimey! Another morning, another version! I hope you're not running out of steam for working so hard on this, mtarini Really appreciate your work on this!
Maybe it's always worked the same way for Dain? If he had followed the new animation tutorial by cdvader 3ds can still import it (but with misrotated bones like Blender - as cdvader had reported too for 0.0.8/9), make changes, export it, and then imported using openBRF the bones would rerotate into their correct position.
So in a sense, it's still working for 3ds... Just as it's working for Blender (though blender's export script didn't work for openBRF in certain conditions as reported earlier). The only problem is that the bones are still misrotated when exported out from openBRF.
Okay for test/bug report. Referring to the previous bug reports:
Part 4: Importing into openBRF and exporting it out doesn't cause assertion error anymore. I can import-export-import-export as many times as I want.
Part 1 & 3: Bones are still rotated the wrong way, but there's a slight difference to it now -
They're rotated 180 degrees the other way around from previous version (though I'm not sure along which axis!).
Part 2: I don't mind much about the old Blender exporter. It still does it job, though not for SMDs exported from openBRF 0.0.8/9. As mentioned before I'm currently testing a new export script which supports exporting animation sequences but there's a problem with the script where it adds a dummy bone into the SMD (for HL2, I think). BRFedit imports them fine and removes the dummy bone when I import it, but if I try importing using openBRF it simply crashes with the default Windows error: openBRF.exe has encountered a problem and needs to close yadda yadda - the despised, generic, not very detailed error message.
edit: here are the SMD outputs of the script if you want to have a look at 'em:
http://amade-wossname.com/tmp/mnb/newscripts_SMD_exporter_output.zip
There were 2 versions of the script. The older one (ver1.0) adds the dummy bone into the SMD. The newer version (v1.03), requires me to add the bone (a new armature) in Blender myself or else it'd not export properly (weird and weirder!). The output of both versions are very similar if you open it with a text editor, both versions crash openBRF. I tried having a look into the .py exporter script but it's way beyond me to determine which part forces the script to ask/add the dummy bone into the SMD. Extra note: If I import these SMDs into BRFedit and export it back out again, openBRF will be able to read them. But this renders the whole exercise pointless since BRFedit can't import/export animation sequence.
Part 5: Naming convention for material works fine, easier to know what to expect now :')
(new)Part 6:
Really appreciate your work on this!Maybe it's always worked the same way for Dain? If he had followed the new animation tutorial by cdvader 3ds can still import it (but with misrotated bones like Blender - as cdvader had reported too for 0.0.8/9), make changes, export it, and then imported using openBRF the bones would rerotate into their correct position.
So in a sense, it's still working for 3ds... Just as it's working for Blender (though blender's export script didn't work for openBRF in certain conditions as reported earlier). The only problem is that the bones are still misrotated when exported out from openBRF.
Okay for test/bug report. Referring to the previous bug reports:
Part 4: Importing into openBRF and exporting it out doesn't cause assertion error anymore. I can import-export-import-export as many times as I want.
Part 1 & 3: Bones are still rotated the wrong way, but there's a slight difference to it now -
Part 2: I don't mind much about the old Blender exporter. It still does it job, though not for SMDs exported from openBRF 0.0.8/9. As mentioned before I'm currently testing a new export script which supports exporting animation sequences but there's a problem with the script where it adds a dummy bone into the SMD (for HL2, I think). BRFedit imports them fine and removes the dummy bone when I import it, but if I try importing using openBRF it simply crashes with the default Windows error: openBRF.exe has encountered a problem and needs to close yadda yadda - the despised, generic, not very detailed error message.
edit: here are the SMD outputs of the script if you want to have a look at 'em:
http://amade-wossname.com/tmp/mnb/newscripts_SMD_exporter_output.zip
There were 2 versions of the script. The older one (ver1.0) adds the dummy bone into the SMD. The newer version (v1.03), requires me to add the bone (a new armature) in Blender myself or else it'd not export properly (weird and weirder!). The output of both versions are very similar if you open it with a text editor, both versions crash openBRF. I tried having a look into the .py exporter script but it's way beyond me to determine which part forces the script to ask/add the dummy bone into the SMD. Extra note: If I import these SMDs into BRFedit and export it back out again, openBRF will be able to read them. But this renders the whole exercise pointless since BRFedit can't import/export animation sequence.
Part 5: Naming convention for material works fine, easier to know what to expect now :')
(new)Part 6:
I'm almost certain that openBRF is showing it right, it's the same with BRFedit. Whatever we see in BRFedit/openBRF gets flipped in M&B (not just rigged meshes I think) so it's prob'ly just a bone naming glitch. If you want to flip just the preview and not the mesh in openBRF I don't see why not. Would save us from any more confusion.
cdvader
Hey, you're right! At first I examined them both and I didn't see a difference (Probably because they were simply swapped/rotated ... and it's almost 3 o' clock in the morning). But now, I examined closer and I've noticed that there is, indeed, a change.
They're the same as Amade's (In my screenshots, the view is from "behind" or "back". Not a frontal one like Amade's). Is this a breakthrough? BTW: Sorry mtarini for lying to you in PM (didn't do it on purpose).
cdvader
They're the same as Amade's (In my screenshots, the view is from "behind" or "back". Not a frontal one like Amade's). Is this a breakthrough?
BTW: Sorry mtarini for lying to you in PM (didn't do it on purpose). cdvader
Percus
Squire
I don't want to be a nitpicker (or whatever it is called) but it looks more like it is mirrored on the y-axis than rotated... just have a look at the item.R from the first pic. it sticks kinda out where the item.L sticks "in" (if you can say that). On the second screenshot from the newer version you see the exact opposite; item.R sticking in, item.L sticking out.amade said:Part 1 & 3: Bones are still rotated the wrong way, but there's a slight difference to it now -
They're rotated 180 degrees the other way around from previous version (though I'm not sure along which axis!).
not sure if it helps in any way...
amade
Grandmaster Knight
Percus said:I don't want to be a nitpicker (or whatever it is called) but it looks more like it is mirrored on the y-axis than rotated... just have a look at the item.R from the first pic. it sticks kinda out where the item.L sticks "in" (if you can say that). On the second screenshot from the newer version you see the exact opposite; item.R sticking in, item.L sticking out.amade said:Part 1 & 3: Bones are still rotated the wrong way, but there's a slight difference to it now -
They're rotated 180 degrees the other way around from previous version (though I'm not sure along which axis!).
not sure if it helps in any way...
It looks like it's mirrored, but I'm pretty sure that with bones you rotate 'em on their local axis (not on the global axis). If the bones are mirrored, that would cause a lot of havoc I think
cdvader
Yup, I once 'tried' to mirror a skeletal animation... Exporter wouldn't even let me export the scene.
Percus
Squire
well then the only axis left for the bones to rotate around resulting in what you showed would be their local Z-axis... no?
and it looks like the pivot is the end of each bone... I mean... well, its hard to explain for me, check this:
this should the the part of the bone which is connected to it's parent bone, right?
Is OpenBRF maybe rotating all child-bones on that very pivot by 90° CCW when their x-value is positive, and vice versa for negative x-values?
it's just a guess...
and it looks like the pivot is the end of each bone... I mean... well, its hard to explain for me, check this:
Is OpenBRF maybe rotating all child-bones on that very pivot by 90° CCW when their x-value is positive, and vice versa for negative x-values?
it's just a guess...
amade
Grandmaster Knight
Percus said:well then the only axis left for the bones to rotate around resulting in what you showed would be their local Z-axis... no?
and it looks like the pivot is the end of each bone... I mean... well, its hard to explain for me, check this:
this should the the part of the bone which is connected to it's parent bone, right?
Is OpenBRF maybe rotating all child-bones on that very pivot by 90° CCW when their x-value is positive, and vice versa for negative x-values?
it's just a guess...
Well, looking at just the screenshots it looks as if they've been rotated on the local z-axis. However, it could've also been rotated from either the x or y axis axis and it would have looked the same - but the result is different.
Bone at rest.
Bone z-rotated.
Bone x-rotated.
Now imagine if the mesh's arm is rigged to it. You'd get twisted deformations if you rotate them the wrong way
Now that I think of it, there is a way to see which way the bones have been rotated by selecting the bones and going into edit mode with the axes display enabled. Then you can compare them to see which way they've been (mis)rotated.
But I assume that mtarini already knows which way he's rotated the bones.
Dain Ironfoot
Count
Blimey! Another morning, another version! I hope you're not running out of steam for working so hard on this, mtarini
Maybe it's always worked the same way for Dain? If he had followed the new animation tutorial by cdvader 3ds can still import it (but with misrotated bones like Blender - as cdvader had reported too for 0.0.8/9), make changes, export it, and then imported using openBRF the bones would rerotate into their correct position.
So in a sense, it's still working for 3ds... Just as it's working for Blender (though blender's export script didn't work for openBRF in certain conditions as reported earlier). The only problem is that the bones are still misrotated when exported out from openBRF.
I followed no tutorial. I just did it the normal way. Export, import into max, edit, export, import into OpenBRF. Works perfectly for me, no need for any tutorial?. No weird rotated bones or any of that stuff.
Tutorials.. pah. I've been playing for animations for quite a while (Since 0.80
and Mtarini's software works brilliantly and solves all my problems. Use a better importer.. I've never heard of Wunderboy, I use another.
Got to report the riding animation bug is still there though. I can chuck over the SMD Mtarini, it seems as soon as it passes through max, the error appears.. it's fine if you just export/import straight back into OpenBRF.
cdvader
Dain, please tell me what version of 3ds max are you using and what Importer/Exporter ?
