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).