The Shadow
Recruit
mtarini said:
Could you make a message box pop up confirming this before it's done, for multiple items? Just so that no one does it by accident?
Download link and main info! [latest ver 0.0.82e -- 19 Jun 2016]
- Thread starter mtarini
- Start date
Users who are viewing this thread
Recruit
Could you make a message box pop up confirming this before it's done, for multiple items? Just so that no one does it by accident?
-
I've done my own testings and it works.Spak said:
Let's see. After some hardcore use of some days here I come with my complete bug report:
- The hue slider, keeps pointing to the blue after oversaturate the vertex coloring.
- Now when you're going to create a collision mesh from a model it throws a windows color selection dialog, once you close the handle, it works as expected.
- The
funtionality is currently broken due to some mistakes when creating the proper registry keys.Code:
Register Extension
- The hue slider, keeps pointing to the blue after oversaturate the vertex coloring.
Code:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\brf]
@="Mount and Blade resource filess"
[HKEY_CLASSES_ROOT\brf\DafualtIcon]
@="C:/Program Files/OpenBRF/openBrf.exe,0 test"
[HKEY_CLASSES_ROOT\brf\shell]
@=""
[HKEY_CLASSES_ROOT\brf\shell\open]
@=""
[HKEY_CLASSES_ROOT\brf\shell\open\command]
@="\"C:/Program Files/OpenBRF/openBrf.exe\" \"%1\""// And here's the desired thing:
Code:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.brf]
@=""
"FriendlyTypeName"="Mount&Blade Binary Resource File"
"PerceivedType"="Application"
[HKEY_CLASSES_ROOT\.brf\DefaultIcon]
@="C:\\Program Files\\OpenBRF\\openBrf.exe,0"
[HKEY_CLASSES_ROOT\.brf\shell]
[HKEY_CLASSES_ROOT\.brf\shell\open]
[HKEY_CLASSES_ROOT\.brf\shell\open\command]
@="\"C:\\Program Files\\OpenBRF\\openBrf.exe\" \"%1\""- A few untranslatable items. As the close button in the
and theCode:
Error CheckerandCode:Okbuttons in theCode:Cancel,Code:New Material, and so. Only minor details of polishement.Code:Menu Background
Also, orientation of the text label over theresults box should be inverted.Code:Error Checker
So if the translation text is longer than the original the text gets hidden into the window border. Currently is a little trickier to get it completely translated.
Aand... here's my revised translation for the Spanish 0.0.55 version: Get the link!
That's it! I'm more than pretty sure that those are the only remaining bugs alive
New version!!
From first page...
Edit: in version 0.0.56b, bug fixed: did not put correct "timings" in new feminine frames. See a few posts below.
Extra info:
1st point: feminine armors. You probably know that M&B (and WarBand alike) keeps a different "vertex animation frame" for masculine and feminine versions of an armor. Now OpenBRF can build the feminine version from the masculine version. Don't expect miracles: if you build the feminine version by careful, artful, manual mesh editing, you will get better results. But it is not bad to be automatic.
After you applied this option, to see how it went, switch to the feminine frame of the mesh (by changing the "frame" inside the "data" box in the center).
Now, unfortunatley Warband and M&B use different conventions: M&B uses the 1st frame as F, 2nd as M. WB the other way round. So OpenBRF tries to guess which version your mod is for and acts accordingly to decide where to place the F armor frame it just built. If your mesh already have a feminine frame, it asks if you want to overwrite it. In the mod, the new armour should just work, switching frame according to wearer's gender.
Details on how it was done: I took a wide array of native dual-gender meshes, and I made OpenBRF learn how to use rigging as a guide to transform M into F. For example, all vertices tied to the chest bone undergo, on average, this and that transformation, and so on.
2nd point: AO on multiple meshes. This is the so-called lazyass option to compute ambient occlusion (AO) on several selected-meshes at once. The way this is done depends on the view mode (see at the bottom of the OpenBRF window). If you are on "combo" mode (all meshes are seen combined in the same space), AO will be computed by letting each mesh softly shadow all other meshes, like it did before. If you are on "side-to-side" mode, each mesh will have AO computed on its own, independently from the others. The former is needed when you have a static scenery object (say, a castle) composed of several submeshes. The latter, when you want to quickly compute AO over a bunch of separated objects (e.g. all your helmets). Edit: be aware that it can take some time to compute them all (it get get unresponsive for, like, 20 secs).
More info on ambient occlusion (AO) in openBRF (what it is and what it is for) can be found around here, in the prev few pages.
3rd point: "repeat last command" option. Now, after issuing any command, you can reissue it again by just pressing ctrl+R, or by going under [tools]->[repeat <whatever> ].
Digression: I should spend a word of prise for QT, the GUI library (by Nokia, originally by Trolltech) which I'm using to make openBRF. Even if this repeat-command was not planned in advance, it was relatively easy and smooth to add it, even this late in the dev of OpenBRF! QT is really one of the best GUI toolkits I've ever seen. Powerful, yet flexible. Elegant to code, yet efficient to run. Cross platform for real. Easy to code, simple or complex stuff alike. Complete. It is steadily improving too, version after version. If really Microsoft will have a go at ruining it (in favour of its .net inferior stuff), as a consequences of its recent alliance with Nokia... well that will be a sad day in the history of C++ programming.
4th point: bugfixes. I've covered the texture error reported and carefully investigated by Spak, and most errors reported by Swyter (thanks to both!!!). Not sure the register extension thing is ok now. The "dot" should have been there already so I'm confused. Added a few translatable lines. Fixed the collision object thing. Fixed the hue slider thing. Updated with latest spanish translation by Swyter.
Edit: forgot to mention: slightly more informative error messages if it fails dumping names of all brf in ini files.
From first page...
Edit: in version 0.0.56b, bug fixed: did not put correct "timings" in new feminine frames. See a few posts below.
Extra info:
1st point: feminine armors. You probably know that M&B (and WarBand alike) keeps a different "vertex animation frame" for masculine and feminine versions of an armor. Now OpenBRF can build the feminine version from the masculine version. Don't expect miracles: if you build the feminine version by careful, artful, manual mesh editing, you will get better results. But it is not bad to be automatic.
After you applied this option, to see how it went, switch to the feminine frame of the mesh (by changing the "frame" inside the "data" box in the center).
Now, unfortunatley Warband and M&B use different conventions: M&B uses the 1st frame as F, 2nd as M. WB the other way round. So OpenBRF tries to guess which version your mod is for and acts accordingly to decide where to place the F armor frame it just built. If your mesh already have a feminine frame, it asks if you want to overwrite it. In the mod, the new armour should just work, switching frame according to wearer's gender.
Details on how it was done: I took a wide array of native dual-gender meshes, and I made OpenBRF learn how to use rigging as a guide to transform M into F. For example, all vertices tied to the chest bone undergo, on average, this and that transformation, and so on.
2nd point: AO on multiple meshes. This is the so-called lazyass option to compute ambient occlusion (AO) on several selected-meshes at once. The way this is done depends on the view mode (see at the bottom of the OpenBRF window). If you are on "combo" mode (all meshes are seen combined in the same space), AO will be computed by letting each mesh softly shadow all other meshes, like it did before. If you are on "side-to-side" mode, each mesh will have AO computed on its own, independently from the others. The former is needed when you have a static scenery object (say, a castle) composed of several submeshes. The latter, when you want to quickly compute AO over a bunch of separated objects (e.g. all your helmets). Edit: be aware that it can take some time to compute them all (it get get unresponsive for, like, 20 secs).
More info on ambient occlusion (AO) in openBRF (what it is and what it is for) can be found around here, in the prev few pages.
3rd point: "repeat last command" option. Now, after issuing any command, you can reissue it again by just pressing ctrl+R, or by going under [tools]->[repeat <whatever> ].
Digression: I should spend a word of prise for QT, the GUI library (by Nokia, originally by Trolltech) which I'm using to make openBRF. Even if this repeat-command was not planned in advance, it was relatively easy and smooth to add it, even this late in the dev of OpenBRF! QT is really one of the best GUI toolkits I've ever seen. Powerful, yet flexible. Elegant to code, yet efficient to run. Cross platform for real. Easy to code, simple or complex stuff alike. Complete. It is steadily improving too, version after version. If really Microsoft will have a go at ruining it (in favour of its .net inferior stuff), as a consequences of its recent alliance with Nokia... well that will be a sad day in the history of C++ programming.
4th point: bugfixes. I've covered the texture error reported and carefully investigated by Spak, and most errors reported by Swyter (thanks to both!!!). Not sure the register extension thing is ok now. The "dot" should have been there already so I'm confused. Added a few translatable lines. Fixed the collision object thing. Fixed the hue slider thing. Updated with latest spanish translation by Swyter.
Edit: forgot to mention: slightly more informative error messages if it fails dumping names of all brf in ini files.
"Mommy, I want to be a great programmer when I grow up, just like mister Tarini!"
I am speechless...
EDIT: To make things clearer: I am also downloading it immediately.
I am speechless...
EDIT: To make things clearer: I am also downloading it immediately.
Well, if you do it manuall you could get better results.
But for lazy asses like me (or people with no time, like me), the auto generation is awesome!
But for lazy asses like me (or people with no time, like me), the auto generation is awesome!
The Shadow
Recruit
I am constantly amazed. I was just wondering how to do the female armors a day or two ago.
Lord_Cheap
Squire
Wow... Great stuff!
I think I've found a bug though: when I get a female character to wear a piece of armour/clothing which has a female version made on OpenBRF, no mesh comes up (ie, its as if she has no body). I think you know what I mean >.<
I think I've found a bug though: when I get a female character to wear a piece of armour/clothing which has a female version made on OpenBRF, no mesh comes up (ie, its as if she has no body). I think you know what I mean >.<
Lord_Cheap said:
ooops you're right. How could I forget... timings! Frame timings must be set right.
Ok, uploading a new version soon,
but meanwhile, it should be enough to manually set the timings of the frame:
in warband:
masculine frame (n.1) => timing = 0, feminine frame (n.2) => timing = 10,
in M&B:
feminine frame (n.1) => timing = 10, masculine frame (n.2) => timing = 20.
Sorry, I forgot.
(naturally, "timing" here has nothing to do with time... it is just the way which the game uses to pick which frame of the outfit must be used)
Edit: ok, updated now. Ver 0.0.56b... re-download if you intend to use that option.
Can anyone confirm that the game likes it now?
Lord_Cheap
Squire
Yup, works fine!
fedeita said:now it need only to render normal map and it will be perfect
Mmmm, I'm not much into them because my main motivation is TLD (The Last Day, the module about Lord of the ring) which is for MB, not WB (and in MB normalmaps are a little messier). But I guess sooner or later I'll have to include that. Not only to let modders preview how they normalmaps look like before loading the game. There is one more reason, unless I'm wrong.
Specifically, in WB normalmaps are in "tangent space". Which means that the mesh needs to have "tangent directions" defined all over it. WB native meshes which use normalmaps have them, unless I remember wrong.
I'm just making educated guesses, i think that normal maps for new meshes might not work in WB. Is that the case?
That would be because, as I said, they would need these "tangent directions", and they don't have them.
Now, it would be possible in OpenBRF to put an option to compute them for a given mesh, so that they are saved and used by the game.
Confirm, that currently (in WB) a normal map does not work correctly if applied over a non-native mesh?
and about the LOD MAKER !!!
Tld team will greatly appreciate that, particularly GA !!
Maybe a lod.1 and lod.2, I think that the others have to be uvmap separately.
But, it must be to difficult to create a option like that since they are already some expensive lod-maker on the web.
Tld team will greatly appreciate that, particularly GA !!
Maybe a lod.1 and lod.2, I think that the others have to be uvmap separately.
But, it must be to difficult to create a option like that since they are already some expensive lod-maker on the web.
Actually there is one free lod maker that doesn't work bad, I use it long time, Balancer Lite.
OT:
Some bug I think.. Norton Internet Security consider this last update to be a high risk virus and removes brf.exe, I excluded it from norton list but now after some time I get runtime error when trying to open some brfs, I'll try to test few things out to see if it's antivirus that's causing the issue.
OT:
Some bug I think.. Norton Internet Security consider this last update to be a high risk virus and removes brf.exe, I excluded it from norton list but now after some time I get runtime error when trying to open some brfs, I'll try to test few things out to see if it's antivirus that's causing the issue.
Update! This is the "request" update.
First point, just as it says, renders bumpmaps (on rigged or non rigged meshes alike)
Left: no bumpmap. Right: bumpmap.
Above: rgb texture; Below: no rgb texture;
I wonder if bump-mapping could be a bit overrated?
They look v. cool without color textures, but not much of a difference with color textures.
Maybe it would be different if more specular is used.
Beware: it seems that the game uses at least to kind of normal maps. I'll call them the green kind and the blue kind.
Both are in tangent space, but the "green" kind seems to have the blue and green channel swapped.
I failed to find an easy way to tell them apart from openbrf (in game, the difference is in the way the shader uses them, and from openbrf I cannot use right away original game shaders). So, for now, only the "blue" kind works properly.
For now, this is just a "preview feature" (i.e. its only use is to let you preview your meshes better). Sometimes, I'll try to find time to add a tangent direction computation tool, so that openBRF can be of some help in order to add normalmaps to custom objects. Longer info: in order to use tangent space normal maps, on needs tangent directions defined over the mesh. When you import a new mesh, it won't have them. OpenBRF could in the future compute them for you. They can be saved only in WB format, though.
(you have to activate "on Mesh rendering"=>"infer settings for material flags" under settings to activate normalmaps)
(btw I corrected a bug in that area. If you used to have that option disabled, try enabling it in this version. It also activates the "iron shader" simulation in OpenBRF, the one where alpha channel dictates how shiny stuff is.)
Second point, more importantly, its my first attempt at automatic LOD construction (for rigged meshes too).
So how good it is? Once again, it cannot beat manual LOD construction.
Also the number of polygons is a little of a rule of thumb... Lod 1 is 50% polys, lod 2 is 25%, lod 3 is 12.5%, lod 4 is half that much.
It has defects, most important one is little gaps that forms. I've tryed one thing or two already and this is the best I got so far.
Occasionally, it just sucks. You might have to trash a few lods from time to time, or substitute them with your own (remember the game just accepts them if they are present, ignoring missing lods).
What remains to be seen is how good they look in game.
First point, just as it says, renders bumpmaps (on rigged or non rigged meshes alike)
Left: no bumpmap. Right: bumpmap.
Above: rgb texture; Below: no rgb texture;
I wonder if bump-mapping could be a bit overrated?
They look v. cool without color textures, but not much of a difference with color textures.
Maybe it would be different if more specular is used.
Beware: it seems that the game uses at least to kind of normal maps. I'll call them the green kind and the blue kind.
Both are in tangent space, but the "green" kind seems to have the blue and green channel swapped.
I failed to find an easy way to tell them apart from openbrf (in game, the difference is in the way the shader uses them, and from openbrf I cannot use right away original game shaders). So, for now, only the "blue" kind works properly.
For now, this is just a "preview feature" (i.e. its only use is to let you preview your meshes better). Sometimes, I'll try to find time to add a tangent direction computation tool, so that openBRF can be of some help in order to add normalmaps to custom objects. Longer info: in order to use tangent space normal maps, on needs tangent directions defined over the mesh. When you import a new mesh, it won't have them. OpenBRF could in the future compute them for you. They can be saved only in WB format, though.
(you have to activate "on Mesh rendering"=>"infer settings for material flags" under settings to activate normalmaps)
(btw I corrected a bug in that area. If you used to have that option disabled, try enabling it in this version. It also activates the "iron shader" simulation in OpenBRF, the one where alpha channel dictates how shiny stuff is.)
Second point, more importantly, its my first attempt at automatic LOD construction (for rigged meshes too).
So how good it is? Once again, it cannot beat manual LOD construction.
Also the number of polygons is a little of a rule of thumb... Lod 1 is 50% polys, lod 2 is 25%, lod 3 is 12.5%, lod 4 is half that much.
It has defects, most important one is little gaps that forms. I've tryed one thing or two already and this is the best I got so far.
Occasionally, it just sucks. You might have to trash a few lods from time to time, or substitute them with your own (remember the game just accepts them if they are present, ignoring missing lods).
What remains to be seen is how good they look in game.
A few examples: originals meshes on the left, then lods 1 to 4.
Above: the ones made by OpenBRF.
Below: the lods found in native game (they are better).
Above: the ones made by OpenBRF.
Below: the lods found in native game (they are better).
The Shadow
Recruit
Mr. Tarini, you are a god amongst modders. Great choice with the bumps by the way, I've never really seen any green ones used in M&B.
Also, the lod tool will save eons of time for making flora lods. I don't know how to say thank you enough.
EDIT: Does OpenBRF render specular maps?
2nd EDIT: Might want to check your loading mem allotment. Upon starting it just loads and loads and loads more memory, about 100,000k/s until my computer completely freezes and the only option is reboot. I tried checking the source code, but I don't know jack squat of where to begin, and main was confusingly short.
Also, the lod tool will save eons of time for making flora lods. I don't know how to say thank you enough.
EDIT: Does OpenBRF render specular maps?
2nd EDIT: Might want to check your loading mem allotment. Upon starting it just loads and loads and loads more memory, about 100,000k/s until my computer completely freezes and the only option is reboot. I tried checking the source code, but I don't know jack squat of where to begin, and main was confusingly short.
Awesome work, Marco!
For lod3-4 you better just substitute preconstructed ones from vanilla for all kinds of items
lod3 = 6 tetrahedrons for armor, 2 tetrahedrons for helmet with cutout for face, 2-4 triangles for weapon
lod4 = 2 tetrahedrons for armor, tetrahedron for helmet, 2-4 triangles for weapon.
Just scale them to mesh and uv-map them automatically to item texture sheet to resemble item color balance, cause this is the most tedious operation
For lod3-4 you better just substitute preconstructed ones from vanilla for all kinds of items
lod3 = 6 tetrahedrons for armor, 2 tetrahedrons for helmet with cutout for face, 2-4 triangles for weapon
lod4 = 2 tetrahedrons for armor, tetrahedron for helmet, 2-4 triangles for weapon.
Just scale them to mesh and uv-map them automatically to item texture sheet to resemble item color balance, cause this is the most tedious operation
mtarini said:Update! This is the "request" update.
First point, just as it says, renders bumpmaps (on rigged or non rigged meshes alike)
Left: no bumpmap. Right: bumpmap.
Above: rgb texture; Below: no rgb texture;
I wonder if bump-mapping could be a bit overrated?
Beware: it seems that the game uses at least to kind of normal maps. I'll call them the green kind and the blue kind.
Both are in tangent space, but the "green" kind seems to have the blue and green channel swapped.
I failed to find an easy way to tell them apart from openbrf (in game, the difference is in the way the shader uses them, and from openbrf I cannot use right away original game shaders). So, for now, only the "blue" kind works properly.
For now, this is just a "preview feature" (i.e. its only use is to let you preview your meshes better). Sometimes, I'll try to find time to add a tangent direction computation tool, so that openBRF can be of some help in order to add normalmaps to custom objects. Longer info: in order to use tangent space normal maps, on needs tangent directions defined over the mesh. When you import a new mesh, it won't have them. OpenBRF could in the future compute them for you. They can be saved only in WB format, though.
(you have to activate "on Mesh rendering"=>"infer settings for material flags" under settings to activate normalmaps)
(btw I corrected a bug in that area. If you used to have that option disabled, try enabling it in this version. It also activates the "iron shader" simulation in OpenBRF, the one where alpha channel dictates how shiny stuff is.)
Second point, more importantly, its my first attempt at automatic LOD construction (for rigged meshes too).
So how good it is? Once again, it cannot beat manual LOD construction.
Also the number of polygons is a little of a rule of thumb... Lod 1 is 50% polys, lod 2 is 25%, lod 3 is 12.5%, lod 4 is half that much.
It has defects, most important one is little gaps that forms. I've tryed one thing or two already and this is the best I got so far.
Occasionally, it just sucks. You might have to trash a few lods from time to time, or substitute them with your own (remember the game just accepts them if they are present, ignoring missing lods).
What remains to be seen is how good they look in game.
A few examples: original, then lods 1 to 4.
Above: the ones done by OpenBRF.
Below: the original ones in game (they are better).
DEUS MARCO !!!!!
I'm crying
edit: features are relly cool !!! but it crash every time I double click on the icon
