[Lory Da Costa]

I don't think that should be necessary - setShaderInt works just fine with bools ( just tested ).


I take that textures added through annotations get cleaned up properly ?


Well, that would just complicate thing IMHO, having multiple versions of the same shader floating around and such. The best course of action would be to pick a name and stick to it.

EDIT: I've almost completed the support plugin. As of now, it loads all known ( and existing ) shaders on game load. The options menu can be used to shader individual shader variables and turn on/off loaded shaders. Variable input is handled by a text input menu. Is there anything else that's required of the plugin ?

PS : Writing data over the PCIE bus seems to be slower than I imagined it would be.

I agree for the 'one shader, one name' rule - and it should be kept shortish and as obvious as possible. The only one that changes ATM is the Godrays, which IMHO should just be called Godrays.fx. All the others have pretty decent names.

Plugin features look good, all we need is the ability to change shader variables and toggle them from in game. We can then put together a giant readme on what variables do what, taken from the comments in the shaders themselves, so people can easily find out. Perhaps at a later date this could also be made into a series of Cobl Guide Books, but that's not really important for now.

I take it that other plugins could piggyback this one to change things too, and that it's a master for this purpose (kinda like how ScreenEffects worked, but not doing any fancy mixing of inputs)?

Yea I am. I actually stayed up all night a few nights ago trying to implement tessellation to add geometry to all these stoney walkways and walls. Just so happens a friend of mine pioneered related techniques working for nVidia a few years back. Problems are twofold: 1. The documentation for how that stuff is implemented at the moment doesn't exactly exist. People's engines are still proprietary tech, and he used the stuff for other purposes. 2. The shader has to be applied to every single pixel in exactly the same way, so I'm not even sure that type of shader works with OBGE. I think these shaders can only apply some value to a pixel after most of the stuff's been rendered, not interpret a scalar field to give you geometry then send the whole shebang back to be done over again.

Yep, OBGEv2 is only post-processing ATM.

SUGJESTION / ADVICE:
Maybe it is better to convert all previous released OBGE and OVEP Shaders and Mods to the new OBGEv2 standards. There are obviously lots of people that "can't read" the stuff about making the modifications them self's. They can only post these annoying complaints about stuff not working because they choose the easy way to do it.

No offence to the people that "can't read" but maybe we need to help them a bit more before more of those dudes show up.

That's been fixed already in OBGEv2's next version, the changes will no longer be needed.

[Robert Garcia]

I agree for the 'one shader, one name' rule - and it should be kept shortish and as obvious as possible. The only one that changes ATM is the Godrays, which IMHO should just be called Godrays.fx. All the others have pretty decent names.

timelygodrays has a pretty and decent name. <_<

PS. Just kidding, no problem. How you make the system work guys, I will obey.

[Amanda Furtado]

@ vtastek: So long as it stays how it is (or next will be) - which I thought could be a problem considering the version number is in the name - it'll be fine for shadeMe's stuff. :shrug:

[Syaza Ramali]

Plugin features look good, all we need is the ability to change shader variables and toggle them from in game. We can then put together a giant readme on what variables do what, taken from the comments in the shaders themselves, so people can easily find out. Perhaps at a later date this could also be made into a series of Cobl Guide Books, but that's not really important for now.

Not really necessary to do that as each variable has a description field that gets displayed during input. Like http://i659.photobucket.com/albums/uu320/shademe/shader%20stuff/Oblivion2010-02-2414-05-27-98.jpg. I've added info for all of the shaders bundled with the latest release.

I take it that other plugins could piggyback this one to change things too, and that it's a master for this purpose (kinda like how ScreenEffects worked, but not doing any fancy mixing of inputs)?

Nope. All this plugin does is let you modify variables of known shaders at runtime. It'd be easier to add a few OBGE commands to a plugin, instead of referring to ours. In any case, any plugin could use [the support plugin] as a master and access the shader index array.

[Suzie Dalziel]

The crashes seem to be unrelated actually, for some reason it sometimes runs and sometimes doesn't, and if it makes it past the Beth spashscreen it runs fine after that. But back to OBGE, for some reason I still can't get the SSAO to show up, even when godrays are working, and I've checked the names in my shaderlist.txt file dozens of times.

Looking back in the threads it looks like you asked this question before and your OBGEv2.log file showed that the SSAO shader wasn't compiling. Someone responded and asked if you had changed anything in the SSAO shader fx file.

Just to make sure we are on the same page can you post what it says in your OBGEv2.log file when the game runs OK.

@shadeMe - Yup the annotated textures are cleaned up automatically.

[Eoh]

I want to ask something about shaders. Having something like this.

sampler s0;

or

color = tex2D(s0,tex);

lead a great impact on performance. I just removed an unused sampler and users reported a performance increase. What I wanna know is having 3-4 post process shaders, like DoF, SSAO, godrays, all of them will use a depthframe sampler and at least one tex2D function, 6 total. Is this a performance concern? The compiler supposed to optimize things, right? Since there are 3 shader fx files, may compiler look at them as different shaders or let's say if it was treating them as one big fx file with different techniques, would that help the performance?

[katsomaya Sanchez]

What exactly is the RAWZfix.fx doing?

Thank you all very much for your hard work. It really makes the game much more atmospheric!

[Alexander Horton]

I want to ask something about shaders. Having something like this.

sampler s0;

or

color = tex2D(s0,tex);

lead a great impact on performance. I just removed an unused sampler and users reported a performance increase. What I wanna know is having 3-4 post process shaders, like DoF, SSAO, godrays, all of them will use a depthframe sampler and at least one tex2D function, 6 total. Is this a performance concern? The compiler supposed to optimize things, right? Since there are 3 shader fx files, may compiler look at them as different shaders or let's say if it was treating them as one big fx file with different techniques, would that help the performance?

Yes each effect file is treated separately from another effect file. The optimiser can't work across several files.

It's the color=tex2d(s0,tex) statement that's the slow(er) one as the shader has to do a texture look-up. However if you combined all the shaders into one big mega shader you will have to do all the depth related stuff in a single pass as a shader can't remember variables between passes.

Direct X 9 can do http://msdn.microsoft.com/en-us/library/ms890588.aspx, which is the only way to take lots of different shaders and combine them into one shader. However I'm pretty sure each fragment is compiled and optimised separately and then pasted together at run-time. Unfortunately fragment shaders would be way too complicated for a project like this i.e. way too complicated for me to program.

What exactly is the RAWZfix.fx doing?

Thank you all very much for your hard work. It really makes the game much more atmospheric!

The RAWZfix.fx is a bug fix for people with older nVidia graphics cards who's depth buffer's information is incorrect (The depth information is spread between the r g and b components, instead of just the r component). It's applied automatically by OBGEv2 if needed.

[ZzZz]

Am I the only one noticing strange effects between Ayleid wells and Godrays(v3.4)?

Screenshot to illustrate: http://img706.imageshack.us/img706/2287/ayleidwell.png

edit:
Finally decided to drop ssao_test, noticed a huge frame drop...indoor(outdoor was ok for some reason).
And ssao_perf has a strange effect on land, looks a bit like some light cell shading.

[hannaH]

If I may make a request: Is there any way you can change the search path that the game uses for each individual race's skeleton and body parts? It seems like if it were to be possible, custom races would be a cinch.

Edit: doh. got mixed up

[Kat Lehmann]

That sounds like it might be a better request for the OBSE thread.

[Niisha]

.....

Thanks for the info. My number of shaders are approaching 6-7 in MGE. That's a lot and affects performance. I am more interested in optimization now. Like in our post process shaders, can we benefit vertex shaders? What kind of calculations can be moved to vertex shader?

PS shader{float4 color = tex2D(s0, tex);float Decay = 0.99;float saat = f4Time[1];float dakika = f4Time[2];float Exposure = 0.001;if (saat > endevening - 1 && saat < 24 ){	Exposure = moonshaftex;}..............lots of stuff to calculate one variable..............	if (saat > startevening && saat < endevening ){	Exposure = eveningshaftex;}color = color * Exposure;}

can I move 'lots of stuff to calculate one variable' to vertex shader?

vertex shader{calculate exposure}pixel shader{color = color * Exposure;}

Would it be any help. Move anything not pixel related to vertex shader, am I on the right track?

PS. @DarklyDreaming(all I can dream after season 4)
I am aware of that, maybe it is my bright pass but I believe it is alpha particles written wrongly(whitely) to depth texture. I think it will be solved in a future release of OGE, not a big bug imo.

@I am updating godrays with new stuff, also decided to make a new godrays shaders with a totally different method, hope it will turn out better... But I have to use sun color variable in this new method.
Edit1: It turns out the missing variable was sunpos, not eyepos for godrays shader.
Edit2: For position, I know xyz, but what is w?

[josh evans]

Thanks for the info. My number of shaders are approaching 6-7 in MGE. That's a lot and affects performance. I am more interested in optimization now. Like in our post process shaders, can we benefit vertex shaders? What kind of calculations can be moved to vertex shader?

You wouldn't want to move any per pixel code, as vertex shaders only run on vertices. Besides, I don't think you can pass custom variables through the vertex shader output as the current FVF structure only defines the POSITION and TEXCOORD0 semantic. You should, however, be able do so by adding another TEXCOORD element (TEXCOORD1) to it and then pass your variable using that semantic, IIRC ( the variable needs to be defined in the plugin's code before it can be used in shaders )

EDIT: The w component of POSITION should be RHW(1/w). Its value is always 1 in screenspace.

[Jason Rice]

You wouldn't want to move any per pixel code, as vertex shaders only run on vertices. Besides, I don't think you can pass custom variables through the vertex shader output as the current FVF structure only defines the POSITION and TEXCOORD0 semantic. You should, however, be able do so by adding another TEXCOORD element (TEXCOORD1) to it and then pass your variable using that semantic, IIRC.

EDIT: The w component of POSITION should be RHW(1/w). Its value is always 1 in screenspace.

Thanks, but do you recommend to move non-pixel related calculations to vertex shader? Or is it not such a big deal?

W for screenspace, so can I use it to turn off the effect when sun is not on screen? But what does it take otherwise, just 0?

[elliot mudd]

I'd imagine that all non-pixel related calculations are better off in the vertex shader - it's going to have less of a performance hit, even if that hit isn't noticeable, so it's good practice, I would have thought.

Unfortunately, during my brief time trying to understand vertex shading, I saw no effect of vertex shaders. It didn't even seem like variables were being transferred to pixel after being set in vertex (using TEXCOORDn semantics). Perhaps vertex shaders don't do anything ATM because it's simply post-processing, or I was simply doing something wrong.

[Annika Marziniak]

Quick question, is it possible to extend the skybox to include places on the ground? So that it looks like you are seeing further than you actually are?

[Len swann]

What do you mean? The skybox shows sky, why would you want to see sky on the ground?

Or do you mean add terrain to the horizon band of the skybox?

[Alisia Lisha]

What do you mean? The skybox shows sky, why would you want to see sky on the ground?

Or do you mean add terrain to the horizon band of the skybox?

Yes, I mean add terrain to the skybox. You could make it look like you had a view distance of hundreds of miles.

[Blaine]

The skybox isn't a box like in some other games I'm more familiar with the workings of, but more like a hemisphere that the sky textures are streched across. The textures get moved across it, to simulate wind moving the clouds, and they wrap around again. Putting textures there would mean that you'd get mountains sideways in the sky, and stuff like that.

It's basically a dynamic skybox, as opposed to something fixed. And Cyrodiil is supposed to be pretty big, it just isn't. I'd recommend using something like Streamline's Streamsight to make the world feel bigger. I'm sure that others will have some suggestions regarding this.

Also, IMHO such skyboxes look pretty bad. They're OK for FPSes, where you're not looking at the distant scenery, but I don't think the effect would translate very well into Oblivion.

[Taylor Thompson]

Yes, I mean add terrain to the skybox. You could make it look like you had a view distance of hundreds of miles.

You can't see hundreds of miles on earth.

From wiki:

For an observer standing on the ground with h = 1.70 metres (5 ft 7 in) (average eye-level height), the horizon is at a distance of 4.7 kilometres (2.9 mi).
For an observer standing on a hill or tower of 100 metres (330 ft) in height, the horizon is at a distance of 36 kilometres (22 mi).
For an observer standing at the top of the Burj Khalifa (828 metres (2,720 ft) in height), the horizon is at a distance of 103.75 kilometres (64.47 mi).

I don't know if Nirn is a bigger planet. (But I assume it is smaller.) In any case Oblivion has a pretty good distance view.

As for skybox, it is part of the game, and I am sure it is moddable. There must be an equivalent of this mod in Oblivion.
http://www.gamesas.com/bgsforums/index.php?showtopic=1071075&st=0&p=15568445&hl=skybox&#entry15568445

I prefer Open Worlds though.(As stated in my sig)

@wrinklyninja
Try to alter worldpos values, does it work? In MGE all I can edit is MGE stuff: water and grass. I wish I could edit any object separately. Then normal maps here I come... (I plan to hack grass codes to render my own stuff, let's see if I can add bump maps, hehe.)

[NAtIVe GOddess]

@ Vtastek: Yeah, Nirn is a lot smaller than earth. Nice wiki find. I don't know about altering worldpos values, I've never tried it, and don't really have the time to try it out ATM.

[Skivs]

@ Vtastek: Yeah, Nirn is a lot smaller than earth. Nice wiki find. I don't know about altering worldpos values, I've never tried it, and don't really have the time to try it out ATM.

I can try something now. Here what I found about something called preshaders.

http://www.riemers.net/eng/Tutorials/XNA/Csharp/Series3/Preshaders.php

I'm not sure if it is available to us, or maybe moving to CPU can cause an even bigger performance hit...

[Anne marie]

Interesting. Oblivion is generally CPU limited, but it would certainly help when using a lot of heavy graphics/OGE stuff to have the calcs done only once.

[Lisha Boo]

Unfortunately, during my brief time trying to understand vertex shading, I saw no effect of vertex shaders. It didn't even seem like variables were being transferred to pixel after being set in vertex (using TEXCOORDn semantics). Perhaps vertex shaders don't do anything ATM because it's simply post-processing, or I was simply doing something wrong.

I've clarified my previous post a bit.

I can try something now. Here what I found about something called preshaders.

http://www.riemers.net/eng/Tutorials/XNA/Csharp/Series3/Preshaders.php

I'm not sure if it is available to us, or maybe moving to CPU can cause an even bigger performance hit...

From what I can tell, the plugin's compile call doesn't disable them explicitly. There is a good chance that it's already being used with the existing shaders.

EDIT: I've uploaded the support plugin to the Nexus page. Shaders can be turned off by clicking on their buttons with the control key held down. Turning them on requires the shift key to be held down instead. I haven't updated the file description with the details though.

[Victoria Vasileva]

I have a question: will Screen Effects work with the OBGEv2.dll?
Should I delete obge.dll or can those two plugins work together?

brucevayne