It was mentioned previously that your hooks allow in-game editing of the shaders. I didn't really think about this too much until I read this.
It's for development only, it's not necessary to do that once a shader is done with. Though of course anybody can come up with some magnificant use of it as a feature to do some incredible stuff.
I assume this kind of thing would need to be tied into use of, say JRoush's Magic Extender, or just use scripted spells to enable per-spell customisation of such shaders?
Well I think it'd be sub-optimal to do that on function-level. You're not changing the Oblivion-exe either to allow a variety of trees. You deal with that on data-level, your shader-function should better be constant, but you can make it adapt to varying inputs; like yellow, red and violet bolts for example, or bolts which branch 6 times or 10.
Dumb question, but there's a slight delay at present as the OBGEv2 HLSL shaders compile post game-load. What kind of delay are you seeing with so many HLSL shaders? I presume the mechanism is much the same (post game-load compilation).
The feature is two-fold, you can replace any shader, those files can be deployed as binaries, or source which is automatically compiled and saved as binary. So this won't require any time after the first source->bin. The binaries are fed to Oblivion as if they come directly out of the shaderpack. The runtime-feature is only there so you can run the game and develop instead restarting the entire game for just 1 code-change. Technically the shaders are loaded before the splash-video, I don't know if that counts as pre- or post-.
Oh, and apologies for this slightly negative question. :whistling: Agreed, it's not really necessary. I'm quite willing to accept your word for it that it's all working right, I was trying to point out all the shaders I could think of in that shot that demonstrated the "success" that people didn't seem to be noticing, and then mentioned a few more shaders that I suspected would get unnoticed even if they were included in the shot.
No offense taken, I perfectly understood the intention of your post. Though I have three monitors, I just got one brain and keyboards. As such I have to be a bit resource-conservative and currently don't have my fingers in all of the pies. I try to focus on handle things such that it has the highest chance of success.
The number of used shaders per scene is surprisingly low, let's say 30 or so. That's not much against 650 in all. I did not test all what is possible, didn't degrade the shader-model to use and so on. Partly because of time, partly because I believe we need tomerk's water-replacement to trigger a cascade of on-going shader-development. Remaining shader-glitches will be fixed then for sure, and much more efficiently.
Still greatly impressed. When the depth buffer was exposed for OBGE2, that was very good, this now is fantastic.
Well ... the depth-buffer ... it's causing me nightmares. I probably will end up redoing it because I need to expose the depth-buffers of all passes, not only the main-surface's one.