Specialist
Master Knight
How did you come by that?
Suggestions/requests thread -- post yours here
- Thread starter mtarini
- Start date
Users who are viewing this thread
Master Knight
That is a pity.
On the animations, it's puzzling; the animations specify explicitly what state they blend to, so I'm not sure that was the catch. I honestly think that it's just that Races were constructed rather ad-hoc in various parts of the code, and they never saw any need to make it flexible.
For example, header_skins is where most of the data should go; references to walk sounds, the particle effect if walking on a "dusty" surface, other sounds and particle effects, what color is used in vertex colors if the Agent is wounded or does damage to others in hand-to-hand combat, etc., etc.
Yet the data isn't centralized there at all; it's scattered all over the place. It honestly feels like they added data to the engine as they realized they needed it, then never went back for a second pass on the code to make it all modular and to make each Race a nice clean set of references. Insofar as this was ever done, as in facial morphs and the like, it is built like it should be, but it's disappointing how, instead of a Race being a nice collection of references to data defined elsewhere and control parameters, some of it operates that way and some of it is entirely hard-coded and can only be disabled by omission or changes to parameters.
I understand that they were probably in a hurry and just stopped messing with that once it worked, but it's not where I would have considered it done yet; I feel very strongly that organization helps keep future features cleaner, and it would have been nice to have that on hand for future uses of the engine. I mean, if it wasn't for silly things like this, the engine would be a lot more general-purpose, and I'm sure somebody would have pitched a fantasy title using it to Paradox by now. I have no idea what a spaghetti mess that is on the engine side, of course, but it's probably not too awful at this point and adding some additional data references to module_skins so that making a race with all of the essentials working properly wasn't very difficult.
But they just wanted humans, male and female, so there you go.
It's a really annoying limitation when it comes to weapons, though; there are a lot of weapon types and fighting styles I feel can't be animated properly due to this issue, and experiments in that vein have led me down a lot of blind alleys. It's really a pity that you can't establish an explicit relationship between X animation set and Y weapons in the header files, where X can be a new group of animations. I just looked everything over for the nth time, though and it really does appear that the engine calls this stuff by number and doesn't allow for new ones, which is why we're not allowed to modify the core animation order.
I concur.
My dream is that Mount and Blade eventually goes opensource (or else that I'm allowed in any other way to change its code).
Attack animations: I know what you mean. The only one which I tried and which was not a "dead alley" is extreme: sacrifice one weapon category from native and substitute its animations for a new weapon category. In TLD (apart from the trolls/ents whose combat I scripted 100% so it can use any attack animation), I made a custom attack animation for orc bows (shot horizontally) substituting pistols, which we didn't need.
My dream is that Mount and Blade eventually goes opensource (or else that I'm allowed in any other way to change its code).
Attack animations: I know what you mean. The only one which I tried and which was not a "dead alley" is extreme: sacrifice one weapon category from native and substitute its animations for a new weapon category. In TLD (apart from the trolls/ents whose combat I scripted 100% so it can use any attack animation), I made a custom attack animation for orc bows (shot horizontally) substituting pistols, which we didn't need.
Hey mtarini, very cool release, but did you miss my suggestions post? 
http://forums.taleworlds.com/index.php/topic,168046.msg5055536.html#msg5055536
http://forums.taleworlds.com/index.php/topic,168046.msg5055536.html#msg5055536
Specialist
Master Knight
The ability to use semitransparent textures. I need to preview the materials with a semitransparent diffuse out of the game, so I can get a gauge of whether or not I need to make it more/less transparent. It's probably so dang hard that it's not worth it...but it would be Insanely useful
I'd like:
1. A straightforward, no-nonsense diffuse-to-vertex color transfer operation. Takes the currently-defined diffuse and then does a pixel sample at the uv of the vertex, transferring it to the vertex's color attribute. Would make working with foliage and certain other types of shader far easier, as they become available.
It'd be really useful if this data could be stored in an export format for further post-work, as well. Do either of the export formats allow for vertex colors?
I'm thinking that since PLY imports from MeshLab appear to be flawless now, maybe PLY is the best way to go back and forth.
2. An additive version of AO. How it would work: you'd select a sub-part, or parts, of a building or character model and apply AO, then adjust it to be reasonably subtle, then grab the whole thing and do a second pass of AO, darkening the current result, giving you a darkened interior with subtle gradations of darkness on interior details.
This would be a poor-man's version of the lighting burns that can be done in expensive software like Max (the only way to get it there would be to allow end-users to move and configure the virtual light sources in terms of position, color, intensity and falloff and add more than one light), giving building interiors a really polished feel, and I was thinking that it would probably be fairly easy to do, since it can just query the existing vertex color values as it goes, then multiply the results.
It probably won't work very well for anywhere that the AO would reach total black; one idea on that is that perhaps AO needs a cutoff slider to keep it in bounds, in terms of darkness, but frankly it's all just User Error, if they use two dark AO passes in a row and end up with blackness everywhere.
Anyhow, both of them aren't giant leaps forward, but would make life easier for a few of the trickiest things.
1. A straightforward, no-nonsense diffuse-to-vertex color transfer operation. Takes the currently-defined diffuse and then does a pixel sample at the uv of the vertex, transferring it to the vertex's color attribute. Would make working with foliage and certain other types of shader far easier, as they become available.
It'd be really useful if this data could be stored in an export format for further post-work, as well. Do either of the export formats allow for vertex colors?
I'm thinking that since PLY imports from MeshLab appear to be flawless now, maybe PLY is the best way to go back and forth.
2. An additive version of AO. How it would work: you'd select a sub-part, or parts, of a building or character model and apply AO, then adjust it to be reasonably subtle, then grab the whole thing and do a second pass of AO, darkening the current result, giving you a darkened interior with subtle gradations of darkness on interior details.
This would be a poor-man's version of the lighting burns that can be done in expensive software like Max (the only way to get it there would be to allow end-users to move and configure the virtual light sources in terms of position, color, intensity and falloff and add more than one light), giving building interiors a really polished feel, and I was thinking that it would probably be fairly easy to do, since it can just query the existing vertex color values as it goes, then multiply the results.
It probably won't work very well for anywhere that the AO would reach total black; one idea on that is that perhaps AO needs a cutoff slider to keep it in bounds, in terms of darkness, but frankly it's all just User Error, if they use two dark AO passes in a row and end up with blackness everywhere.
Anyhow, both of them aren't giant leaps forward, but would make life easier for a few of the trickiest things.
orangeknite1
Sergeant Knight at Arms
So I dont think this is in OpenBRF, correct me if I'm wrong. So I have noticed in many Engines that I have been working with like UDK they have a nice optimization feature. What you can do is make it so your alpha channel is your specular map. They they plug the alpha channel into there specular input and that therefore saves alot of space. So I would like a way to do this in OpenBRF please so say a checkbox next to the specular input that says "Use Alpha Channel as Specular". If you checked it, it would disable the alpha channel in the diffuse map and just use it in the specular channel.
That's more a shader thing then anything else, not OpenBRF related at all.
Do know that when you want a proper Alpha channel to support non-binary specmap you would be forced to use a DXT5 texture, the same memory size as Two times a DXT1 texture (diffuse + specmap)
In all essence the memory requirements will be exactly the same, the performance might only be slightly affected since your only executing one Tex2d call in the shaders fragment program but were talking about 0.01% performance increase which is neglect-able.
Native has support for alpha channel spec build into some shaders already, its the use_spec_factor bool set on the general shaders. (just check shader sources)
Do know that when you want a proper Alpha channel to support non-binary specmap you would be forced to use a DXT5 texture, the same memory size as Two times a DXT1 texture (diffuse + specmap)
In all essence the memory requirements will be exactly the same, the performance might only be slightly affected since your only executing one Tex2d call in the shaders fragment program but were talking about 0.01% performance increase which is neglect-able.
Native has support for alpha channel spec build into some shaders already, its the use_spec_factor bool set on the general shaders. (just check shader sources)
Yeah, basically we can do that in the engine already; it's not OpenBRF's issue.
There are actually really good arguments for not doing both specular and diffuse in the same bitmap; amongst other things, that allows for a colored specular map, which is really superior for anything that exhibits metallicity. Also, you can use a full-sized diffuse with a half-size specular and on a lot of things it's hard to even see it.
There are actually really good arguments for not doing both specular and diffuse in the same bitmap; amongst other things, that allows for a colored specular map, which is really superior for anything that exhibits metallicity. Also, you can use a full-sized diffuse with a half-size specular and on a lot of things it's hard to even see it.
Pumpkin Lord
Can you prepare a list of all current available shaders ready to be used?
What, for OpenBRF? Other than building a test platform shader that makes minor modifications to the GLSL to test Moar Metal with, I haven't done anything.
If you're talking HLSL, that list:
http://mbmodwiki.ollclan.eu/Category:Shaders
Plus the code I've released thus far in the HLSL thread is pretty much it right now.
If you're talking HLSL, that list:
http://mbmodwiki.ollclan.eu/Category:Shaders
Plus the code I've released thus far in the HLSL thread is pretty much it right now.
Pumpkin Lord
Hmm, not talking about the ones community did. But the ones BRF actually contains within itself.
Ah, the preview shaders, which OpenBRF uses for previewing the meshes.
There's maybe two of them built in, I don't even remember, but anyone can add new custom ones.
In the "customPreviewShaders.xml" file you can add custom custom vertex/fragment shader pairs, and also specify a set of technique names: OpenBRF will use that shader to preview any mesh which uses a shader using a technique named in that way.
(shaders are written in GLSL, and the example provided in OpenBRF distribution shows which attribute/uniform values you can use)
(you can use F5 from OpenBRF to immediately reload the shader file, after editing it)
There's maybe two of them built in, I don't even remember, but anyone can add new custom ones.
In the "customPreviewShaders.xml" file you can add custom custom vertex/fragment shader pairs, and also specify a set of technique names: OpenBRF will use that shader to preview any mesh which uses a shader using a technique named in that way.
(shaders are written in GLSL, and the example provided in OpenBRF distribution shows which attribute/uniform values you can use)
(you can use F5 from OpenBRF to immediately reload the shader file, after editing it)
it is possible to have a replace fonction.
for example, when you make a model, sometime there is some minor problem and you need to go in your 3D software to adjust it and then re-import it in Openbrf via the founction import a static mesh and then delete the previous one.
if you can make a function like that :
I can right click on the mesh I want to replace, I can have a browser where I can find the new one.
voila
for example, when you make a model, sometime there is some minor problem and you need to go in your 3D software to adjust it and then re-import it in Openbrf via the founction import a static mesh and then delete the previous one.
if you can make a function like that :
I can right click on the mesh I want to replace, I can have a browser where I can find the new one.
voila
It takes only a few two seconds to copy the name of the old one onto the new one and delete the old one?
press F2 (opens name screen) on old one > hit Control + C
hit Enter key.
Hit Delete key.
Import the new object.
press F2 (opens name screen) on new one > hit Control + V
hit Enter key.
Done, 10 seconds.. I don't see how this is a issue.
press F2 (opens name screen) on old one > hit Control + C
hit Enter key.
Hit Delete key.
Import the new object.
press F2 (opens name screen) on new one > hit Control + V
hit Enter key.
Done, 10 seconds.. I don't see how this is a issue.
orangeknite1
Sergeant Knight at Arms
Well look how semi-complicated that is, its not a huge issue but it does help. Most tools have a reimport mesh button.Vincenzo said:
It would probably be useful to have a re-import function, but really, this is a final-stage tool for assembly and certain basic testing of a finished piece of work, not something developed with back-and-forth workflow in mind.
For example, if you're having issues with edge hardness, export it to OBJ, load into Wings, tweak all of the edges there and preview for welding errors, etc. and then bring it back, and then you're done in one pass.
On the other hand, from what I could see of your model, you've built something that's way, way over spec, and you're about to find out why we use normalmaps for most little surface details. 7100 triangles is, well, not to spec; most full characters, including head meshes and equipment, are < 5000.
For example, if you're having issues with edge hardness, export it to OBJ, load into Wings, tweak all of the edges there and preview for welding errors, etc. and then bring it back, and then you're done in one pass.
On the other hand, from what I could see of your model, you've built something that's way, way over spec, and you're about to find out why we use normalmaps for most little surface details. 7100 triangles is, well, not to spec; most full characters, including head meshes and equipment, are < 5000.
