Download link and main info! [latest ver 0.0.82e -- 19 Jun 2016]
- Thread starter mtarini
- Start date
Users who are viewing this thread
WilliamBerne
Master Knight
secend this!Fei Dao said:It'd be a nice addition if this tool had a feature to autosort entries by alphabetical order.
I'd also like an auto-sort by name, good suggestion.
Would it also be possible to add a slider control to the animations tab? Some animations are really long, and it would be a lot easier to just be able to move a slider, then having to either watch the entire animation, click up/down, or type in frames, etc.
Would it also be possible to add a slider control to the animations tab? Some animations are really long, and it would be a lot easier to just be able to move a slider, then having to either watch the entire animation, click up/down, or type in frames, etc.
KaiserSkullz
Regular
So far So good, its a great program, I was wondering how to change the module file its looking at to my module file instead of native? otherwise it wont read any of my texture files. Thanks Much!
KaiserSkullz
Regular
just tried that and it still says the module is (native) and when I do a search in module I cant find any of my files so its still looking at native?
Edit: also for whatever reason when I import my new mesh its way above the skeleton im trying to rig it to?
Edit: also for whatever reason when I import my new mesh its way above the skeleton im trying to rig it to?
Not really
[!] I found a great bug in the SMD importer, when trying to import an anim which skeleton is situated lower than the ground line ( < 0) for example, the legs of a guy sitted. OpenBRF puts the anim at the same height that the reference frame. I mean raised of the ground. This bug does not exists if the anim is "flying style" I have tryed many times but this looks to be an OBRF SMD importer bug. Here's a little sketch:
#0
#0 #()_
#()_ <-- Guy sitting [in 3D Max] ###|_ <-- Guy "Flying" [in OpenBRF]
###|_
^
|_ Ground Line Z=0
#0
#0 #()_
#()_ <-- Guy sitting [in 3D Max] ###|_ <-- Guy "Flying" [in OpenBRF]
###|_
^
|_ Ground Line Z=0
Swyter: I think that's only that OpenBRF assumes that the 1st frame is the reference frame (the T pose). That frame itself is discarded, but used to establish the absolute position of subsequent frames. So just add the T pose frame to your SMD animations. (Maybe 3DS has an option do to so on export?). Maybe I should add an option to control that behaviour? I've read somewhere that SMD animations are supposed to have that 1st frame.
Barf: decimate numbers... ok, good idea, thanks. Will do.
Shik & othes: alphabetic order... yes good idea.
KaiserSkullz: maybe you have a problem with paths? make sure openbrf is in a standard, ascii only path (no chinese characters, etc). Also, that so is your module and M&B. OpenBRF only understands ascii paths (from starti, e.g. "C:\" to end). Sorry about that.
Barf: decimate numbers... ok, good idea, thanks. Will do.
Shik & othes: alphabetic order... yes good idea.
KaiserSkullz: maybe you have a problem with paths? make sure openbrf is in a standard, ascii only path (no chinese characters, etc). Also, that so is your module and M&B. OpenBRF only understands ascii paths (from starti, e.g. "C:\" to end). Sorry about that.
Hmmm... yeah, simple its better; sorry marcomtarini said:
I have been hasty. Post deleted. Is that a common animation technique? In the battle for Middle-Earth 2 (SAGE engine) was exactly the same that SMD... No problem, me and Hokie were wondering why the guys were floating in the SW cantina...mtarini said:
PD: Someone has posted something about default SMD exporting horses with human skeletons... maybe you could check it
Dain Ironfoot
Count
It was a vaguely planned feature at one point I think.
Oddly I can't find the transfer rigging command in the latest version.
Oddly I can't find the transfer rigging command in the latest version.
killkhergit
Squire
WilliamBerne said:secend this!Fei Dao said:It'd be a nice addition if this tool had a feature to autosort entries by alphabetical order.
You got another vote for that one!
I got another suggestion concerning the Combine tool. Can you add a "Remove old parts" option to it?
Dain Ironfoot said:
I changed the way you do that. First, you select copy (ctrl+C) the rigged mesh(-es), then you select the mesh(-es) you want to rig, and you [edit]->[paste rigging].
It seemed a better way. First, more natural. Also, that way you can transfer rigging *from* multiple exemplar meshes (not only *to*) -- transferring from multiple meshes can work better. Also, that way the meshes you copy rigging from are not constrained to be on the same brf file as the destination meshes anymore.
Did the sorting tool, but don't have time to update it on the server! Soon...
killkhergit said:
What parts should be removed? How do I identify "old" parts? Maybe what you are looking for can be achieved with the "paste modifications" tool?
killkhergit
Squire
mtarini said:
The selection the user makes to combine.
so... update!
GUI note: the sort tool is in a new "tool" menu. A little inelegant maybe... but all the option you access with the right click are relative to selected things, that that is not the case.
The more robust way to assemble vertex animation frames means that texture coords are still used to tell vertices apart, as before, but now if two vertices have the same text coords, than the closer vertex is selected. That tends to work a lot better.
The "quiver" mode to assemble frames is made for making quivers animations... you know, each frame is a quiver for a different number of arrows left. (actually, missing arrows are not really missing, they are just shrunk to nothing and hidden somewhere). In OpenBRF, that's how you can do that: first you make the frame with all the arrows. Each subsequent frame works as follows: any object that is displaced, in any way, w.r.t. the 1st frame, is just collapsed to a point (and thus disappears). You activate this mode under [settings]->[on assemble frames].
edit: As for the "horse exported with human skeleton" bug: now a rigged mesh is exported with the skeleton currently selected to view the animation.
Killkhergit: sorry! I still don't understand. You select mesh A and mesh B. By "combining" them, you make a new mesh containing both A and B. What should be considered "old" and removed? The sub-parts that were contained in both A and B?
GUI note: the sort tool is in a new "tool" menu. A little inelegant maybe... but all the option you access with the right click are relative to selected things, that that is not the case.
The more robust way to assemble vertex animation frames means that texture coords are still used to tell vertices apart, as before, but now if two vertices have the same text coords, than the closer vertex is selected. That tends to work a lot better.
The "quiver" mode to assemble frames is made for making quivers animations... you know, each frame is a quiver for a different number of arrows left. (actually, missing arrows are not really missing, they are just shrunk to nothing and hidden somewhere). In OpenBRF, that's how you can do that: first you make the frame with all the arrows. Each subsequent frame works as follows: any object that is displaced, in any way, w.r.t. the 1st frame, is just collapsed to a point (and thus disappears). You activate this mode under [settings]->[on assemble frames].
edit: As for the "horse exported with human skeleton" bug: now a rigged mesh is exported with the skeleton currently selected to view the animation.
Killkhergit: sorry! I still don't understand. You select mesh A and mesh B. By "combining" them, you make a new mesh containing both A and B. What should be considered "old" and removed? The sub-parts that were contained in both A and B?
killkhergit
Squire
Great, thank you for the new release mtarini!
I just thought of something that might be useful for those of us working on teams:
Lots of people on our team make updates to .brf files, but it is often difficult to see exactly what changed in the .brf (especially when people don't fill in their change logs). I don't know if this fits into the .brf format, but could a last modified date somehow be added for each mesh, texture,material, collision, etc...?
I just thought of something that might be useful for those of us working on teams:
Lots of people on our team make updates to .brf files, but it is often difficult to see exactly what changed in the .brf (especially when people don't fill in their change logs). I don't know if this fits into the .brf format, but could a last modified date somehow be added for each mesh, texture,material, collision, etc...?
