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

Users who are viewing this thread


Sergeant Knight
Bloc said:
Sadly, Its not working properly. Here is the screenshot,

Oh, I believed the problem only affected the Graphic window!
Only now I see what you a it is on the GUI part as well.

That's unfortunate. If it is what I think, I'm afraid that fixing that might take quite a bit of work on my side (but would also have beneficial side effects).


I wasn't able to show screenshots back then. Sorry for not being more clear.
But not much of people using 4K as far as I know, so I believe you can take your time. I hope you can fix it.  And you can send me latest build via PM, before you release. So I can test it for you, no worries.


Sergeant Knight
(after a few PMs with Bloc)
now (ver 0.0.82b) it works acceptably if not perfectly on a 4K screen. Thank you Bloc!


Sergeant Knight
Thank you mtarini for continuing to update (despite the data loss)

I'll test it when I resume modding (june 22) and report on any bug I see.


Grandmaster Knight
Big thanks for this update!

Just tested it (against v0.0.81b) and have some issues with "clean redundant vert/pos" operation, for example:


Sergeant Knight
Small discussion about future features which I am kind of considering:

1- ability to import new textures in as .png/.jpg and have them saved as .dds of a chosen format (DDX1,3 or 5).
Naturally there's plenty of tools to do that already, but I would have found an integrated feature of this kind useful.

2- incorporation of shaders written in GLSL for previews. Because, apparently, Warbands ports in platform other than windows already include GLSL versions of all the shaders so they could be easily used by OpenBRF as well. It would be a matter of making sure to feed them the right data e.g. about lighting environments. This would drastically improve accuracy of previews (what you see in OpenBRF is what you see in game), but might complicate the interface with the need to simulate e.g. night VS day previews.

(none of this has high priority)

If you have any suggestion shoot.



Sergeant Knight
Wow! Yours are the most well spotted + most clearly described bug reports I've ever seen!
Thank you.

I think I know what is going on. Neither versions is doing the right thing.

Longer explanation. "Clear redundant... etc" works by merging together "positions"  and "vertices" which are (almost) identical, which means which share all attributes. That is, for vertices: uv-coords, tangent dirs, normals, and colors; for positions: xyz pos, skinning, and vertex anims. Before, in 0.0.81, I erroneously disregarded tangent dirs, meaning that vertices which differed for tangent dirs only were unduly merged. Now, in 0.0.82, I "corrected"  that problem, but I'm being too strict: in the rightmost path, there are small differences everywhere because tangent dirs are first computed independently in each triangle, when they are still disconnected. Instead, I should probably allow for some tolerance. Will do that.


Grandmaster Knight
mtarini said:
Wow! Yours are the most well spotted + most clearly described bug reports I've ever seen!
"A picture is worth a thousand words"

The next difference between two versions:
- WireFrame on -> switches SpecMap off (even if still ticked) -> toggle SpecMap on/off has no effect -> need to turn WireFrame off first.


Sergeant Knight
So, the newest bug fix (0.0.82e) fixes:
[*] the minor wireframe + specular bug
[*] the small inconsistencies with tangent directions computation / vertex merging.

Here's how the latter works now:
When you [recompute tangent directions] now, it adds new vertices, if they are needed.
When you [clean redundant vertices pos], it doesn't over-estimate the needed vertices due to tangent dirs anymore

It is a bit long/technical to explain, but, super-short version:
[*] mesh vertices duplicates (aka vertex seams) are needed whenever any vertex attribute (normal, color, uv...) needs be discontinuous across two adjacent mesh faces. E.g. that happens over a UV cut, over a "hard-edge" (a crease, a discontinuous normal), etc.
[*] tangent direction is just another vertex attribute. This one is needed to correctly display (tangent-space-)normal-maps.  Usually, where UV is discontinuous (a UV cut), so are tangent directions, and viceversa. So, typically, storing tangent directions does not need any additional "vertex duplication" than the ones needed to store UVs.
[*] however, there is a special case when tangent directions needs be discontinuous but UV isn't. That can happen only when a part of a mesh where textures are mirrored meets a part of the mesh where textures are not mirrored.
[*] now, when you recompute tangent directions, OpenBRF detects the above case and responds by adding new vertex duplicates as needed. This means that now it can increase the number of vertices when you "recompute tangent dirs". If the seams are already there, it works just as before (this happens for all vanilla meshes I could test with). If the seams are not needed, it works just as before (this happens if the texture is never applied flipped over the mesh).
[*] note: this only happens when you explicitly ask OpenBRF to recompute tangent directions for you. No additional vertices are added when tangent-directions are silently and automatically pre-computed for previewing purposes only (i.e., when a bumpmapped mesh has no tangent directions stored in it).
[*] when you "Clean redundant vertex pos",  OpenBRF can now merge vertices more aggressively/smartly because the cases when a separate copy of the vertex is actually needed due to tangent directions are correctly identified (it's the special case above).

Thank you [[email protected]] for reporting the problems above. Does it behave more sensibly now?


Grandmaster Knight
Yes, this bug is eliminated. Thank you!

Just spotted a minor one in 0.082d & e (0.081b is fine): combine male & female armour meshes OR "Add feminized frame" -> set "Animation" to e.g. "run_man_forward", play:
- even if user sees male frame, program changes view to the female frame,
- when user switches to 1st or 2nd frame, running animation is paused.
I have a question. I opened the body .brf file for Viking Conquest, and exported the female body mesh as a .stl to edit it. Is there any way to replace the original mesh with the edited one?


Does anyone have a download link for version 0.0.81b (the last version before the latest one)? Or can upload it and post a link? I'm on an old crappy computer atm and new version just shows blank white in the viewing window, not even the floor grid.


Grandmaster Knight
I'm having an error with this new version... everytime I try to open the application throws an error saying that MSVCP120.dll is missing...


Grandmaster Knight
Nothing. I've tried this already. Even I've tried to download manually this MSVCP120.dll and put it in the openbrf folder. Then it says it's missing the MSVCR120.dll, I download it also, put it in the folder, and then it throws another error message wich is not related with a missing dll.
Pure madness  :dead:


Well, I found and older version of Open Brf (0.079) and this I can use it with no problems, so is for sure a problem with the new version.
For anyone interested:!AkkUhLxD!cEnbxME3N4b2-fmf-JRMQdz_HcNGRVrB3SQT76DYw1s
Top Bottom