BRF Maker Tutorial (for making Collision Objects)

Users who are viewing this thread

fisheye

Quick-n-dirty BRF Maker download:
http://forums.taleworlds.com/viewtopic.php?t=7054

BRF Fields and Collision Objects Documentation:
http://forums.taleworlds.com/viewtopic.php?t=7054

This tutorial assumes that you are able to make 3D OBJ files and import them into a BRF file using Lurb’s BRF Viewer. If you don’t know how to do this, refer to Yoshi’s tutorial for help.

For illustration, suppose we are trying to make a scene of a flat plain. Assume we are using Wings3d, and the plain is already defined and textured and exported and sitting happily in some BRF file which you defined. So, you can specify it in your scenes, and you can see it, but if you use some other scene's collision mesh (e.g. bo_thirsty_lion) you'll bump into walls that aren't there, etc. Now we need to make a collision object to define the "solid" and "walkable" areas of your scene.

A collision object definition (more often called a collision mesh) defines a space in 3D which is not allowed to intersect with other collision object definitions. The way this space is defined is often very different from the shape of the modelled object, especially if the object is small and intricate. For example, if I was modelling a crystal bowl with 1,234 faces, it's not going to be practical to "cut off the bits I don't need". It's easier to simply define a sphere that encloses the bowl, which means anything that touches this sphere is touching the bowl object. Why is this easier? A sphere is defined as a point in space XYZ with a radius. It is trivial to compute distances from this point, hence physics calculations are much easier. Similar rationales hold for things like capsule. A capsule (looks like the thing you take your medicines in) is a loci of points equidistant from a line, very easy for physics. So if you have a long shape, like a car, maybe, instead of taking the car's mesh and deleting vertices to get a simplified mesh, you wrap the whole thing up in a capsule, much simpler for your game engine to handle. Planes are useful for flat surfaces like walls and floors. Manifolds are used for more complex objects that need to be modelled accurately.

brfmaker-ss1.jpg


We’re going to make a big square “face”-type collision object to go with this big flat model of a plain. Now we need to get the correct sizing and positioning for the collision object. To do this, we typically make another object that has roughly the same size and shape as our collision object, and then read off its dimensions.

In this case, we don’t even need to do that, since we can see the dimensions that we want simply from our 3D editor.

brfmaker-ss2.jpg


You can see from here that Wings says the position of the upper left vertex of my plain is at (-77.25, -0.01, -77.25). Since my plain is centered at 0, the other corners are at (77.25, -0.01, -77.25), (77.25, -0.01, 77.25), (-77.25, -0.01, 77.25).

Important note: the coordinates for Wings3D are Y-Z flipped for M&B, so make sure you flip the Y and Z coordinates when entering your data.

Now get BRFMaker and put it in some directory (doesn’t matter where). Edit brf_data.py to show the following:

Code:
outputfilename = "bo_big_floor.brf"

body = [
  [
    "bo_big_floor",[
      "face", [ [-77.25,-77.25, -0.01],[77.25,-77.25, -0.01],[77.25,77.25, -0.01],[-77.25,77.25, -0.01] ], 4
    ]
  ],
]

The outputfilename is self explanatory. The variable “body” is a list of collision objects we are going to include in this file; this one contains only one collision object, “bo_big_floor”. The collision object consists of a “face”, with the specified coordinates that we read off from the previous part (remembering to flip the Y and Z axes), in counterclockwise order with respect to the normal of the face. The last parameter is an unknown but seems to always be set to 4 for collision meshes.

As another example, suppose we added another collision object to this file. Then it would maybe look like:

Code:
outputfilename = "bo_big_floor.brf"

body = [
  [
    "bo_big_floor",[
      "face", [ [-77,-77,0],[77,-77,0],[77,77,0],[-77,77,0] ], 4
    ]
  ],
  [
    "bo_huge_giant_table",[
      “composite”,  [
        ("face", [ [-7,-2,4],[7,-2,4],[7,2,4],[-7,2,4] ], 4),
        ("capsule", [ 2, [-5,0,2],[5,0,2] ], 4),
      ]
    ]
  ],
]

In this case the collision object of the table is a “composite” of two other collision structures, with a “face” for the tabletop and a “capsule” to encapsulate the legs. This example is for illustration only, don’t include this code for your tutorial.

Now once you’re done entering this into brf_data.py, run make_brf.bat and it will compile a brand new BRF for you with your chosen filename. In this case, it’s bo_big_floor.brf. Move this BRF to your Modules/MyModuleName/Resource folder (of course, replace MyModuleName with the name of your mod).

Now edit Modules/MyModuleName/module_info.txt to include these lines:
Code:
load_module_resource = bo_big_floor

Using either the unofficial editor or the python scripts, you can now include these scenes wherever you wish. For example, I made the following changes:

Code:
  ("zendar_arena",0,"big_grass_ground", "bo_big_floor", (-100,-100),(100,100),-100,"0", [],[]),

Fire up M&B, enter the scenes (e.g. by talking to the arenamaster) and enjoy!
 
hmmm... not so good if you are making something a bit more complex...

This would help me add minor scene objects like telephone poles, tire walls, etc. but my more complex models and building interiors would take a bit more work.... :???:

I'll try this for some of the above mentioned items... Where do I get the BRFmaker?
 
jik said:
hmmm... not so good if you are making something a bit more complex...

This would help me add minor scene objects like telephone poles, tire walls, etc. but my more complex models and building interiors would take a bit more work.... :???:

It's a stopgap measure until Lurb writes his BRFView v2.0. I wouldn't even begin to know how to display a 3D object, let alone design a UI for it.

jik said:
I'll try this for some of the above mentioned items... Where do I get the BRFmaker?

Post edited with relevant info at the top.
 
Great Job Fisheye! Thanks for all your hard work.

However, this much I already understood pretty well. So the next logical question is...

If I model a box in wings, I think I now know how to generate the collision definition.

But what do I do with it after that, in order to use it in the game?

The 3d mesh BRF can be added to an existing BRF resource file (such as "object_meshes.brf") but we cannot use Lurb's BRF viewer to put the Collision definition in one of those BRF files since it will destroy it - so where do we connect the collision mesh to the object?) I know I am a pain in the A$$ - sorry.

I should just be patient *grin*

I'm looking forward to adding more large objects - such as variations on battlements, towers, stairs etc. (as well as other smaller objects that still need to have a collision definition attached).

Thanks again for all your hard work!!

DE
 
Deus Ex said:
The 3d mesh BRF can be added to an existing BRF resource file (such as "object_meshes.brf") but we cannot use Lurb's BRF viewer to put the Collision definition in one of those BRF files since it will destroy it - so where do we connect the collision mesh to the object?) I know I am a pain in the A$$ - sorry.

So you're making a Ferrari. You define a collision mesh in brf_data.py using faces, spheres and capsules. Now specify the mesh name as something like bo_myfunkyferraricollisionmesh instead of bo_big_floor. Set the output file to "anythingyouwant.brf". Include the line "load_module_resource = anythingyouwant.brf" in module_info.txt.

Now you may refer to "bo_myfunkyferraricollisionmesh" as a valid collision mesh anywhere in your module.
 
fisheye said:
Now you may refer to "bo_myfunkyferraricollisionmesh" as a valid collision mesh anywhere in your module.

Ahh, now I am cognizant of my own lack of knowledge. I am humbly unworthy. It is obvious to me that I am ignorant, and unlearned in these arcane arts, :wink:

but still I must ask...

Other than in "module_scenes.py" where does one specify a bo_mesh/collision definition reference??

In "module_scenes.py", I can see the object mesh is connected to the collision definition by the fact they are specified together.

Now, as for all other objects in the game, such as battlements, tables, etc, I do not know how to specify them. I only know of the ones that already exist. I know that they exist in the BRF resource file "object_meshes.BRF" (I can view them with Lurbs viewer). I can insert them into the game using the in-game editor. I believe the defintions of what object, and where it is located in the scene, are stored in the "scn_xxx.sco" file. However, I cannot read that file (that I am aware of).

So, if I build a "Ferrari_Hay_wagon" - and build the approriate collision definition for it (I have "F_hay_wagon.brf" and "bo_F_hay_wagon.brf")
how do I specify them in a scene in a module??

(am I getting better at asking the right question?? *grin*)

DE
 
Inventory items are defined in module_items.py

Scenery objects are defined in scene_objects.txt (in the Data directory, not modularised yet).
 
fisheye: Nice tut.

Deus Ex: you can add:

<name to display in in game editor> 0 <mesh name> <collision mesh name (bo_something), or 0 for no collision mesh> 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000

to the end of scene_objects.txt in the Data dir.

A brf is not an object. The objects are inside the brf. Currently you can only create collision shapes with fisheyes tool, and they will be placed inside the brf you specify.
 
CLICK

It all falls in place. SWEET.

Thanks Thorgrim for clarifying that!

My limitation, my blind side if you will, is that I did not actively investigate the text files. I have worked almost exclusively with the python files. (I tend to do better with code oriented stuff - all those lists of numbers tend to remind me a bit too much of debugging hex dumps... *grin*) - I see now that I was constrained by what was defined to the module system.

So now I know how to add new objects that I want to create - and make them available in using the in-game editor.. - very cool.

So now, until we have a method to add them together, each collision definition is going to be in it's own BRF file. Hmmm, I wonder if when using Fisheye's new tool, if you specify the output BRF filename of an existing BRF file, will it append it or over write it... (ONE way to consolidate BRF's if it appends them *grin*)

okies.

Tremendous stuff Fisheye!! - again many thanks.

hmmm more questions forming, better stop here for now *grin*

Cheers

DE

(hmm let's see how do I model a fountain with a Fish and a BIG eye?...)
 
one last thing. I think there is a number count at the top of the scene_objects.txt file. I think you need to increment it when you add objects.

As with more complex objects you can break them down into faces or capsules. Stairs isn't as complex as you think. The collision def. is a simple box (4 faces) with one side slanted down along the climbable part.

You could do each step, but you have to be careful, the first instance of stairs I used in the in game editor (older verions, they must have cleaned it up later) you had to jump every time you wanted to go up a step. :???:

I wanted to test my tower, which was hollow, had 3 doors, and 7 stair levels. just doing one side with a door would be 3 faces for the outside, 3 faces for the inside, and 3 faces for the door way. each set of stairs would have 3 faces (since you really only need the visible sides, and maybe you could exclude the bottoms) then 2 more landings...

I could do it, but it's a double conversion for me since I use max, not wings. I don't know if they messed with the xyzs in that....
 
Deus Ex said:
CLICK
if you specify the output BRF filename of an existing BRF file, will it append it or over write it... (ONE way to consolidate BRF's if it appends them *grin*)

Ah, it will overwrite it, be careful! :smile:
 
jik said:
I wanted to test my tower, which was hollow, had 3 doors, and 7 stair levels. just doing one side with a door would be 3 faces for the outside, 3 faces for the inside, and 3 faces for the door way. each set of stairs would have 3 faces (since you really only need the visible sides, and maybe you could exclude the bottoms) then 2 more landings...

I could do it, but it's a double conversion for me since I use max, not wings. I don't know if they messed with the xyzs in that....

Hey jik, thanks for the feedback.

Do you know of any software (3DSmax?) that can edit collision objects and export them? If so, I can probably make a converter to convert them to BRF, which would be a lot less of a headache for you.
 
Most times I've made collision defs. was more handled by the editor then the modelling software. Ex. with UT, you specify an mesh object to define a game object's collision def.

I mean, I can make collision objects and export them as OBJ files. OBJ files seem to store each vertex location, so I'd assume that would be sufficient.... I'm gonna run a litte test and get back to you. I'm gonna export a single face and see what the OBJ file looks like...
 
ok, here's the output of a flat plane (the listing of the OBJ file) with the normal side facing up:

# Exported from Wings 3D 0.98.32b
mtllib plane-up.mtl
o Box01
#4 vertices, 2 faces
v -1.50000000 -5.0000000e-5 1.50000000
v 1.50000000 -5.0000000e-5 1.50000000
v -1.50000000 -5.0000000e-5 -1.50000000
v 1.50000000 -5.0000000e-5 -1.50000000
vt 0.0000000e+0 0.0000000e+0
vt 0.0000000e+0 1.00000000
vt 1.00000000 0.0000000e+0
vt 1.00000000 1.00000000
vn 0.0000000e+0 1.00000000 0.0000000e+0
vn 0.0000000e+0 1.00000000 0.0000000e+0
vn 0.0000000e+0 1.00000000 0.0000000e+0
vn 0.0000000e+0 1.00000000 0.0000000e+0
g Box01_default
usemtl default
f 1/1/1 4/4/4 3/2/3
f 2/3/2 4/4/4 1/1/1


it has the vertex locations that you specify for a face. In other objects there are the 'v' enteries, the 'vn' entries and also 'vt' enteries. Possibly the 'vt' has to do with normals (the solid side of the faces) since I've tested exporting shapes (having no normal defined) and the 'vt' info was not present. the 'g' area denotes the name of the object upon export.

if I could get my hands on one of the ob files exported to OBJ, I think I could understand how they worked better. Is that possible?
 
jik said:
ok, here's the output of a flat plane (the listing of the OBJ file) with the normal side facing up:

# Exported from Wings 3D 0.98.32b
mtllib plane-up.mtl
o Box01
#4 vertices, 2 faces
v -1.50000000 -5.0000000e-5 1.50000000
v 1.50000000 -5.0000000e-5 1.50000000
v -1.50000000 -5.0000000e-5 -1.50000000
v 1.50000000 -5.0000000e-5 -1.50000000
vt 0.0000000e+0 0.0000000e+0
vt 0.0000000e+0 1.00000000
vt 1.00000000 0.0000000e+0
vt 1.00000000 1.00000000
vn 0.0000000e+0 1.00000000 0.0000000e+0
vn 0.0000000e+0 1.00000000 0.0000000e+0
vn 0.0000000e+0 1.00000000 0.0000000e+0
vn 0.0000000e+0 1.00000000 0.0000000e+0
g Box01_default
usemtl default
f 1/1/1 4/4/4 3/2/3
f 2/3/2 4/4/4 1/1/1


it has the vertex locations that you specify for a face. In other objects there are the 'v' enteries, the 'vn' entries and also 'vt' enteries. Possibly the 'vt' has to do with normals (the solid side of the faces) since I've tested exporting shapes (having no normal defined) and the 'vt' info was not present. the 'g' area denotes the name of the object upon export.

if I could get my hands on one of the ob files exported to OBJ, I think I could understand how they worked better. Is that possible?

Thanks jik.

The OBJ file format is totally open, a google search will show you exactly what you need to know, no experimentation required.

So, yes I can probably do faces, and manifolds (once I decipher the manifold format).

The issue is with spheres and capsules. Most modelling programs would output them as faceted objects, which would be useless. Know of anything that would actually output a sphere as (center XYZ, radius)?
 
fisheye/jik: I don't think it worth spending the effort on this... Lurbs Model importer should be able to create all the collision meshes when ready, and exporting anything except manifolds seems pointless.

If you really wanted to do it, you could do something simple like do it with obj files, dependant on the name, you can easily work out the dimensions. Eg a spheres centre and radius is easy, a plane is easy... a capsule would be a bit hard (But no formats I know have them anyway)

Best off just waiting for the BRF editor to be ready, then if Lurb doesnt have time to do the collision mesh part we can add it for him :smile:
 
Thorgrim said:
fisheye/jik: I don't think it worth spending the effort on this... Lurbs Model importer should be able to create all the collision meshes when ready, and exporting anything except manifolds seems pointless.

If you really wanted to do it, you could do something simple like do it with obj files, dependant on the name, you can easily work out the dimensions. Eg a spheres centre and radius is easy, a plane is easy... a capsule would be a bit hard (But no formats I know have them anyway)

Best off just waiting for the BRF editor to be ready, then if Lurb doesnt have time to do the collision mesh part we can add it for him :smile:

Question of the year: Any update on Lurb?

I hate waiting around for someone else to do the work when they undoubtedly have other much more serious health affairs to attend to. It makes us all look like useless pansies, just waiting for a good guy to do all the work when he should be looking after his own health.

But in this case a lot of work has already been done and it's not good to repeat the effort. So it's a bit of a bind until we know what's what.
 
I would like to also add a comment that while this tool is somewhat user-unfriendly at the moment, it's a good existence prover that making collision objects is possible even if Lurb goes completely offline.

So, all you modelers out there, start making your scenes now. We'll have some kind of tool to use to make the collision objects by the time you're finished. Whether it's Lurb's or mine or someone elses, it will be there. So get crackin'!
 
Well, I've been waiting a long for this kind of thing, but I guess I can wait longer. Still lots of stuff to do for AoA. I guess I'm all excited to try out my hollow tower with stairs... If anything, I can make a properly faced object to OBJ and put the info into the BRFmaker.

On that note, with some of the things talked about by fisheye, exporting for complex (not faced) bo files may be dificult, unless the importer can destinguish different types of objects. How will it know that the shpere I exported is a sphere if the out put in in faces?

then again, to make things simple, maybe all bo objects that are not spheres or capsules should be set up as boxed faces? I'm rabbling again... I'll move on for now... :oops:
 
jik said:
On that note, with some of the things talked about by fisheye, exporting for complex (not faced) bo files may be dificult, unless the importer can destinguish different types of objects. How will it know that the shpere I exported is a sphere if the out put in in faces?

One method: label all collision objects with their type. E.g.

a cube enclosing your bowl, named CMSphere:

I could make the BRFMaker read this off the OBJ file, compute the center and radius of the sphere that the cube would enclose.

Similar for capsules, in that case it would simply be a box (a cube with one axis stretched).

Faces and Manifolds are self explanatory. It would be the modeller's responsibility to make them closed, but that's really not too hard.
 
Back
Top Bottom