As I mentioned yesterday, here are the two replacements for Bokeh_DoF.fx:
http://www.4shared.com/file/DcwGKDos/Bokeh_Circle_DoF.html
http://www.4shared.com/file/iyVU6dI3/Bokeh_Hexagon_DoF.html

Which have proper http://s1100.photobucket.com/albums/g405/tomerk001/Hexagonal%20Bokeh%20DoF/?action=view¤t=ScreenShot307.png and http://s1100.photobucket.com/albums/g405/tomerk001/Hexagonal%20Bokeh%20DoF/?action=view¤t=ScreenShot304.png respectively.
Hexagons have edge weighting on by default while circles have it off bye default.

Great work once again.

Any estimates on an update to the support plugin to incorporate the new shaders. I would like to have SSII in there so I can turn it on and off to see the difference.

It already is*. It seems you have not downloaded the most recent version of core and shaders from the OP. That would be thing to do.


* SSII, that is. The newer ones will take a bit of time, because - if I understand correctly - it's all down to one *busy* person.

Did i read correctly that 4xx cards have a bug with Godrays? Because i can't even enable the svcker (the console tells me that it is enabled but the shader enabling thingamajig still has a minus by it, and no visual effect present).

Just been testing out the shaders recently and have overall been very pleased. Only small bugs I've noticed and I believe each are related to the SSAO probably. First being one fairely mentioned with underwater effect, seems like there use to be a problem with underwater textures not showing, using the volumetric one I have textures underwater but the effect is really strong and still comes out strange looking. Is it possible for the effect to be disabled underwater? For some reason I'm doubting it but thought to ask. Other issue is some objects mostly what appears to be overlayed objects the game uses for dirt or ribble or even marking out where traps are gets a fine dark line around it. Likely the AO trying to shader under the object, what this does though is reveal the outline of what is suppose to be an alpha blended object. Not sure if anything could be done about either, first problem is mostly an exterior problem, the second interior, the effect is worth it despite the bugs though but never hurts to find some polish if it's possible.

So it crashes when you've got OBGEv2 installed, but the support plugin inactive? Do you have the shaderlist enabled, and are you using it? (Check your OBGE.ini in My Games\Oblivion) Try setting bLoadData and bSaveData in your OBGE.ini to 0.


The first is an example of the fog bug, the second is an alpha issue, yes. I think both can be solved by rendering the shaders earlier in the process, and IIRC that's going to be done for the next OBGEv2 plugin update.

@ tomerk: Thanks for those shaders, I'll get the support plugin updated ASAP.

Double post, but I've updated the Nexus page with v4.2 of the Shaders package, changelog is:

First download

But the Godrays shader still dead :brokencomputer:

Thanks for the prompt update, wrinklyninja. And for the new Bokeh shaders, tomerk. Great stuff.

Not usually firing off requests one after the other, but well, would there be any chance of bringing back Quick Blur, or anything like it?

Again, I will completely understand if it's not a priority, or if there's simply no interest at all (except from me). Just thought it might be worth the asking, is all.

If you're talking about the example/test shader Scanti provided, that's still available in the Extras folder of the Core package, though of course the support plugin doesn't cover it.

My next 'big' update to the support plugin I thought to make is to have it listing shaders by their name as printed in the readme as opposed to their filename, which is what is currently given. What do people think of that, is it a good idea or a bad one?

@ atikabubu: The Godrays shader is the same one as vtastek posted in the last thread (or possibly the one before that), which I thought all the known users of 4xx/5xx series cards had verified worked...

Well dunno, it doesn't even have a checkmark that it's enabled... It just doesn't... :cryvaultboy:

http://www.speedyshare.com/files/26255554/obge_log.7z - OBGE and OBSE logz

I'm running Win 7 x64 with a GTX 460 (the one with ripped cores)

Oh, sorry, I should've said - yeah, I meant for the support plugin. Though... a better way of including it, that just occurred to me, would be to add it into ColorEffects. Hrm, though it isn't a "color" effect, I guess. :shrug: But it would be closer then, to ScreenEffects, and so one less reason for some to still be using that. Just a thought. Even if the reason most might be, is likely to something else altogether.



That sounds sensible and reasonable to me. So um, that's one vote?

Agreed, will make it much easier. also will you be adding in the other shaders like Viginette and SSII?

I'll pretend that second sentence doesn't exist.

@ atikabubu: Thanks for those, I'll take a look.

@ Breton Paladin: Well, for now you can load it via the support plugin by renaming it to testshader1.fx. It's just a fullscreen blur though, I must be missing something as to why you'd want to use it...

Oh, that's right, you can too. I'd forgotten, even though I read a post explaining that only a day ago or so. :blush: Sorry! I guess I was hoping for the plugin's support, re: variables. Er, maybe variable, singular. Can't recall what's in quickblur, off the top of my head.

And as for using it - strictly screenshots, I assure you! By no means do I want to go wandering around Tamriel (etc.) like someone suffering from massive head trauma. Even though a lot of characters would be. But, er, never mind that.

And yeah, that's why the plugin support would've been handy: the occasional screenshot. But to be quite honest, it's one of those corner case things, even for me, when taking screenshots. Let alone anyone else, I suspect... :shrug:

"For the sake of completeness" might be about the most compelling case that could be made for it. Weaksauce, really.

Really great job on the new Bokeh shaders, tomerk. I thought the "correct" hexagons seemed a little too sharp, but in-game I could rarely make out individual hexagons anyway... I don't think I found areas with sharp enough highlights. It's probably really only that pronounced when the stars are in the background. For conversations in particular, the Bokeh is simply gorgeous.

A point I want to bring up though, about all Depth of Field shaders, really, is how maybe they could be made more... useful?

I'm curious if two things are possible (and these are by no means requests of this team, but I'm hoping you might have the answer nonetheless):


1) Toggling DoF shader on/off during specific events, e.g. going into third-person, or entering a conversation with an NPC, or drawing a bow.
2) To add to this, utilizing different DoF based on the specific event, e.g. hyper-blurry Bokeh DoF for conversations, subtle distance blur for third-person, auto-focus for when drawing a bow.


As it stands, I feel like nobody must use these DoF shaders, in-game, 100% of the time. They seem to me like they're meant for screenshots. I'm sure some like the effect 24/7, but it's not realistic in first person because that view is obviously meant to simulate two functioning eyes where DoF is not apparent, and it usually just obscures the pretty views or actually impedes gameplay. It's realistic in third-person, because there clearly has to be some kind of camera chasing you (unless it's an animal or has two lenses). And it's usually done for effect when using an aimed weapon, say you close one eye (which you really don't in archery) or to simulate a scope, etc. And for conversations, I think it would really enhance the cinematic quality (even though you're technically in first-person) and looks amazing. In fact, the new Bokeh shaders aren't even usable for much else other than the stand-still dialogue scenes and screenshots, in my experience. It simply runs too slowly on my machine, though I'm sure it runs well enough for some.

So, I thought it was a really good idea, and wanted to share, and see what anybody thinks. I've delved into modding before, but I don't know if the kinds of things this would need can even be scripted.

Sorry, didn't realize that you did update the support plugin. just saw that.

If you can detect events via scripting (OBSE or otherwise), then you can make shaders jump through all the hoops you want when those events occur. Unfortunately, a particular problem with DoF is that there is no time-based blur shifting, everything happens instantaneously, but you can still mimic a gradual application by increasing the strength of the blur gradually from 0 to whatever final value you want.

Specifically, going into third person is detectable (IsThirdPerson). Conversation might be detectable using GetCurrentAIPackage, and you could probably check for drawing a bow by checking if the player has a bow equipped and then checking for left-mouse-button press.

Thanks. I'm quite rusty with this, just reinstalling Oblivion AGAIN after so many attempts to get back into it... I came to some of the same conclusions after some thought. Specifically the bow equipped/LMB pressed.

I know of the limitations with the DoF implementation. I really didn't think it would be a problem. Most of the transitions are already jarring, one moment you're in first person and then you're not, one moment you're not talking to someone then you are, one moment you're holding the bow, the next it's being aimed (that one does have some bit of animation though).

For dialog, I thought most simply you could use

Begin onMenuMode 1009

... the code for Dialog? And then in GameMode if a token has been set like "hasDialogDoF" we know we've just exited the Dialog and should turn off the Bokeh DoF. Is my understanding of this correct? It has been a while since I've toyed around with all this... heh. At least I've been a programmer for a long time, so it's a matter of adapting what I know to a game loop...

I will still check out GetCurrentAIPackage... I should get familiar with all the functions sometime anyway.

Edit: Oh, and I assume that whatever code needs to manipulate shaders on/off is going to be identical to your Ctrl- and Shift-click code in the Support Plugin? I guess I'll be looking into it soon enough, but are the shaders given some kind of unique ID? (And do they stay the same between plugin updates?)

Yep, that dialog detection would also work, I'd forgotten it was a different MenuMode, and you're correct that the required shader-related code will be as in the support plugin (though that deals with everything in arrays so appears more complex than you'd need), including any variable alteration you might want to do.

Ninja'd (hah!) before I got an edit out in my previous post...

I added at the end a question about if the way each shader is addressed (whatever way they are identified) changes each time you update the plugin. Or do you just give new IDs to new shaders? More or less was wondering if I rely on your plugin as a dependency (which I assume I'd have to to ease the toggling on/off) if I would have to make my own changes with each Support Plugin release.

I guess I might be making too many assumptions about how it works, so the question might not make any sense.

While I am not quite sure how to go about any of the other scenarios, I can think of a simple way to make the bokeh transition well when entering conversations:
Not in a conversation: bokeh disabled
Enters conversation: enable bokeh with a base_blur_radius of 0

Then, as quickly as you want bokeh to start, increase base_blur_radius to 2 by the same amount each frame

In conversation: Do not alter bokeh settings

Exiting conversation: Do the opposite of what you did when entering conversations,
decrease base_blur_radius to 0 then disable the shader.

See the latter half of the Core package readme - it goes into the details of all the OBGEv2 commands, but basically I wouldn't make your plugin be dependent on the support plugin - if one plugin loads a shader and another then tries to load it, the load function will just return the ID of the shader instance already loaded (unless otherwise specified by a flag), preventing duplication while allowing both mods to do stuff with the shader. So just load the DoF shader of your choice in your plugin and work independently of the support plugin.

I think I know how to implement everything, writing pseudo-code now... I will try this after I get the simple toggle down. Thanks!



Well, this is all turning out a lot easier than I first thought!