Download link and main info! [latest ver 0.0.82e -- 19 Jun 2016]

Users who are viewing this thread

New version!!!

Nothing exciting, but it is more complete, I added several things:

Edit:changelog:

ver 0.0.12 (17 Ago 2009)
  - display and direct editing of material/texture/shader/collision attributes
  - creation of material/texture/shaders object
  - rendering of textures (and materials, as textures) (sceenshot below)
  - export of collision meshes as multi/object obj. (import still missing).
  - mesh tools added: recompute normal, unify position/vertices see ("other features" above).
  - flags is still just a number, but at least it is shown/edited in hexadecimal


So, to answer Highelf and Eumolpus, now it should be more usable.

Something that is still missing is an intelligible bit-flag management.

I've added some tool for mesh editing: "recopute normals and unify"
that should fix the shading in the God-sceen screenshots I see.
(edit: shading is wrong, flat shading. You can see triangles)
I also added the option to automatically do that after mesh imports, but don't turn it
on if you trust the tool that produces your meshes to also produce good normals.)

As for the "unify" part, it means that vertices and position are matched and reindexed, for more compact
and more render-efficient meshes.

Collision meshes can be exported as Obj. I'm working on an importer to match it.
(the issues is that I want it to work also with al kinds of collosion objects: collision spheres, capsules, etc).

(Everytime a texture is not readable, -- either because it is a format openbf does not support, or
baecause is in a position where openbrf didn't look --  a checkboard pattern is shown instead.
And, some texture look just uniform color until you see the alpha channel or use alpha transparency
In a material panel, if you select a texture name -- eg bump or shniness map -- that texture is show.)



Edit: oops I forgot to update verion number in about screen.



amade: Crashes occasionally... I know, I'll try to make it more robust.

Edit: amade: ok, I'll quit doing that... oops!  :mrgreen:
 
Whoopee, another round of midnight testing!
Nothing exciting he says... pah!
I think we're almost to the point where we can completely replace BRFedit :razz:

mtarini said:
Also, I've added some tool for mesh editing: that should fix the shading in the God-sceen screenshots I see.
(I also added the option to do that automatically after mesh imports.)

Which one is this? I think I may have missed this issue/problem.

edit: About still says it's version .11, but new features are in
 
mtarini said:
(edit: shading is wrong, flat shading. You can see triangles)
Ah, I thought cdvader simply had left it unsmoothed...

Material display is buggy, sometimes it only shows blue-white checkerboxes, sometimes it shows the same material as greyscale instead of in colour. Doesn't seem to affect display of native materials though... Something to do with the flags and settings?

edit: Bleh, quit editing your replies into old posts, I keep missing 'em! :razz:
 
low priority, but could I request a mult-edit functionality for shaders, specular, RGB, and flags on multiple materials at once?  I often find myself just typing the same thing again and again when I want to swich some material settings....
 
New bug... Since we've all been obses- I mean... focused on rigged mesh and animations I don't think anyone's thoroughly tested static mesh import/export yet :razz:

Importing static meshes causes them to replace whatever mesh was previously selected in openBRF. The imported mesh displays correctly after import (tested formats: obj and ply). Importing rigged meshes work as usual, they get added into the list instead of replacing whatever existing mesh in it.

Export works alright. Except that PLY doesn't keep the UV coordinates of the model, and the object is oriented -90 degree along x axis (the rotation isn't a problem, it's just a matter of adaptation). I'm not familiar with PLY formats so I don't know if there are any advantages to exporting into this format if it doesn't maintain your texture-coords instead of exporting the familiar OBJs, which works fine as expected in all respect.

edit: Ack! I just noticed that OBJs exported from openBRF have their UV coords mirrored on the Y-axis. I can fix this minor annoyance in Blender but I'm not sure if other people wouldn't have trouble realigning their UVs should they need to.
openBRF0012_bugrept_1.jpg
 
Is it normal that every model is textured with blue and white cubes (chess style) ?
I want to see the normal texture, not just a chess table.
 
Freddex said:
Is it normal that every model is textured with blue and white cubes (chess style) ?
I want to see the normal texture, not just a chess table.

Are you really an idiot, or do you just pretend to be one on the internet?
 
The white-blue patterns is just openbrf way to say "I could not load this texture"...
(it is a way that allowed me to check that at least texture coords made sense).
This is just an issue of the 3D preview inside OpenBRF. It does not affect any file it saves or exports.

There can be several reasons for the checkboard to happen:
the texture file is missing, or it is present and where it is supposed to be but openBrf looked in the wrong place, or it was in a format that OpenBrf doesn't understand, or BrfEdit does not know what texture to associate to the current material of a mesh.

Format:
- currently, OpenBrf understands DXT1, DXT3 and DXT5 textures, which are the vast majority of textures used in M&B.
  It does not understand TIFF textures (there's a very few).

Place where to look:
- currently, OpenBrf is pretty dumb: if you open a file brf in any folder, it will only look for textures in "<that_folder>/../textures/"
This will only work if that file is a native file (in common res folder) or a module file in that module resource folder and the texture is in that module texture folder . Otherwise, this strategy will fail... I'll implement something smarter at some point.

Unknown material (edit):
- as you know, Meshes determine Materials, and Materials determine Textures. So to know what texture to use, you need a Material, which can be stored in another brf file. Currently, OpenBrf only scans for materials a few files ("materials.brf", "core_materials,brf", and in the next ver, "materials_face_gen.brf"), so either the used material is there, or it is in the file you just opened together with the mesh, or in a file you opened in the same session, or else... checkboard.



Another thing that can cause the checkboard:
- in the material screen, OpenBrf shows in the 3D screen the last texture that you clicked on in the list (of the many that composes the material: diffuseA, diffuseB, bump...). If an empty ("none") texture is selected, then... checkboard. Just select the name of a texture which is not "none".
not anymore

 
New version!

This time, two things were added:

- material flags are now checkable separately. Is is a small thing but can we work without this?
I also discorporeted the bits encoding "render order" in a different field.
I figured out the meaning of each bit in the flags by looking at the old BrfEdit. If you have better sources, let me know.

Also, if you find any native material with any flags set that is labelled "unused", report that: we might be able to infer the meaning of that bit. For example, I added a previously undocumented bit which I called "LoD", which is set in all materials that are used for Level of Detail. I guess that it means "only load smaller mipmap-level of the texture(s)" or something similar.


Second thing:

- the import of collision objects from Obj files... let me know if you encounter problem with your Obj files...
Also, there is a lot to add about how to use this for better results, I'll do it in a separate post in a minute (edit: done: see 2 posts below this one). Let me update the first page.


edit: HokieBT and Dain: editing of multiple materials... good idea. It is in the list now...
 
How to build good collision objects

Preamble: in M&B, the most common kind of collision objects is the "manifold" (closed meshes of quads and tris, which usually are the simplified/poly-reduced versions of the tri meshes used for rendering). They are the most flexible kind, as any shape can be approximated with one. However they are quite heavy to test, and in the game a lot of testing happens for collision detection. Better primitives (better = lighter to store and to test) are cylinders (called "capsules") and spheres. Unlike manyfolds, cylinder / sphere is not specified by hundreds of points and faces: a few parameters like center, axis and radius will do.
In M&B a collision object is a collection of manifolds, spheres, and cylinders.
So, if you can, try to specify collision objects for your custom stuff in terms of a few spheres and cylinders.
It will be more efficient to test. For example, see the screenshot with the collision object for the catapult in the first page (taken from a native collision object)...

PS: there is also a forth, simplest kind: the "face", a single flat polygon.

How to do that? an Obj file can contain several subparts, each with its own "name". When one obj is imported in OpenBrf as a collision object, all parts that have a name starting with "cylinder" (or "capsule") will be interpreted as a cylinder, and a "capsule" object will be created for it with the right position/orientation/size (by a fitting algorithm). Similarly, object with a name starting with "sphere" and "polygon" (or "face") will produce a "sphere" and a "face" collision object respectively.

(Obj files produced by OpenBrf by exporting a collision object will comply with the above naming rule, so if you reimport en exported off all the various subparts should be kept).


Yes but how do I specify these names in my Obj file? The answer varies with the program you use to produce the obj file.

In Wings3D, for example, you must look at the geometry graph. Also, if you add a new "cylinder" or "sphere" object, Wings 3D will produce an object named "cylinderX" or "sphereX" (X being a number), so that's just perfect.

EXAMPLE:

In wings 3D, I created an vaguely erotic abstract art with two cylinders, two spheres, a cube and a torus (note the geometry graph, displaying names of the objects -- they are the default ones)...
art02.png


After importing, OpenBrf understood and separated the spheres and cylinders as separate objects...
art01.png

(the scene is flipped, as usual -- in the game, it will look like in OpenBrf).
Update: not anymore. Now obj exported by OpenBrf will look with the same orientation in Wings3D etc.

The torus and the cube, as well as anything not named "sphere*" or "cylinder*", were merged in a single "manifold" object, but the spheres and the cylinders are listed as separated objects, each defined by a few parameters and ready to be tested for collision (during the game) in a wink .


What if I didn't read any of the above and don't feel like doing so?

Nothing bad, friend. If your obj file is not spit in objects named "sphere" "cylinder" etc, then the collision object you obtain by importing it will just be composed by a single manifold. It will still work in M&B. (only, it may be a little less efficient in game).




 
Good.
Thanks for your help mtarini, my problem is solved now.

Are you really an idiot, or do you just pretend to be one on the internet?
Dain, why do you call me an idiot? What's the problem?
I just had a simple question, and I'm not a noob in M&B I think.
I play this game since version 0.35 and I have some skills at modelling, but if
you wanna continue flaming me done in every thread, do it.
 
mtarini said:
edit: HokieBT and Dain: editing of multiple materials... good idea. It is in the list now...

Excelent. I'm doing some BRF edit stuff and typing the name of the material for each individual mesh is taking forever.
 
Err... not sure if you've noticed this bug report:
http://forums.taleworlds.com/index.php/topic,72279.msg1911691.html#msg1911691

I noticed the bug is still present in v0.0.13 which may affect this operation:

mtarini said:
- the import of collision objects from Obj files... let me know if you encounter problem with your Obj files...
Also, there is a lot to add about how to use this for better results, I'll do it in a separate post in a minute (edit: done: see 2 posts below this one). Let me update the first page.

Don't mind this post if you've already read that report but haven't fixed it in yet in this version :'P

Neat tutorial btw!
 
No, actually I didn't notice that post! So thank you! I'll see to fix them.

(however, that is not likely to affect collision objects: first, they have no texture coords, and second, I remade a novel import/export procedure for them anyway, because previously I was importing them via a lib that handled only triangles, while collision manifold feature quads...)

As for the ply format.... is about the only format I know that preserves color per vertex, so that can be useful (see my o-o-o-o-old post on ambient occlusion computation). Beside, I always work with that format at work so it's familiar to me. But you are right,   off   obj should be put as the first default option...
 
mtarini said:
As for the ply format.... is about the only format I know that preserves color per vertex, so that can be useful (see my o-o-o-o-old post on ambient occlusion computation).
Useful to know, I'll keep that in mind!

mtarini said:
But you are right, off should be put as the first default option...
Um, don't you mean OBJ (wavefront obj)? Or is there something peculiar about OFF that differentiates it from OBJ too? I just realized I haven't tested the OFF format yet, will do so now :razz:

edit: If I try reimporting OFF files exported from openBRF its vertex colour changes to (mostly) red (originally uncoloured/white):
openBRF0013_bugrept_1.jpg
Apart from that I can't tell if that's bad or fixable in editing programs since my Blender's OFF importer script doesn't seem to be working well to check it out myself.
 
mtarini said:
Format:
- currently, OpenBrf understands DXT3 and DXT5 textures, which are the vast majority of textures used in M&B.
  It does not understand DXT1 or tiff textures.

Hey mtarini.

I think it would be a good idea to include DXT1 if possible; this format is (or should always be) used whenever there's no need for an Alpha channel.
 
Back
Top Bottom