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

Users who are viewing this thread

Version 15 is looking good! Btw, not sure if this been suggested before, but will you add the List like the Flags has (you click the [...] button and a list of the flags come up) to the Shader as well?
 
cdvader said:
Version 15 is looking good! Btw, not sure if this been suggested before, but will you add the List like the Flags has (you click the [...] button and a list of the flags come up) to the Shader as well?

I wish I could, but where to recover the information about which bit does what?
Same for mesh flags (all at 0 as far as I know: exceptions?), and body "pieces" (cylinders and spheres) too...
 
Not sure if this is what you're looking for, but in Mount&Blade folder there are .fx and .pp files which seem to be about shaders.
 
So, here is the updates I've implemented while network-less...
Ver 0.0.15 (29 Aug):
- special fast load of all resources in the module.ini file
- auto-completions of stuff (texture, material, shader names).
- navigation of a dataset (see above)
- correct and complete texture-material in a mod. Now it should always locate the texture to be used for a given material (in mesh previews). (but, possible DXT1 texture problems?)
- now possible to edit data for multiple materials at once, including flags (and to edit "used material" for multiple meshes).
- minor: when you copy (ctrl-c) a texture/material/shader, you can paste (ctrl-v) its name in any appropriate box (e.g. in the "used material" box of a mesh).
- fixed bug with recompute-normals/vertex-unification of SMD files (used to cure "flat shading" effect).

Thanks Highelf for the SMD dataset, it was used in the last bug fix in the list.

Dataset navigation means simply that by pressing Ctrl-Right you go from a mesh to its material, or from a material to any of its shader/textures... To chose which one, click on its label (I mean the writing saying "diffuesA" or "bump"). Ctrl-left goes back. This works if the destination object is in the module.ini file. If you edit it, you can reload it in the editor by pressing F5.

It is all in the "module" menu anyway.

The rest is pretty self-explanatory. Now I should go back in this thread and look at all the many bug reports and suggestions...
 
Note: The download of the Source is bugged. I only get a 4.0kb file which I can't open.
 
cdvader said:
Not sure if this is what you're looking for, but in Mount&Blade folder there are .fx and .pp files which seem to be about shaders.

I know them well, but that still doesn't help  :sad: ... (I've been successfully experimenting with M&B shaders quite a lot in the past, but I found nothing that told me what the flags are for... one of my favorite result was my lego-brick shader).

cdvader said:
Note: The download of the Source is bugged. I only get a 4.0kb file which I can't open.

Oops forgot about it, thanks, fixed.
 
The new ruler option is fantastic.  Anyway we can get these for the two additional axis?

I would use it for more accurately placing muzzle flashes at the end of firearms.
 
Great update mtarini, lovin' the new ruler!

The bug with texture coordinates highelf reported is still present though: http://forums.taleworlds.com/index.php/topic,72279.msg1920543.html#msg1920543

Also, if I export from openBRF a static object that already has a correct texture coords (e.g. static meshes imported via BRFedit) and reimport it into openBRF the texture coordinates won't screw up. Seems like the bug only happens if the mesh was imported from the source OBJ.

Highelf: Are you still experiencing this bug as well?


And... I don't know if this other bug is related to the above bug but it's been reported as well: http://forums.taleworlds.com/index.php/topic,72279.msg1928710.html#msg1928710
 
Thanks!

I tried replicating it and failed. In particular, I tried exporting an Obj, importing it in Wings3D, changing it here and there, exporting an obj again, and reimporting it. It seems it worked. Hum. How did you get your results, exactly?

As for the other bug (texture not showing up in game)... that's scary, I wonder what went wrong. I cannot replicate it right now (lack of a working M&B copy), I'll try soon. Edit: it won't be trivial because I'll need to find an some object that I will immediately find in game. Did anyone else replicate the bug so far?


Meanwhile, I released another version: added vertex animations support! I'll need to explain a little about that in another post.
 
mtarini said:
Thanks!

I tried replicating it and failed. In particular, I tried exporting an Obj, importing it in Wings3D, changing it here and there, exporting an obj again, and reimporting it. It seems it worked. Hum. How did you get your results, exactly?

Could the texture coordinates in wings3D's OBJ be exported differently? Because it looks like if I try it with Native models without editing them the same bug occurs.
Here's the process of how I tested for the bug:

  • Create new model in Blender -> export as OBJ-> import in BRFedit = textures OK
  • The same OBJ exported from Blender -> import in BRFedit -> view in openBRF = textures OK
  • The same OBJ exported from Blender -> import in openBRF = textures misaligned
  • The same OBJ exported from Blender -> imported into BRFedit -> exported using openBRF -> reimport into openBRF = textures OK
  • Native OBJ exported from BRFedit -> reimported using openBRF = textures misaligned

(sorry for the anal-retentive formatting, just making sure no confusion arises :razz:)

Here are the files if you'd like to test them: http://amade-wossname.com/tmp/mnb/OBJ_tex_test.zip
edit: tests were done in 0.0.16, haven't tried with 0.0.17 you've just released to see if it's any different


mtarini said:
Meanwhile, I released another version: added vertex animations support! I'll need to explain a little about that in another post.

Hot damn! You've done so much I wonder how can we ever repay you for all you've done?  :mrgreen:
 
Vertex animations with openBRF


What a BRF Vertex animation is:

A vertex animation is just a sequence of meshes, one mesh per frame. Each frame is also associated to a timing. But, here's the catch, each frame only redefines positions and normals. All frames share the same: triangles (which triangle connects which vertices), texture coords, rigging (in case mesh is also rigged), etc  (this also means that the frames are bound to have the same number of vertices/faces).

Note that the frames must be considered just keyframes. The game is "free" to interpolate between two frames of the vertex animation to get smoother animations (it will exploit that, for example when it animates bows).


How are they used in M&B:

For many things!
  • animated icons on the map (in this case the 1st frame is unused, the second is the stance pose, the rest is the walking sequence)
  • weapons animations (like the bow string).
  • armours: the 1st frame is unused, the second frame is the male version, the third the female version
  • quivers and the like: each frame represent a different number of arrows left
  • shields: a frame for when they are fastened around the arm, a frame when the belt is loose
  • scabbards: first frame is with sheathed weapon, second frame without it
  • hands/gloves: first frame open, second half-closed, third closed in a fist/grab
  • customizable heads: frame 0 is the base head, each frame is the effect of a "slider", like "eye-to-eye distance".
... and maybe other things too.


How to make your own in OpenBrf:

UPDATE: since ver 0.38 (Aug 2010) you can also export/import vertex animations as MD3 files (the format introduced by Quake3).
The other option, descried in the following, is still available:


You stack them frame by frame. So, typically, you export a frame, edit it, reimport it and attach it to your animation.

The Cut and paste way: with ctrl-alt-x, ctrl-alt-c, ctrl-alt-v (as you can see in the edit menu) you perform cut and paste operations that refers to individual frames (and apply to the currently selected frame). So you can import a mesh, and stack it to your animaton by cut and paste. You can also redefine frame order, duplicate frames, etc.

Direct frame import and attach: when your frame is in an external file, as a shortcut, you can also import a static mesh directly as an additional frame of the currently selected mesh (menu "import").

Remember to edit manually the times (in the "data" box) of each frame, at the end of the process.


The problem with frame by frame stacking, and possible solutions:

What makes the process messy (if you tried in other occasions, like in OpenBRF you know), is that when you assemble frames you are assuming that not only the vertex number, but even their internal order has been kept the same by all import/export operations. Otherwise... say vertex N.412 is  on the head in frame 1, but on the foot in frame 2: then it kills everything! Textures, triangles, interpolations... result is a mess. That's because, remember?, triangles/text-coords/etc are shared by all frames. So, if you have a triangle connection vertex N.412, N.51 and 413 together, that applies to all frames.

In OpenBRF you have two options to merge a frames into an animation.

Option 1: you pray that the vertex order is kept unmodified by your mesh import/exports (openBrf will comply, but who knows what, say, Blender or Wings3D will do). This is the "old way". Works, sometimes.

Option 2: you resort to use texture coordinates as unique identifiers of vertices.  You just assign to each vertex of your mesh an unique u-v point in texture space. (((Note that sometime you want different points to share the same texture coords: for example, if you have a quiver, each arrow is a copy of each other arrow including uv coords, and if you have a symmetric something, the left half will use the same texture coords of the right half. In these cases, just displace the text each vertex by a little tiny bit in your mesh editor. Half a fraction of a texel (a texture pixel); it won't make any practical difference, but it will be enough for OpenBrf to tell vertices apart.))) Once your texture coords identify the vertices in frame 1, don't touch them anymore. Feel free to edit mesh 3D shape for all other frames!

You select which one of the above is your favourite option, 1 or 2, in the option menu ("Option" => "On assemble vertex animation").


Note that the system is somewhat robust: if Option 1 fails (e.g. different number of vertices) it will fallback to option 2 automatically. If Option 2 fails (e.g. same texture coords for different points), it will fallback to option 1 (for that vertex only).


Let me know how your experiments go!!!



 
Very cool. I'm too tired atm, though, so I can't experiement. I will try tomorrow, though.
 
Vertex animation import - Preliminary report:

Haven't tested it in-game yet but but there's a problem in which when openBRF imports the frame it does not put it after the previously selected frame. This is using both the copy/paste and direct import frame method. When importing a new frame, openBRF puts it before the previously selected frame. So the base mesh, the static mesh you're appending to, will be displaced from frame 0. There's a workaround to this in which I can as you mentioned previously redefine the frame orders by copying the base frame and pasting it back in its proper place; however, I don't know if this would affect how openBRF will read and compare the frames for vertex IDs since it's all rearranged...

Upon checking the version of openBRF it still reads 0.0.17 (no b at the end). Is it still the older bugged version?

Oh, and regarding this: http://forums.taleworlds.com/index.php/topic,72279.msg1945478.html#msg1945478
Tested with 0.0.17 as well - please disregard the edit I put in there.


edit:
In game test!
openBRF0017b_vertAnimTest.jpg

Middle, icon while animated (the sails billow a bit). Left and right, icon at rest position (sails are slack).
Vertex animation seems to work. However I can't determine if the vertex IDs were messed up - I can tell that it's messed up if I was using BRFedit to append frames and the icon will animate correctly but the shaders can't calculate the lighting on it properly - so you get textures that flash around a bit like a broken neon light (see screenshots below). Due to the issue where M&B doesn't show the textures after the BRF is edited in openBRF I can't see if the vertex IDs are also messed up if done in openBRF.

outrigger_test.jpg

For the Hari Ragat mod.
In the two insets at the top you can see the sails are "sparkly" during animation due to appending with messed up vertex IDs in BRFedit.

 
It looks like the ruler tool is limited to 250 centimeters... Preferably it should be able to reach for more than 500. (max game length is 512 cm I think)
 
Back
Top Bottom