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

Users who are viewing this thread

Yoshiboy said:
If you need a hand converting any of the Shaders to GLSL then I might be able to lend it, though you seem fairly qualified yourself and wouldn't want you to get off your roll!

They're some automatic tools to do that HLSL -> GLSL fx conversion:

http://graphics.stanford.edu/~danielrh/babelshader.html Old, maybe deprecated.

http://sourceforge.net/projects/hlsl2glsl/

Try this, it's supported by AMD. Maybe the output couldn't reach human quality, but seems pretty good for simple non-intensive previews.

For the Warband shaders, you may need to decompile it, or ask a source copy to the devs. :???:
I suppose that a reimplementation of displacement maps shouldn't be a problem for you.  :smile:
 
Yeah I've tried some of those tools before, kinda useless I found. Either way I meant really writing a new shader to emulate the HLSL ones the devs use.
 
Thanks guys. I'm quite fluent in GLSL myself!

Yoshi: that's what I did in current rel: I emulate in openbrf, with a GLSL shaders, what game does in with the "iron_shader" in hlsl. To do that, naturally I peeped into game shaders.

I could (and eventually will) do the same for other game shaders, including normal maps etc.

---------------------------------------------------------------------------
warning: boring useless tech details in the rest of the post:
---------------------------------------------------------------------------

My concern, with current iron shader imitation or any other, is: how can OpenBrf know what shader to use for a given mesh.

Sure, it knows that that mesh uses material X which uses shader Y which uses "technique" Z.  But then, how does it know what Z does without reading the mb.fx file. One has to accept some compromise here.
  • Before, my policy was to look at the flags of material and make openbrf guess from there. Not very accurate: I already received bug reports about "that shield looks all shiny in OpenBRF while in game it is not"; it happened when my iron shader emu wrongly kicked in over objects where alpha texture was uniform 1 (which means max shininess everywhere in the iron shader).
  • Or, hardcode in openbrf shader (or technique) names?... but that's not very general. For example, in our TLD module we make our own shaders and OpenBRF wouldn't know about them. I could make the list customizable, but probably it is just not worth it.
  • Beside, even if I did replicate exactly what each game shader did, I would still have to guess the parameters used in game like amount of sun light etc.

As a compromise, in next version (which I'm about to release) OpenBRF does this:
- whenever the used "shader" has "iron" anywhere in its name, iron shader emulator kicks in
- whenever any alpha test flags are set, I use alpha transparency instead.

I'll use similar rules-of-thumb when I'll add new game-shader emulations (eventually).
 
Well, you could always add checkboxes, and emulate the in-game light.  So like "Indoor Lighting"  "Outdoor Lighting"

Though that still wouldn't solve the shader problem.  Maybe just don't support custom shaders?

In Warband they aren't customizable anyway, as far as I know.  Though TLD is using 1.011...

So support Warband and TLD shaders?
 
Bolkonsky said:
Well, you could always add checkboxes,

Sure I could, but I don't want to burden(**) the interface too much. So, instead, I decided to:
- by default, emulate decently a few popular shaders(*), activating them with some reasonable (but not bulletproof) criteria
- let users deactivate that, under "settings" -> "on mesh rendering"
  (there are two options: "infer settings from Material" or "always use default settings")

That's a good compromise, as it does the more-or-less right thing most times, by default, but you can deactivate if it doesn't work in your case.

(*) by "few popular shaders" I mean the most commonly used M&B and WB shaders...
currently, the iron shader in M&B/WB, and the ones doing alpha cutouts. In the future, at some point, normalmap shaders and the ones using env mapping and shininess maps.

(**) e.g. you would need to let user choose: use alpha cutouts, use normal maps, use alpha channel as shininess map, etc.

 
New version! from 1st page:

ver 0.0.49 (28 Sept 2010): 
- added command to turn mesh (or mesh groups) in collision objects
- fixed a few bugs relative to the last updates

First point is after a suggestion by [WilliamBerne] (thanks!)

BEWARE of abusing that thing!

Good collision objects uses far fewer polygons than typical good meshes used for rendering.
The cool coll. objects you'll create with that option will use only a little fewer (because of auto-quadification), but still too many, on average, than what would be good for efficiency purposes!

Also, meshes can have any kind of inconsistencies while collision objects must be two-manyfold well oriented etc.

------
The bugs were: I accidental disabled the "alpha cutouts" rendering. Missing translations of OK/cancel buttons and a few messages. Occasional crashes when the content of BRF was changed and colors-coding-by-usages was activated.
Thanks foxyman swyter triglav and others for reporting them!

 
Bolkonsky said:
In Warband [shaders] aren't customizable anyway, as far as I know.  Though TLD is using 1.011...

I've heard that, but why is that so? It seems WB has shaders in brf, and fxo files.
All it takes is that Armagan makes fx files available for us to build customized fxo files. Was he asked?
 
mtarini said:
BEWARE of abusing that thing!

Good collision objects uses far fewer polygons than typical good meshes used for rendering.
Thank you mtarini! This will save me even more time.
I am fully awared of what a good collision body should look like. In fact I keep on making optimized collision bodies all the time.
 
mtarini said:
Bolkonsky said:
In Warband [shaders] aren't customizable anyway, as far as I know.  Though TLD is using 1.011...

I've heard that, but why is that so? It seems WB has shaders in brf, and fxo files.
All it takes is that Armagan makes fx files available for us to build customized fxo files. Was he asked?

Actually it probably is a good idea asking him.

I figured he was protecting his source by only including the compiled versions. Though it would probably also be nice if he could  include non-compiled versions as reference.

Not to be mean but it isn't like he shaders are doing anything revolutionary that needs to be protected!
 
Yoshiboy said:
Not to be mean but it isn't like he shaders are doing anything revolutionary that needs to be protected!
Most likely WB shaders now include some proprietary 3rd party ones (e.g. from Paradox library or such). Which necessitates protection for the whole bunch

Would be cool still if WB would have some outlet to load custom shaders from. Like a separate fx+fxo pair in a module folder
 
How about a better exporter/importer? I'm especially thinking about 3DS files and maybe also .mat files for the materials.
 
Darwin said:
Dain Ironfoot said:
...modeling format...

That's the point. :wink:
With 3DS you could import material, texture and mesh at the same time.

Yes but BRFs don't use materials that have any resemblance to 3ds materials  :roll: It would be a lot of work for very little reward, when you can import a texture and material pretty quickly anyway.
 
Back
Top Bottom