After more than a year, a new version!
More data:
1- From rigged Mesh to Vertex ani
Vertex animations can be constructed either from a selected skeletal animations
(selecting a reference "skin" and a "skeleton")
or from a selected rigged mesh (selecting a reference "skeletal animation" and a "skeleton").
Be warned that vertex animations (where xyz+normal vertex data is repeated for each frame) can be
quite space consuming. If you try to produce anything bulkier than 5 MB, OpenBRF will warn you in advance.
There aren't probably many uses in M&B modding for this, but it is a tool I wanted to have.
(Remeber in OpenBRF you can compose your custom skins for previewing skeletal animations...
the skins are kept in a "reference.brf" data which is, by default, specific for each module).
2- Shadows in animation renderings
When you display a skinned animation, OpenBRF will now show an accurate shadow under it.
That can be useful to understand the action, especially with respect to the ground.
Anyway, you can disable that, together with the gridded floor. Do that if if goes too slow.
Ability to disable floor was suggested by "[thick1988]"
They look like this:
See? They make it easier to see what's going on.
3- Prop text creation
the new tool to generate props is found under [Module] tools, at the end.
It will produce the code snippet, coded as the Python-esque code expected by M&B/WB module system,
which lists each mesh in the current file as a scene prop (if case you don't know, a scene prop is a usually static
3D element of a M&B scene). If a matching collision "body" is found in the current file, it is added to the description of the
respective scene prop. As usual, it is just a bit of automatization. After a suggestion by [Harry_].
The results is copyed in the clipboard, so you can paste it in your "module_scene_props.py" or whatever.
For example, it might create a text like:
4- Export Vertex ani as OBJ sequence
when you export a vertex animation, now you can opt to save it as a sequence of obj files, one for each frame
(like: <name>.000.obj, <name>.001.obj, and so on), instead of as a single SMD file. Why? Just so.
You access this option by changing the format when you are exporting the vertex animation.
5- Navigate from Mesh to Collision objects
You know how, pressing shift+right and shift+left, you "navigate", going "right", from a Mesh to its Material, to its Texture (or its Shader, or its Bump); and back, going "left" (BTW these commands are also found under [Module]=>[Navigate] ).
The new thing is that now, going "left" from a mesh, you go to its "collision object", the one that is named "bo_<mesh name>" (a standard convention), and back with "right". But only if that collision object is to be found in the same brf file, cos I'm lazy.
6- Small improvements
- When, as multiple objects are selected, the view screen is splitted, layout is chosen somewhat better.
- The "auto" mode to visualize combined selections is now the default (if you remember, it is the mode where meshes matching names, like "castle.1" and "castle.2" are combined, LODs are hidden, and everything else is seen side-to-side)
- When you select and copy (ctrl+C) multiple things, all their names are copyed to the clipboard as text, not just one.
- apart from that, many small things, including a bit of reshuffling of menus, and stuff like:
6- ... and fixes
- Main fix: following some report and discussion with [xenoargh] (thank you!!!) both the cleaning operation ("removal of redundant vertex/pos") and the (optional) automatic cleaning of meshes should be more respectful of crease edges in the input mesh.
I am not sure this solved all the issues reported by [xenoargah].
Remember that if you want to smooth out creases to save (vertex and pos counts), you can recompute normals (either
automatically on mesh load, or on the meshes you select)
Hot-fix (+b,+c): more fixes
- also fixed order reversion during cut-n-paste (bug reported by [somebody])
Hot-fix (+d): Important fix!
- fixed a *bad* bug crashing OpenBRF. Happens when one updates all underliing libraries at once.
Plus:
- smarter way to guess whether or not use alpha blend (according to material), thanks [rgcotl]
- multiple selections can now be happily moved up and down, just as single ones (with alt-up/and down).
Hot-fix (+e), (10 jun): More correct "Alpha test" values
Now OpenBRF actually uses, as alpha test value, the value determined by material flag.
Recall that this value can be modified by clicking on the "flag" button in the "material" data box,
Explaination: that value determines how cutouts (over textures with alpha) are rendered (both in game and in OpenBRF preview, hopefully).
The larger the value is, the tighter cutouts are; the smaller, the larger margins are left around the solid parts of the objects.
For example, here is how a native tree model looks like, according to OpenBRF, with
Alpha test = "8/256", "136/256", and "251/256", respectively i.e. the three settings you can set on the flags.
A close up:
(Native uses "136/256" for the material of this mesh: the middle image)
In this case:
- Small Alpha test value (8/256) = background problems (left)
- Medium Alpha test value (136/256) = decent (middle)
- Large Alpha test value (251/256) = too thin, disappearing branches, pixelated look (right)
ver 0.0.80(+d) -- "long time no see" release (09 Jun 2013)
Small things. Probably incomplete list:
1- new tool to construct vertex animation from rigged meshes
2- added an (optional) shadow when visualizing skinned animations
3- new tool to export string for module's scene-prop python code (for all objects in a brf file)
4- ability to save vertex animations as sequences of obj files
5- module "navigation" (shift+left / shift+right) also goes from mesh to its collision object, if present
6- a few fixes and ameliorations (maybe)
More data:
1- From rigged Mesh to Vertex ani
Vertex animations can be constructed either from a selected skeletal animations
(selecting a reference "skin" and a "skeleton")
or from a selected rigged mesh (selecting a reference "skeletal animation" and a "skeleton").
Be warned that vertex animations (where xyz+normal vertex data is repeated for each frame) can be
quite space consuming. If you try to produce anything bulkier than 5 MB, OpenBRF will warn you in advance.
There aren't probably many uses in M&B modding for this, but it is a tool I wanted to have.
(Remeber in OpenBRF you can compose your custom skins for previewing skeletal animations...
the skins are kept in a "reference.brf" data which is, by default, specific for each module).
2- Shadows in animation renderings
When you display a skinned animation, OpenBRF will now show an accurate shadow under it.
That can be useful to understand the action, especially with respect to the ground.
Anyway, you can disable that, together with the gridded floor. Do that if if goes too slow.
Ability to disable floor was suggested by "[thick1988]"
They look like this:
See? They make it easier to see what's going on.
3- Prop text creation
the new tool to generate props is found under [Module] tools, at the end.
It will produce the code snippet, coded as the Python-esque code expected by M&B/WB module system,
which lists each mesh in the current file as a scene prop (if case you don't know, a scene prop is a usually static
3D element of a M&B scene). If a matching collision "body" is found in the current file, it is added to the description of the
respective scene prop. As usual, it is just a bit of automatization. After a suggestion by [Harry_].
The results is copyed in the clipboard, so you can paste it in your "module_scene_props.py" or whatever.
For example, it might create a text like:
Code:
# from 'arabian_castle.brf': begin (OpenBRF)
( "arabian_castle_battlement_a" ,0,"arabian_castle_battlement_a","bo_arabian_castle_battlement_a",[]),
( "arabian_castle_battlement_b_destroyed" ,0,"arabian_castle_battlement_b_destroyed","bo_arabian_castle_battlement_b_destroyed",[]),
( "arabian_castle_corner_a" ,0,"arabian_castle_corner_a","bo_arabian_castle_corner_a",[]),
( "arabian_castle_stairs" ,0,"arabian_castle_stairs","bo_arabian_castle_stairs",[]),
( "arabian_castle_battlement_c" ,0,"arabian_castle_battlement_c","bo_arabian_castle_battlement_c",[]),
( "arabian_castle_battlement_section_a" ,0,"arabian_castle_battlement_section_a","bo_arabian_castle_battlement_section_a",[]),
( "arabian_castle_stairs_b" ,0,"arabian_castle_stairs_b","bo_arabian_castle_stairs_b",[]),
( "arabian_castle_battlement_d" ,0,"arabian_castle_battlement_d","bo_arabian_castle_battlement_d",[]),
( "arabian_castle_gate_house_a" ,0,"arabian_castle_gate_house_a","bo_arabian_castle_gate_house_a",[]),
( "arabian_castle_house_a" ,0,"arabian_castle_house_a","bo_arabian_castle_house_a",[]),
( "arabian_castle_house_b" ,0,"arabian_castle_house_b","bo_arabian_castle_house_b",[]),
( "arabian_castle_stairs_c" ,0,"arabian_castle_stairs_c","bo_arabian_castle_stairs_c",[]),
( "arabian_castle_keep_a" ,0,"arabian_castle_keep_a","bo_arabian_castle_keep_a",[]),
( "arabian_castle_corner_b" ,0,"arabian_castle_corner_b","bo_arabian_castle_corner_b",[]),
# from 'arabian_castle.brf': end (OpenBRF)
4- Export Vertex ani as OBJ sequence
when you export a vertex animation, now you can opt to save it as a sequence of obj files, one for each frame
(like: <name>.000.obj, <name>.001.obj, and so on), instead of as a single SMD file. Why? Just so.
You access this option by changing the format when you are exporting the vertex animation.
5- Navigate from Mesh to Collision objects
You know how, pressing shift+right and shift+left, you "navigate", going "right", from a Mesh to its Material, to its Texture (or its Shader, or its Bump); and back, going "left" (BTW these commands are also found under [Module]=>[Navigate] ).
The new thing is that now, going "left" from a mesh, you go to its "collision object", the one that is named "bo_<mesh name>" (a standard convention), and back with "right". But only if that collision object is to be found in the same brf file, cos I'm lazy.
6- Small improvements
- When, as multiple objects are selected, the view screen is splitted, layout is chosen somewhat better.
- The "auto" mode to visualize combined selections is now the default (if you remember, it is the mode where meshes matching names, like "castle.1" and "castle.2" are combined, LODs are hidden, and everything else is seen side-to-side)
- When you select and copy (ctrl+C) multiple things, all their names are copyed to the clipboard as text, not just one.
- apart from that, many small things, including a bit of reshuffling of menus, and stuff like:
6- ... and fixes
- Main fix: following some report and discussion with [xenoargh] (thank you!!!) both the cleaning operation ("removal of redundant vertex/pos") and the (optional) automatic cleaning of meshes should be more respectful of crease edges in the input mesh.
I am not sure this solved all the issues reported by [xenoargah].
Remember that if you want to smooth out creases to save (vertex and pos counts), you can recompute normals (either
automatically on mesh load, or on the meshes you select)
Hot-fix (+b,+c): more fixes
- also fixed order reversion during cut-n-paste (bug reported by [somebody])
Hot-fix (+d): Important fix!
- fixed a *bad* bug crashing OpenBRF. Happens when one updates all underliing libraries at once.
Plus:
- smarter way to guess whether or not use alpha blend (according to material), thanks [rgcotl]
- multiple selections can now be happily moved up and down, just as single ones (with alt-up/and down).
Hot-fix (+e), (10 jun): More correct "Alpha test" values
Now OpenBRF actually uses, as alpha test value, the value determined by material flag.
Recall that this value can be modified by clicking on the "flag" button in the "material" data box,
Explaination: that value determines how cutouts (over textures with alpha) are rendered (both in game and in OpenBRF preview, hopefully).
The larger the value is, the tighter cutouts are; the smaller, the larger margins are left around the solid parts of the objects.
For example, here is how a native tree model looks like, according to OpenBRF, with
Alpha test = "8/256", "136/256", and "251/256", respectively i.e. the three settings you can set on the flags.
A close up:
(Native uses "136/256" for the material of this mesh: the middle image)
In this case:
- Small Alpha test value (8/256) = background problems (left)
- Medium Alpha test value (136/256) = decent (middle)
- Large Alpha test value (251/256) = too thin, disappearing branches, pixelated look (right)