Thank you, just wanted to see what you were doing different from mine. Actually we are doing the same thing it seems.
I guess it's those edited photos that trick us. But hey, sure makes for some amazing drool worthy eye candy!

Yes, everybody loves eyecandy.
I actually think that when I play the game, it looks much better than the edit picture. :twirl:
Cannot capture the nice particle effect and the rays that dances between the leaves, in a picture

Isn't there already a Fake HDR/Bloom mod? http://tesnexus.com/downloads/file.php?id=2773

Mine is nothing like that mod. Its more of a bloom shader than HDR but you can use it in replace of oblivions default HDR using OGE. And there is always room for more especially for OGE shaders

@Strupekutter

If you want pics to look like that edited one, you can try my settings for the GTA San Andreas v0.075 ENB series. Just PM if your interested.

I know this is a known issue, but is there any way to lessen the effects of the moving black lines and white-filled texture? http://i.imagehost.org/view/0690/ScreenShot7

I've never seen that issue before. :mellow:

And thanks for quoting my fix.

Would be best to add snow ep's fix to the OP as an answer to a question about blue light rays during the day time.

Done, thanks again Snow_EP for the fix :icecream:

When using the new 'obgev2' from Scanti - do I also need to have loaded the depthtest.dll?

I ask because it automatically loaded the SSAO shader but typing in Loadshader command resulted in no other shader.

So is the SSAO shader on by default?

And when typing in the new commands can someone post here the very exact wording necessary for these?

thanks a lot for this continued work.

OBGEv2 has 2 methods of loading in it's shaders. First it will look for a ShaderList.txt file in your Data\Shaders directory. This file contains a list of shaders to load in whenever the player starts a new game or loads a game. (A quick tip for those people writing their own shaders. It will parse and reload in any shaders in the ShaderList file each time you start/load a game. So you can run the game in window mode, try out a shader, edit the shader fx file and then start/load a new game and it will use your new shader file).

The shaders loaded by the ShaderList file are passive shaders. You can't alter them using any scripting commands.

The other method of loading in a shader is to use the LoadShader script command. This will load in a shader and activate it, returning an index number of the shader. You can then use this index number to alter any constants within the shader e.g. change a texture or set floats. When I release the finished version any loaded shaders using the LoadShader command will be remembered when you save/load a game.

You shouldn't have the DepthTest.dll loaded as it will cause the shaders in the ShaderList.txt file to be loaded twice.

What model of graphics card are you using?

Nvidia Geforce 9800GT

Okay. I first thought it might have been that older depth buffer issue mentioned before, but that doesn't appear to be the case.

Anyways, you seem to have the SSAO fadeout distance pushed out as far as possible, towards infinity. Try reducing it so the shader only works on the closer parts of the image. The banding could be the result of the non-linear scaling of the depth buffer. The farther you get from the camera, the less detail the depth buffer has, and the larger the "gaps" between values. Those gaps will make it appear to a shader as though a fairly regular surface (like terrain or water) has weird step discontinuities (like a staircase) that get worse the farther from the camera they are. The shader will blindly shade those discontinuities using it's algorithm, which should look like dark bands silhouetting the surface of the object, just as in your picture.

If you want to try and get the most SSAO in a scene as possible, fine tune the fadeout distance so it shows the effect just before the banding begins. Otherwise, just re-download the shader with the default values.

Anybody got lucky using f4Time variable?

I am trying to limit the shader around sunsets and sunrises, but compilation errors I am getting is not helping.

The shader fragment fails completely.

What would be a decent way to pass the f4Time.y into the shader?

I started with this

float tzone = fmod(f4Time.y, 12);

but using tzone in any calculation causes the above error. Maybe I got this from the wrong end, I feel rusty.

Rusty or not vtastek, I`m glad to hear that your still working on it ^_^

I've used it before when I was experimenting with introducing frame-by-frame randomization in the jitter algorithm. Did you declare f4Time in the global scope before using it?

I've used f4Time before, I just declared it as:

float4 f4Time;

and referenced it as f4Time[n], 0
Eg. return thisframesample - saturate(sin(f4Time[0] / 59));

Thanks guys, having some progress. Using it directly didn't cause anything(errors). I am suspecting 'fmod' now.

So how's the 'shadows on statics' part coming along? Progress? Do we know where/what shader is used for stencil shadows in vanilla?

I don't think anyone is even working on that yet.

Here is an idea I was thinking of, concerning the performance of my SSAO shader. I was playing Borderlands, and noticed that their ambient occlusion appears to fade in very quickly whenever something changes in the scene (such as when you open a locker to loot it). I'm not sure if they use textures for their ambient occlusion and the fading in is just it loading those textures, or if it is generated in real time, but that made me think about spreading the processing of my shader across several frames. Take 4 SSAO samples per pixel per frame and have them accumulate over several frames, rather than take 32 samples per pixel every single frame.

Attempting something like that would require me to be able to render the SSAO to a separate frame buffer, though, and it might introduce some ghost darkening at lower frame rates (something I could control easy enough with a script tweaking shader variables), but hopefully that would be a good trade-off for the potential gains in performance and sampling quality.

Anyways, I guess my question is, what are the chances we can create our own frame buffers for more advanced, time dependent, effects?

What is "ghost darkening" HawkleyFox ?

Edit:
And what do you mean with sampling quality ?

I believe AO is generated procedurally in Borderlands.

If the frame rate is low, and you turn the camera quickly, it would take a little longer than usual for the AO accumulated from the previous stable scene to fade away. You would see a noticeable outline of the previous scene, which would fade away in a fraction of a second. I could probably adjust the atrophy rate (how quickly AO fades away) either when frame rates drop too low, or when the player starts whipping the camera around like that. Would make the problem less noticeable. But no need to worry about this stuff for now, seeing as its currently not possible to implement.


The ambient occlusion algorithm I used in this shader takes several samples from various parts of the image, centered roughly around the pixel it is shading. Each of these samples adds more information and detail to the final result. The fewer samples taken, the lower the detail of the SSAO. Right now, the most favored way to gain performance with this shader is to reduce the number of samples taken per pixel (the ssao_sample_size variable). When it is set to 4, it takes 32 AO samples, but most people set it to 2, making it take only 16, and greatly decreasing the amount of time it takes for the shader to shade the scene.

What I suggest is instead spread the detail across several frames instead. Make it take 8 samples per pixel and having the detail accumulate over 4 to 8 frames. This way you could have 32 sample quality with 8 sample performance.

Thanks for the explanation :grad: :clap: