[Alan Cutler]

From what I can tell, shaders don't stack unless the loadShader call is made with the allowDuplicates flag. When called without it, the plugin adds the shader into its internal data structure. On every applyFullScreenShader call, it checks if the shader being loaded already is. If it is, and the duplicates flag isn't set, it simply returns the integral ID of the already-loaded shader. The serialization routines should take care of delinquent shaders on their parent's removal, but the textures loaded using setShaderTexture can't be. So essentially, you'll need to call freeTexture on all script-initialized textures ( or call purgeManagedTextures once instead, if the command only validates the calling mod's resources - I'll take a look to confirm ) before uninstalling. To remove a loaded shader ( during uninstallation, presumably ), call the removeFullScreenShader command with the permanentlyDelete flag set.

Some news on the support plugin - I managed to find the one I wrote earlier but had to scrap it as I hadn't considered shaders with more than 10 tweakable variables. I've mostly rewritten the menu system with a fancy-sounding dynamic button system that'll add and remove buttons, as needed. Have a couple of bugs to quell before it can be released. Updating the plugin with new variable/shader info is a relatively easy task that doesn't involve anything more than constructing an array structure.

Right, so stacking is no longer a problem, that's good. And regarding the removal of shaders effects when the plugin loading them is removed, that's handled by OBGEv2, and I don't need to make any removeFullScreenShader calls, am I right?

Or do I have to include an uninstall script that will remove the shader so that it's safe to remove the mod? It would be easier, and safer in general (IMHO), if OBGEv2 automatically removed shaders when the plugin loading them is not loaded, and remove the data from the savegame, rather than the plugin having to unload the effect itself. Simply because previous OBGE mods didn't do this, so they'd experience problems if you do indeed have to.

Good news on the plugin, BTW.

The code looks like my code from Realistic Health that I posted around, minus my comments which would explain it better.

Yeah, I think it might be a mix between ScreenEffects and RH code. I understand it though, I wasn't sure if it was nescessary is all. shadeMe's answered most of my questions though. For the record, I'm not interested in backwards compatibility with the original OBGE, so missing parameters, etc. isn't a problem.

[Undisclosed Desires]

Right, so stacking is no longer a problem, that's good. And regarding the removal of shaders effects when the plugin loading them is removed, that's handled by OBGEv2, and I don't need to make any removeFullScreenShader calls, am I right?

Or do I have to include an uninstall script that will remove the shader so that it's safe to remove the mod? It would be easier, and safer in general (IMHO), if OBGEv2 automatically removed shaders when the plugin loading them is not loaded, and remove the data from the savegame, rather than the plugin having to unload the effect itself. Simply because previous OBGE mods didn't do this, so they'd experience problems if you do indeed have to.

Good news on the plugin, BTW.

Yes, but it won't hurt to remove the shaders yourself. Removing an non-existent shader won't be an issue as the plugin should handle it internally.

EDIT: By the way, I suggest that we keep to a single, static file name for for each shader to keep from updating the support plugin constantly.

[Sarah Unwin]

OK, I did some quick testing and:

1. Loaded a game without the plugin, no shader loaded. Screenshoted.
2. Loaded a game with the plugin, shader loaded. Screenshoted and saved.
3. Loaded the saved game without the plugin, shader not loaded. Screenshoted and saved.
4. Loaded previously saved game. Screenshoted.

Screenshots 1, 3 and 4 are identical, with only 2 showing the effect. This is with no removefullscreenshader calls, just letting OBGEv2 handle everything internally, so it looks like everything will be fine regarding previous OBGE mods working with OBGEv2. In all cases, the shader file was present, even when the plugin was not active.

The OBGEv2 log for 1:

Ingnoring message.RESZ format supported.Depth buffer texture (INTZ) (1366,768) created OK.Depth buffer attached OK. 0Releasing the original depth surface.Received load game message.Loading a game.Creating vertex buffers.Creating screen texture.Width = 1366, Height = 768Setting screen surface.Setting depth texture.Loading the shaders.Loading shader (data\shaders\)Failed to load.Added to list OK.Loading the shaders.Loading shader (data\shaders\)Failed to load.No texture data found in save file.No shader data in save file.

The OBGEv2 log for 3 was:

Ingnoring message.RESZ format supported.Depth buffer texture (INTZ) (1366,768) created OK.Depth buffer attached OK. 0Releasing the original depth surface.Received load game message.Loading a game.Creating vertex buffers.Creating screen texture.Width = 1366, Height = 768Setting screen surface.Setting depth texture.Loading the shaders.Loading shader (data\shaders\)Failed to load.Added to list OK.Loading the shaders.Loading shader (data\shaders\)Failed to load.Save file links 0 textures.Shader Index = 1Shader num = 0Filename = AmbientDungeons.fxEnabled = 1RefID = 9000ED3Is in use = 0Received save game message.Ingnoring message.Saving a game.Calling TextureManager::SaveGameShaderManager::SaveGameShader index = 1

and then when I loaded 4:

Ingnoring message.RESZ format supported.Depth buffer texture (INTZ) (1366,768) created OK.Depth buffer attached OK. 0Releasing the original depth surface.Received load game message.Loading a game.Creating vertex buffers.Creating screen texture.Width = 1366, Height = 768Setting screen surface.Setting depth texture.Loading the shaders.Loading shader (data\shaders\)Failed to load.Added to list OK.Loading the shaders.Loading shader (data\shaders\)Failed to load.Save file links 0 textures.Shader Index = 1

I'm not entirely sure, but it looks like that when you save the game with plugin, the shader is saved in it. Then, when you load that save, OBGEv2 references the shader, but doesn't apply it because the plugin no longer exists. If that is then saved, a 'clean save' takes place, and the shader is no longer referenced at all, but there is still a shader indexed in the save (compare with OBGEv2 log). So it looks like there is a need for a RemoveFullScreenshader call, otherwise this index will remain.

EDIT: I agree with the one name per shader file, over all versions. It could get confusing otherwise, and you can always record versions inside the shader itself.

[Daniel Brown]

@ Scanti: Would it be relatively easy for you to add a SetShaderBool, or should I just convert by bools to floats? I understand bools take less memory, but is it something that is worth a new command?

I can do that no problem. I'll need to get some op-codes from the OBSE team.

scanti, why exactly can't you release allocated textures using the serialization API ? Are they implemented independently of their parent shaders ? Just curious.

Textures can used by the shader system and the HUD system. I can probably get the serialization system to release textures associated with an unloaded plug-in if I'm careful. I'll try to wrap my head around the problem.

To correctly write something that works with both OBGE v0.1 (shaders not in savegames) and OBGEv2 (shaders in savegames), you would need to add blocks that unload the shader in the savegame menu and when the quicksave key is pressed. Basically, you need to explicitly avoid having shaders saved in the savegame....

Unfortunately I wrote OBGEv2 to work with an OBGE mod but not an OBGEv2 mod to work with OBGE. That's one of the reasons I gave the OBGEv2 plug-in a different name so a mod can easily distinguish between them.

Yes, but it won't hurt to remove the shaders yourself. Removing an non-existent shader won't be an issue as the plugin should handle it internally.

EDIT: By the way, I suggest that we keep to a single, static file name for for each shader to keep from updating the support plugin constantly.

I did suggest that plug-ins could have optional meta-data that modders could be able to access like the mod name, author and version number but nobody thought it was a good idea because no one would use it. I can add the commands if you think it would help your project. Of course the shader file authors would have to supply the data for it to work.

OK, I did some quick testing and:

1. Loaded a game without the plugin, no shader loaded. Screenshoted.
2. Loaded a game with the plugin, shader loaded. Screenshoted and saved.
3. Loaded the saved game without the plugin, shader not loaded. Screenshoted and saved.
4. Loaded previously saved game. Screenshoted.

Screenshots 1, 3 and 4 are identical, with only 2 showing the effect. This is with no removefullscreenshader calls, just letting OBGEv2 handle everything internally, so it looks like everything will be fine regarding previous OBGE mods working with OBGEv2. In all cases, the shader file was present, even when the plugin was not active.



and then when I loaded 4:

Ingnoring message.RESZ format supported.Depth buffer texture (INTZ) (1366,768) created OK.Depth buffer attached OK. 0Releasing the original depth surface.Received load game message.Loading a game.Creating vertex buffers.Creating screen texture.Width = 1366, Height = 768Setting screen surface.Setting depth texture.Loading the shaders.Loading shader (data\shaders\)Failed to load.Added to list OK.Loading the shaders.Loading shader (data\shaders\)Failed to load.Save file links 0 textures.Shader Index = 1

I'm not entirely sure, but it looks like that when you save the game with plugin, the shader is saved in it. Then, when you load that save, OBGEv2 references the shader, but doesn't apply it because the plugin no longer exists. If that is then saved, a 'clean save' takes place, and the shader is no longer referenced at all, but there is still a shader indexed in the save (compare with OBGEv2 log). So it looks like there is a need for a RemoveFullScreenshader call, otherwise this index will remain.

EDIT: I agree with the one name per shader file, over all iterations. It could get confusing otherwise, and you can always record versions inside the shader itself.

Actually in the 4th test there are no shaders saved in the save file. The shader index is just the ShaderID of the next shader to be loaded. The previous version of OBGE reused a shaderID when it was released. My version increases the shaderID each time you load a shader (until you reach the maximum number it can go up to and then it resets back to 0 (oh actually it doesn't - I need to fix that)). The reason I did this is this scenario:

• mod a loads shader x - OBSE method = shaderID 0, OBSEv2 method = shaderID 0
  
• user saves the game
  
• user deletes the fx file for shader x.
  
• user loads the previously saved game - the serialization interface can find shader x so it isn't loaded
  
• mod b loads shader y - OBSE = shaderID 0, OBSEv2 = shaderID 1
  
• mod a tries to change shader x - with OBSE shader y will get changed, with OBSEv2 you get an error

OK the scenario is pretty unlikely but as a programmer I have to think of all the ways in which someone can break stuff.

[Samantha Mitchell]

Oh, so there's no real problem, it's just that the shaderID is 'reserved' for the AmbientDungeons.fx, in case it ever gets loaded again. That makes sense.

[Louise]

Oh, so there's no real problem, it's just that the shaderID is 'reserved' for the AmbientDungeons.fx, in case it ever gets loaded again. That makes sense.

It's not reserved. Once you 'clean save' it will lose the shader information for that shaderID. If you try to use that shaderID you'll get an error (unless you've loaded in 2147483648 shaders before checking) saying that you've used an invalid shaderID and the mod writer will have to decide what action to take.

I'll need to change all of the shader commands to return -1 if you try to access a non-existent shader so that the scripts can keep track if anything goes wrong.

[NAkeshIa BENNETT]

The test I'm more interested in is what happens when you;

1) start game with mod loaded, mod loads shader for the first time.
2) save game using "quicksave key".
3) reload game using "quickload key" without restarting Oblivion.
4) reload game again using "load game menu" without restarting Oblivion.

I'm mostly interested in making sure that shaders are correctly unloaded and the saved shader stack is restored when a save game is loaded without restarting Oblivion. With OBSE v0.1 this was a problem and you had to explicitly make sure shaders were unloaded before another savegame was loaded, otherwise they stacked.

From scanti's description of how the loaded shader index is continuously incremented it sounds like most common problems will be avoided, but I suspect there might be corner cases around this;

1) start new game with no mods loaded, savegame O.
1) restart Oblivion with only modA loaded, load savegame 0, modA loads shader A.fx, savegame A
2) restart Oblivion with only modB loaded, load savegame 0, modB loads shader B.fs, savegame B
3) restart Oblivion with modA and ModB loaded, load savegame A, modB loads shader B.fx, savegame AB
4) restart Oblivion with modA and ModB loaded, load savegame B, modA loads shader A.fx, savegame BA
5) without restarting Oblivion, load savegame AB...

will ModA and ModB now have swapped shaders?

[NIloufar Emporio]

@ Scanti: OK, that's fine for me anyway.

@ ABO: The problem doesn't exist any more in OBGEv2. The above test I did was with both quicksave/load and normal save/load. Shaders are no longer stacked unless you explicitly specify them to with the allowDuplicates flag.

Regarding your example, no. AB will remain AB, from what I can tell.

[Kevan Olson]

Can I have a list, of shaders that works without the depth buffer ?

[Svenja Hedrich]

It's not even getting as far as compiling the fx files.

At what point does Oblivion crash?

Does it still crash if you temporarily remove the OBSEv2.dll from your oblivion\data\obse\plugins folder?

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.

[Oscar Vazquez]

Can I have a list, of shaders that works without the depth buffer ?

ColorEffects
ColorMood
Sharpening

those don't need Depth Buffer. Everything else does.

[Greg Swan]

ColorEffects
ColorMood
Sharpening

those don't need Depth Buffer. Everything else does.

Thanks

[Nicole Coucopoulos]

OBGEv2 don't works with the MotionBlur mod :nope:

[Setal Vara]

OBGEv2 don't works with the MotionBlur mod :nope:

Yes it does. Read the OP. You have to change some things in the .fx file.

[Milad Hajipour]

Yes it does. Read the OP. You have to change some things in the .fx file.

I know, but for some reason, wrinklyninja removed this post :huh: ........

[Beat freak]

The OP is still there, the last time I checked, and it has a big FAQ section with that FAQ in it.

HINT: The bug you are getting is a blue screen/flickering one, correct? How about looking at the FAQ for that?

[KRistina Karlsson]

Huh. I was having that problem, but I wasn't sure what was causing it. I didn't think it was a bug with OBGE, but I'm now thinking it might have been.
Of course, I'm going to test if the problem is solved now, but if it isn't, then I'll have to keep checking for the solution.
(I've had that problem for a while, before I installed OBGE, but it kinda got worse when I started using it)

[Solina971]

I don't get blue screen :huh: ! but MotionBlur just don't works :confused:

I don't get directional blur effect, neither the brightness/contrast !

[Katey Meyer]

I don't get blue screen :huh: ! but MotionBlur just don't works :confused:

Change all instances of "half" in the .fx to "float". If you haven't done that already. That's what I did and motion blur works fine for me.

[Tracey Duncan]

Whoops, blue screen is gone now, of course. Gotta update FAQ. :facepalm:

[W E I R D]

Change all instances of "half" in the .fx to "float". If you haven't done that already. That's what I did and motion blur works fine for me.

Thanks

[+++CAZZY]

FAQ updated now.

I've finished making the changes to Ambient Dungeons to move it over to using OBGEv2, and I plan to release that, and an updated version of Enhanced Seasons, once OBSE v18 gets out of beta and Scanti releases the next version of OBGEv2. Then I'm going to lay those two to rest, along with Enhanced Weather, and let myself concentrate my modding on this and All Natural.

EDIT: Oh, and BOSS. I always forget that one.

[Anna Krzyzanowska]

I can do that no problem. I'll need to get some op-codes from the OBSE team.

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

Textures can used by the shader system and the HUD system. I can probably get the serialization system to release textures associated with an unloaded plug-in if I'm careful. I'll try to wrap my head around the problem.

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

I did suggest that plug-ins could have optional meta-data that modders could be able to access like the mod name, author and version number but nobody thought it was a good idea because no one would use it. I can add the commands if you think it would help your project. Of course the shader file authors would have to supply the data for it to work.

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.

[alyssa ALYSSA]

I have been working on learning shaders be reverse engineering other shaders to my own benefit. But I don't think I yet know enough to toy with it. Thanks for telling me haha =P


EDIT:
found this

"Geometry shaders can add and remove vertices from a mesh. Geometry shaders can be used to generate geometry procedurally or to add volumetric detail to existing meshes that would be too costly to process on the CPU. If geometry shaders are being used, the output is then sent to the rasterizer."


Anybody getting the ideas I am?

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.

[Avril Louise]

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.