B Tutorial Other Minitutorial: hit-boxes manipulation in OpenBRF

Users who are viewing this thread

mtarini

Sergeant Knight
Background

What are Hit-boxes?
Hit-boxes in M&B are little balloons around each bone of a moving character used by the game to understand if something hit that part of the body, and, by extension, that character. A character, independently by its apparent size and look, is hit just if an only if the ballon is hit. The rationale is that it is much quicker for the game to check the "balloon" for collisions. It is similar to the Collision Objects (which are for static meshes, however, and can be any shape -- not just baloon).

Another use of hitboxes is in ragdolling, to avoid that, say, an arm pass though the chest when the guy is dead and is falling like a huge bag of potatoes.

hitbox_human.png

hitbox_horse.png
Hitboxes for human and horses in vanilla Warband, visualized with OpenBRF

Why you want to edit them? Simply put, if you make a new skeleton or customize an old one, you want to make a new hitbox set for it, for a more realistic fighting experience in the game.


Hit-boxes in M&B / WB

The game keeps, for each different skeleton it uses, a hit-box set (composed of at most one hit-box per bone). Some bone, usually smaller ones like "hands", have none (at least in vanilla). Every hitbox is shaped as a "capsule", the geometric shape you get if you cut a sphere in half and cram a cylinder of the same radius in the middle.

Now the ugly catch: Hit-boxes for skeletons, unlike basically all other content of the game (e.g. meshes, animations, materials, collision objects...), are not stored in any BRF file!

Instead, the game keeps them in a separate file, "skeleton_bodies.xml", which holds all hitboxes for all skeletons used in a module, plus a few other metadata also associated to skeletons (used for regdolling). That file is kept in "<your_module>/data" folder, but, if not there, a default copy is used from game "data" folder.

That's a bit of a problem for OpenBRF: hit-boxes are tightly linked to skeletons, they cannot even be visualized without one, and yet, if they are modified, not the BRF file holding the skeleton, but this global .xml file has to be saved. That will cause some confusion, I'm sure. Important: the link between "hitboxes" (in the XML data) and skeletons (anywhere in BRF files) is by name: a hitbox set will be associated with any skeleton with the same name (by the game and OpenBRF alike).



How-to's in OpenBRF

Visualize hitboxes

Just select the corresponding skeleton. You'll see, in the databox, a check-button called "has hit-boxes", in the "data" box, which tells you whether that skeleton has an associated set of hitboxes. If it does, you can visualize the set of hit-boxes by selecting the option inside the "view" box.

Hitboxes can be visualized also when seeing skeletal animations (to see how they behave during an animation).  In all cases, they can be visualized overimposed with a rigged "skin" (the skin can be quickly toggled on/off with space: doing so helps perceiving how well the hitbox fits an actual character).

hitbox_wb.png

When you change the current module (and at start-up), OpenBRF scans the file "skeleton_bodies.xml" and remembers all the hitboxes found there: it will use them together with skeletons with the same name. OpenBRF reloads that file from disk when you hit F5 ("refresh module") (with many other things).

Remember the association is done by name: for example, if you rename a skeleton, it can lose (or gain) a hitbox set.


Edit hitboxes manually with a text editor

Anything you need to do with hitboxes of your mod, you can do it manually, by opening the file "skeleton_bodies.xml" in a text editor (copy the one from <game>/data folder into your <module>/data folder to start with). The file is a XML so it's should not be too difficult to figure out and edit.

To visualize that what you did made sense, you can keep OpenBRF open: just save the XML file and refresh OpenBRF with F5: the hitboxes will be updated.

This is the "slow but sure" way: you can add, delete, edit any hitbox assocaited to any skeleton. It is just not very intuitive to do. That's the emergency way to do anything (even without OpenBRF). However, OpenBRF offers functionalities so that you can, in most cases, do all you need without ever opening that file.


WYSIWYG editing hit-boxes within OpenBRF

- Select the skeleton with the same name as the hitbox.
- Click on any bone on the list.
- You can now use the controls to thicken, elongate, move, rotate the hitbox for that bone. You can also activate/deactivate that hitbox (not all bones must have one). You can make the hitbox symmetric (e.g. you edit the left leg, and use that to update the right leg so that it matches). And so on: experiment with the controls, they should be  easy to understand with very little tries.
- Hint: while you edit, it helps to turn the skin on and off (keyboard shortcut is "space") to see that your hitbox is right.

Edit, forgot to mention: while using these controls, if you keep any modifier pressed (ctrl, shift, alt...) you will just nudge the hitbox a little.


Save a modified hit-box set

Now the tricky part: when you modified a hitbox set in OpenBRF, a "(**)" (note: double *) will appear in the OpenBRF windows title: this tells you that you have unsaved changes in the skeleton metadata. It's of no use to just "save": that saves the BRF file with the skeleton, and hitboxes are not kept there. Instead, you need the command, under "Module" menu, to "Save module Hit-Boxes for all skeletons".

Don't worry: you will be prompted that you must save your changes, and offered to do so, whenever you are about to lose them (e.g. you try to quit OpenBRF, or open another module, etc).

(hint: a quick way to discard your edits, if you need to do so, is to refresh the module with F5 and pick "discard changes" when prompted: that reloads the current "skeleton_bodies.xml")

Remeber you never save just a single hitbox set: you save either all hit-box sets of a module or none.

Caveat: when OpenBRF saves the hitboxes, it saves a "skeleton_bodies.xml" which is looks very different from the one found in native (a backup is done anyway). This is because equivalent XML files can have many different forms (indentation etc). In particular, OpenBRF unfortunately scrables the order of "attributes" inside nodes. The game does not care at all, and works correctly. But subsequent manual edit of that xml file can gets more difficult, I'm afraid.


Add a hit-box set to a new skeleton

When you create a new skeleton (e.g. copy, paste and rename an existing skeleton, or import it), it will have no associated hitbox set. Unfortunately, you cannot just add hitboxes to its bones, one by one, because there is no way OpenBRF would know the rest of the metadata which will have to be saved together with the hitbox.

Instead, you have to transfer an existing hitBox-set from another skeleton.

How to do that:
1) select origin (a skeleton with hitbox), [edit]->[copy hitbox]
2) select destination, [edit]->[paste hitbox].

The two skeletons must share the same number of bones.


More on copying and pasting hitboxes

The above is the "direct" way to copy a hitbox set from a skel to anther.
As an alternative, you can pass through a collision object. The effect is a bit different (see below).

That's how you do that:
1) select origin (a skeleton with hitbox), [edit]->[copy hitbox]
2) [edit]=>[paste] (or ctrl+V), creates a static Collision Object with all the capsules
    (maybe edit this Collision Object in whatever way you like)
3) [edit]=>[copy] (or ctrl+C) this collision mesh
4) select destination skeleton, [edit]->[paste hitbox].

In other words, the hitbox set you copied from a skeleton can pasted the normal way (step 2), instead of pasting it "as a hitbox". That creates a (static) Collision Object, made of capsules (plus "empty" placeholders for bones without hitboxes). The capsules are disposed statically according to bones in the original skeleton.

This Collision Object can potentially have its own uses, and can be treated as any other BRF Collision Object (e.g. they can be saved in the BRF, edited by re-scaling them, or by manually editing their many numbers, or be exported-modified-and-reimpored, etc.). 

A Collision Object of this fashion can, in turn, be copied and pasted "as a hitbox" over a skeleton (steps 3 and 4).

The two ways to transfer a hitbox from a skeleton to another are a bit different:
- If you direct, the capsules will adapt to the position of the bones in the receiving skeleton.
- If you go though the Static Collision, their position are fixed in space, indendent of the bone positions of the destination skeleton. 

I kept both ways because there are cases when either of the two things is useful. Can you see why?


Minor: remove a hitbox from the module

That is, remove it from skeleton-bodies.xml

You can select the skeleton with the same name, right click, [Remove hitboxes]. Remember you are not actually doing anything to the skeleton. The association is done by name: if you remove the hitbox from a skeleton called "skel_giant", you are just deleting the hitbox called "skel_giant" (e.g. another "skel_giant" sitting in another unrelated BRF file of the same module will now be without hitbox).

When you save hitboxes, OpenBrf tells you all the hitbox sets that are going to be saved.

Small detail: if you want to remove one hitbox set, but have no skeleton named that way, you can create a temporary skeleton with that name just in order to delete it.



 
When doing this, OpenBRF most likely needs administrator access on Windows 7/ Windows Vista, yes? I have the stupid anti-hacking crap enabled on Vista, and so if I make changes, nothing happens. (therefore, I do all mod editing on a flash drive) :razz:
 
Administrator access: good point...

however, if OpenBRF saves any BRF at all, then it means he is writing into:
 
Code:
<gameFolder>\modules\<your_module>\Resources\<file_name>.brf
so it should be able to write, just as well into:
 
Code:
<gameFolder>\modules\<your_module>\Data\skeleton_bodies.xml
right?
 
Well, I do my mod editing outside the MB Warband folder. Due to limited/no access without Admin features granted I can't save or write anything into my <gamefolder>/module/ folder. I should probably just shut the dang thing off... :razz:
 
Hey mrtarini, did some experimenting with the WYSIWYG editor of the hitboxes, it seems to work fine except:
- It completely mixes up the xml file, my merge tool does not know where to start

- It drops some variables from the xml file like the one:
  for_ragdoll_only="1"

- After saving once and trying to save again, It gave me a error about unable to find skeleton "skel_elman" after manually renaming the "skel_human" into "skel_elman" in the file it saved. Renaming it again manually in the file made it work ingame but its a interesting bug.

- It changes a end of a element sometimes instead of: "</Bone>    "  into:  " /> ".
  I'm not entirely sure how the game xml parser handles that.

- It changed the header from double qouotes to single quotes, not sure how the game handles that;
  version="1.0" encoding="UTF-8"
  To:
  version='1.0' encoding='UTF-8'
 
Let's see...

Vincenzo said:
- It completely mixes up the xml file, my merge tool does not know where to start

Unfortunate but ultimately harmless.

Yes, I know, warned about that above...
Edit, for clarity: specifically, what is happening here is that order of attributes gets mixed up.

The game likes OpenBRF generated mesh XML just as well (I test before releasing naturally).

But I agree that's unfortunate, cos I know the mergers/compares will think the file changed a lot; also, manual editing of XML file as text will also become somewhat harder...

I might try to find a way around that, but it is not a quick change (I'll would need to change or patch the library I use for XML). 


Vincenzo said:
- It drops some variables from the xml file like the one:  for_ragdoll_only="1"

Harmful!
Thanks for reporting that. I'll double-check. Is it the only flag that goes missing?


- After saving once and trying to save again, It gave me a error about unable to find skeleton "skel_elman" after manually renaming the "skel_human" into "skel_elman" in the file it saved. Renaming it again manually in the file made it work ingame but its a interesting bug.

As I said...
mtarini said:
Now the ugly catch: [...] That will cause some confusion, I'm sure.
Important: the link between "hitboxes" (in the XML data) and skeletons (anywhere in BRF files) is by name [...]

So, :sad:


Vincenzo said:
- It changes a end of a element sometimes instead of: "</Bone>    "  into:  " /> ".
  I'm not entirely sure how the game xml parser handles that.

Totally harmless

Vincenzo said:
- It changed the header from double qouotes to single quotes, not sure how the game handles that;
  version="1.0" encoding="UTF-8"
  To:
  version='1.0' encoding='UTF-8'

Totally harmless
 
Yes, the only flag I found dropped.

What is the trouble with the skeleton name?
Just now openbrf was complaining it couldn't find the skeleton named "skelkeluman" upon trying to save.
Going into the file and temporary naming skel_human like that weird **** and saving in openbrf then renaming it back becomes tedious every time...
 
When you have time, can you check, if it that problem is gone now, in ver 0.0.73b?

Edit: no wait, there are problems.... wait for c version.

Ok, 0.0.73c version is out now. Hopefully it is fixed.
 
What is the max number and minimum number of hitboxes? I'm making some new skeletons for special troops, but some need every bone to have a hitbox, while another needs about two bones to have a hitbox
 
HitBoxes are linked to skeletons. So in your case I think you'll have to duplicate the skeleton, rename the duplicate something else, and edit different hitboxes for the duplicate (*).
Then make special troops use a different "skin", which in turn uses the duplicated skeleton.

More details: I'm afraid that the game will hate you if you use different skeletons for "humans" (non-horse) troops with non-matching number of bones. But I'm sure you can use different skeletons as long as they share the number of bones (and every human animation must be designed for than number of bones).
In your case, the skeletons will be identical, but they will have different associated hitboxes.


While you are at it, can you double-check if the hit-boxes which you experience in-game are just the same as the hitboxes you see in OpenBRF?
It is not immediate to tell, but shooting arrows at targets get be a good way to attempt to find out.
(I'm asking because I've made my best to make OpenBRF interpret hotbox correctly, but my guess are based on the assumption that Vanilla hitboxes match closely vanilla meshes)


(*) EDIT: easier way to do that: when you duplicated the skeleton, copy original skeleton and [edit]=>[paste hit-boxes] over your duplicate. Then edit new hitboxes for duplicated skeleton.
 
mtarini said:
HitBoxes are linked to skeletons. So in your case I think you'll have to duplicate the skeleton, rename the duplicate something else, and edit different hitboxes for the duplicate.
Then make special troops use a different "skin", which in turn uses the duplicated skeleton.

More details: I'm afraid that the game will hate you if you use different skeletons for "humans" (non-horse) troops with non-matching number of bones. But I'm sure you can use different skeletons as long as they share the number of bones (and every human animation must be designed for than number of bones).
In your case, the skeletons will be identical, but they will have different associated hitboxes.
Yeah, that was the plan. Though I am planning to test something out with different skeletal bones. If I make two skeletons (borrowing your skeleton and animations with the tail bones) and then set skel_human_2 or something to the female race, I can see what happens.

mtarini said:
While you are at it, can you double-check if the hit-boxes which you experience in-game are just the same as the hitboxes you see in OpenBRF?
It is not immediate to tell, but shooting arrows at targets get be a good way to attempt to find out.
(I'm asking because I've made my best to make OpenBRF interpret hotbox correctly, but my guess are based on the assumption that Vanilla hitboxes match closely vanilla meshes)

Good idea. I'm testing it out in an...interesting manner. Enlarging each hitbox one by one per-test to see functionality seems like a good idea atm.... not sure yet. The other thing I was thinking was making my own capsule-body matching up to the hitboxes and seeing how accurate it is by a few misc tests.
 
Back
Top Bottom