Update log [latest version: 0.0.82e -- 19 Jun 2016]

Users who are viewing this thread

Status
Not open for further replies.
After more than a year, a new version!

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:
shadow_1.png
 
shadow_2.png

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.
tree_a.png

A close up:
tree_b.png

(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)
 
 
new version!

mtarini said:
ver 0.0.81b -- "materials and usability" release
1- more faithful renderings, i.e. more material settings will cause OpenBRF to do what the game does!
    this is the list of material features which should now be correctly previewed on meshes
    (*) "render order" and "render 1st" flag
    (*) transparency mode (blend, add, mult...)
    (*) "uniform lighting" flag
    (*) "no depth test", "no z-write" flags
2- more flags documented, and errors corrected
3- usability improvements
  (*) after starting OpenBRF, hitting ctrl+R [R]eloads last loaded file
  (*) when visualizing stuff in several sub-windows, double clicking on any of them
    selects the corresponding objects
  (*) double click on an object in the list selects all its components
4- the usual fixes and minor improvements


First of all, I should thank [cmpxchg8b] for, once again, having provided lots of precious informations about the
actual meaning of the flags used by OpenBRF. I bugged him a lot in this thread.
Otherwise I could not implement points 1 and 2 above.
He now has his own "acknowledgment" section now in the about screen (hit F1 in OpenBRF).
That information is used in two ways in OpenBRF: first, to just let users more accurately know what the flags will be doing. Second, to let OpenBRF previews emulate better what the game will be doing one you run it.


So, about the points...

1- more faithful renderings, i.e. more material settings will cause OpenBRF to do what the game does!
Below is the list of material features which should now be correctly previewed on meshes.
To access them, just edit the material flags.
(e.g. follow the "material" link of a mesh, hit the "..." button next to flag, and then follow "back" to go back to the mesh)
  • "render order" and "render 1st" flag
    this is used to control what gets renered over what. Because, you know, every time there is something semi-transparent you want the transparent things be drawn over (i.e., after) the opaque ones, not viceversa
  • transparency mode
    transparent objects can be overlaid on the background in several ways, which you choose from 6 possibilities.
    These incliude the standard blend, useful for semitransparent object,  the add mode (only making stuff lighter), mult mode, (only making them darker), ad others.
    It can be an useful observation to make that all modes except "blend" are order independent! Which means that as long as you don't write on the Z buffer or don't use the Z-test for a bunch of such objects, the results will be just the same no matter which one is drawn first.
  • "uniform lighting" flags
    Used for stuff like foliage meshes, to avoid using their normals for the lighting. Using the normals would reveals a lot more their nature of "cardboards".
    For example, compare plant renderings, with and without that flag set
    :
    trees_2_old.png


    trees_2_new.png
  • "no depth test", "no z-write" flags
    if you are not into CG: the former means, in practice: "this object overwrites over anything when it is its turn to get drawn.
    Contrary to usual, it won't be hidden by things which are already drawn but are in front of it."
    The latter, means: "this object will be overwritten by anything that is drawn after him: even stuff that would normally go behind it will be drawn in front of him (if they are drawn after it)."

All together, these flags work together  to get the desired effects.
The good news is: if it looks good in OpenBRF, chances are that it will look good in the game.
For example, look these interior in vanilla (interiors_b.brf)
int_01.png

solid objects, drawn first (negative render order)
+
int_02.png

transparent dirt layer, drawn after  (render order: +4), mode: BLEND
+
int_03.png

window light, drawn last  (render order: +5 ), mode: ADD (make lighter). No Z-write (so that it doesn't occlude itself)
=
int_04.png

final result

(There are many other beautiful examples in native, where shadow meshes, dirt meshes, leak meshes, light meshes are used to achieved all sort of effect.)

Anyway, if you need to have a good look at your mesh without all these transparency effects (blend modes, alpha cuts, and the Z flags), you can disable "transparency" with a click just as you disable other rendering features (like texture, wireframe, bumpmap...)



2- more flags documented, and errors in material flag descriptions corrected.

As mentioned, the merit goes to [cmpxchg8b],
who provided me with the information. I've tried phrasing the flag texts and the status tips in the most natural, understandable way (sometime that's entirely different from the previous text).



3- Usability

I just wanted the GUI to be a bit more comfortable.

- You know how OpenBRF can show all the pieces side by site in a MxN grid.
  Not if you double click on a square of that grid you will select the corresponding object(s).
This works as a kind of visual search: e.g. Ctrl+A to select all objects in a file and see them all in 3D, then double-click on the 3D object you wanted. Works with everything (meshes, collisions, textures, animations, skeletons etc).
(From version "b": ctrl+doubleClick to deselect.)

- If you double click on the list on the left, you select the object you clicked PLUS all other subparts.
Previously, it was alt+tab which did that but I like the new way a lot more. Naturally, you can ctrl+doubleClick and you
toggle the selection on and off.

- small thingy: hitting Ctrl+R after opening OpenBRF [R]eopens last BRF file.
  (Recall that, after performing any editing action, like for example "compute ambient occlusion", Ctrl+R means [R]epeat that
  action. I wanted both things to be triggered by that key combination, because it comes just natural to me)




Little ameliorations include a better looking wireframe mode.
For the fixes, see the bug report thread.
Edit: ver 0.0.81b: hot-fixes, also see bug report thread.
 
New version!

ver 0.0.82 -- "revive and polish" release (5 Jun 2016)
1- fixed many bugs & polished various things & hi-res (4K screen) compatibility
2- option to use auto-computed tangent dirs if none is stored, to preview bumpmap (mimicking what the game does)
3- skeleton re-size tool (also affects hitboxes)
    and
0- re-coded 0.0.81 upgrade anew (source was lost)

Details:

1- fixes and polishes:
  • Hi-res 4K screen compatible -- works on "retina, hopefully. I didn't test because I don't have that kind of monitor.
  • No more limit on number of items. OpenBRF will now correctly display BRF files with as many items in them as you want (before, there was a limit of a few thousands).
    Still I would not recommend putting that many assets in a single BRF file. It is much more convenient to group them together in smaller chunks, according to some criteria, like everything needed by a given feature. Something particularly convenient (I found) is to place materials and textures together with the meshes which use them.
  • Dragging-and-dropping of BRF files over OpenBRF works again (in which version did I accidentally broke this?)
  • Custom Feminizer Setting file correctly located and loaded when OpenBRF loads up
  • Move Up and Down item on list (Alt+Up, Alt+Down) now work over multiple selections as well. So does the "duplicate" command.
  • You can now also Move item(s) by leaps, with Alt+PgDown, Alt+PgUp, or all the way, with Alt+Home, Alt+End.
    None of that is documented by the GUI, but I guess it is intuitive enough.
  • more sensible placement of new objects on paste (Ctrl+V)
  • fixed a few crashes happening here and there, and probably more (for example, it used to crash when double clicking on a empty 3D window)
  • now OpenBRF remembers if you disabled the floor rendering from a run to the next
  • icon showing on about screen and other screens
  • Terminology: skinning (per vertex bone-assignment) is actually now called "Skinning" everywhere in the GUI, not "Rigging" anymore. The new term is more correct.
    (The reason why I did this change is that, since the remote day when I started implementing OpenBRF, many things changed, including, that I started teaching various courses, in different universities, about or around Game Dev. Hence, I feel that my responsibility to propagate correct, established terms increased. :grin:)
    Translation files updated accordingly.
  • lighting in previews: still crude, but slightly better now. Used to be a bit over-saturated.
  • better auto-grouping: In "auto" combo mode, now meshes with same base name (e.g. castle.1, castle.2) are grouped together even if they are not consecutive items in the list.
  • Fixed tab ordering in GUI
  • probably other small things I forgot


2- auto-computation of tangent dirs

This probably requires a short explanation.

Background: tanget dirs are per-vertex attributes needed to correctly display normal-maps on meshes.  They can be computed from the UV-map of the mesh.

In the Warband serie: BRF meshes can come with or without tangent-dirs --- within OpenBRF, look in the mid panel to see if a particular model has them or not.
Since ver 0.0.62, OpenBRF lets you compute them and store them (if they aren't present) or discard them (if they are).
What I didn't know at first is that the game itself, whenever a normal-mapped mesh is loaded which has no tangent dirs stored in it, computes them on-the-fly.
So the effect of not storing tangent dirs in your mesh is only a less controlled result, and maybe a little time wasted by the game to compute them instead of just loading them.

The new option: therefore, now OpenBRF does the same. If a mesh needs tangent dirs and doesn't have them, OpenBRF will silently compute them in order for the bumpmap to be previewed correctly. This affects the previews only: the newly computed tangent dirs won't be stored when you save the mesh ---  unless, just as before, you ask OpenBRF to add them (how-to: select mesh, then [compute tangent dirs]). Anyway, you can disable this new feature under Options. If disabled, it is as before this update: meshes coming without tangent-dirs will show incorrect ("flat looking") normal-maps on them.


3- skeleton re-size tool

Simply, the selected skeleton is resized, including (if present) the associated hit-boxes. Remember that hit-boxes are stored in a separate XML file in module folder, not in the BRF file itself.

Usage notes: If you want to make a giant or a smurf, resizing the skeleton is not enough and results will be very broken. You also need to resize, by the same amount, all the skinned meshes which use that skeleton.

This is a small feature I added a while ago for an  experiment for TLD(this one), by Khamukkamu.


0- re-coding of last update

When a few years ago my computer was stolen, I was left with only the sources for 0.0.80. Source code for the features added in 0.0.81 (see post above) were lost. So I re-coded them. I hope they are all there as before. Re-coding things is always a pain. This explains why it took me so long before I did anything new on OpenBRF.



0.0.82b hot-fix (6-Jun-2016): fixed 4K screen compatibility (still not perfect, but viable). Thanks to [Bloc] for testing.
0.0.82c hot-fix (6-Jun-2016): complete Spanish translation. As usual, done by [Swyter].
0.0.82d hot-fix (10-Jun-2016): fixed unify-vert bug. Thanks [k0nr@d] for reporting.
0.0.82e hot-fix (19-Jun-2016): revamped tangent directions a bit. Fixed a pair of more bugs (wireframe...).
 
Status
Not open for further replies.
Back
Top Bottom