v3 shader development

OtisInf
Topic Author

7 years 10 months ago - 7 years 10 months ago #1 by OtisInf v3 shader development was created by OtisInf

A separate topic for this important subject

As a test I'll port my own (not to difficult) shaders from v2 to v3 format. I immediately ran into a bit of a problem: reshade.fx's contents.

Version 2 uses a global.cfg, but v3 doesn't. So a couple of questions to get porting started:

* The global.cfg values, they're going to be editable in the 'Settings' section I presume? The main issue is of course the settings for the depth buffer. As various effects use the depth buffer, it's silly to have each effect edit the same settings for depth buffer linearization.
* [strike]The various uniforms which are defined in v2, are they available in v3 too? E.g. the mouse coords, timer etc. I presume they are, so can a shader dev assume they are equally named?[/strike] Yes they are (but you have to define them yourself).
* [strike]The constants defined in Reshade.fx, like BUFFER_WIDTH, BUFFER_RCP_WIDTH, they're going to be available too?[/strike] Yes they are
* The textures and samplers defined in v2 Reshade.fx, they're going to be available in v3 automatically or do they need to be defined by each shader? COLOR and DEPTH are available automatically I presume?
* Do you have a small list of ui_type values? E.g. what to use for bool or key selectors? Float3/4's are now displayed as a 3 or 4 value drag set, but if it's a color, a color picker would be better. This might be doable by specifying what ui_type is required. Same goes for settings which are currently an int as they're #defined and used in preprocessor directives, but are actually toggles.
* I defined a toggle key variable as uniform, but it's then not usable in a technique. How should shader devs define their toggle key variables so they're also editable?
* Passed in Reshade.fx to linearize depth and to make reshade work (like VS_PostProcess), I have redefined them once now in Reshade.fxh, and the 'Setup' technique they're contained in is showing up in the list of techniques on 'Home'. This is of course not useful, as this isn't an optional shader. Not sure what to do with this.
* ui_tooltip doesnt seem to work for e.g. float3: I get the color as tooltip, not the description

This might be by design.
* the uniforms which are editable use as labels the names of the variables. This might be a bit restrictive as it requires the variable name to be user understandable and also usable as a variable name in the code. I'd like to propose a ui_label annotation for the uniforms so you can define a label for the variable in the UI.
* Are there any plans for pre-defined ordering of shaders? I.e. an overlay shader shouldn't be before a DoF but after. I know you can drag/drop the order, but it might be good as well to have some sort of precedence value specified with the technique: by default it's e.g. 10, if specified, it can e.g. be set to 20 to be sorted after the ones with values < 20.
* Probably not implemented yet, but if I alter a shader var's value in the Reshade UI, where are the values stored?
* Probably not implemented yet, but if I make changes to the settings, they're saved in the ini files in <game>\Reshade, as they're also loaded from there, but restarting the game will not load the values back.
* The 'LinearizedDepth' sampler included in Reshade.fxh in a shader can't be accessed in a function, only in a pixel shader. This is likely to do with the definition of it (as it probably has to be defined differently now) and me not knowing that. It's a shader compiler error: "unknown identifier LinearizedDepth". Accessing it in a pixelshader instead works fine.

My main ideas are the following:
* One shader folder with all the files: fx and fxh.
* One general include for all shaders, Reshade.fxh, which is also in the shaders folder. It's a stripped down Reshade.fx file which contains logic/defines used by most, if not all, shaders
* A .fx file is named <shaderauthor>_<shadername>.fx, e.g. Otis_DepthHaze.fx
* A .fx file includes Reshade.fxh if it needs to, to make porting easier
* A .fxh file with the name <shaderauthor>_common.fxh is created for the utils/common files in the various shader author folders in v2.
* A 'Textures' folder is created inside the Shaders folder for texture retrieval.

This gives 1 folder with fx files and all support files they need. I'll try to bring shaders over one at a time. For now I'll use Reshade.fxh with hard-coded #defines for the depthbuffer settings.

My progress is available here: github.com/FransBouma/reshade-shaders/tree/v3
Lots of temp stuff still there, with progress this will be removed like the cfg files. Additionally, the mouse overlay fx is likely not needed anymore, but I've ported it as it's a simple thingy so it got things up and running quickly.

Sorry for the flood

No more time today, I ported 3 (simple) shaders. In-game editing works, things are progressing nicely in the right direction!

Last edit: 7 years 10 months ago by OtisInf.

Please Log in or Create an account to join the conversation.

crosire

7 years 10 months ago - 7 years 10 months ago #2 by crosire Replied by crosire on topic v3 shader development

OtisInf wrote: * The global.cfg values, they're going to be editable in the 'Settings' section I presume? The main issue is of course the settings for the depth buffer. As various effects use the depth buffer, it's silly to have each effect edit the same settings for depth buffer linearization.

No. You need to do the depth linearization yourself.

OtisInf wrote: * The textures and samplers defined in v2 Reshade.fx, they're going to be available in v3 automatically or do they need to be defined by each shader? COLOR and DEPTH are available automatically I presume?

You need to define them yourself in each shader.

OtisInf wrote: * Do you have a small list of ui_type values? E.g. what to use for bool or key selectors? Float3/4's are now displayed as a 3 or 4 value drag set, but if it's a color, a color picker would be better. This might be doable by specifying what ui_type is required. Same goes for settings which are currently an int as they're #defined and used in preprocessor directives, but are actually toggles.

The only existing values for ui_type are "input" (default) and "drag" right now. I'm already experimentating with a color picker. I noticed you entered the variable type in your ported shaders there, that's not what the annotation is for, that type is read from the variable directly.

OtisInf wrote: * I defined a toggle key variable as uniform, but it's then not usable in a technique. How should shader devs define their toggle key variables so they're also editable?

It's not possible. Uniforms are only accessible by the shader on the GPU. Any additional features ReShade provides does not read them. The toggle key will probably be editable separatly in the future via the in-game menu.

OtisInf wrote: * Passed in Reshade.fx to linearize depth and to make reshade work (like VS_PostProcess), I have redefined them once now in Reshade.fxh, and the 'Setup' technique they're contained in is showing up in the list of techniques on 'Home'. This is of course not useful, as this isn't an optional shader. Not sure what to do with this.

You can hide techniques by adding "hidden = true" to the technique annotations. Also, to make sure the header is only included once (which you want in this case): ReShade supports #pragma once.

OtisInf wrote: * ui_tooltip doesnt seem to work for e.g. float3: I get the color as tooltip, not the description This might be by design.

The color tooltip is built into the edit control, I'm not sure if I can overwrite it. Will look into it.

OtisInf wrote: * the uniforms which are editable use as labels the names of the variables. This might be a bit restrictive as it requires the variable name to be user understandable and also usable as a variable name in the code. I'd like to propose a ui_label annotation for the uniforms so you can define a label for the variable in the UI.

Sounds reasonable. It would fall back to the variable name if ui_label does not exist.

OtisInf wrote: * Are there any plans for pre-defined ordering of shaders? I.e. an overlay shader shouldn't be before a DoF but after. I know you can drag/drop the order, but it might be good as well to have some sort of precedence value specified with the technique: by default it's e.g. 10, if specified, it can e.g. be set to 20 to be sorted after the ones with values < 20.

The initial order is determined by the order the effects were first loaded. So you could achieve that by naming your files accordingly (e.g. 1_DOF.fx, 2_Overlay.fx, ...).

OtisInf wrote: * Probably not implemented yet, but if I alter a shader var's value in the Reshade UI, where are the values stored?
* Probably not implemented yet, but if I make changes to the settings, they're saved in the ini files in <game>\Reshade, as they're also loaded from there, but restarting the game will not load the values back.

Is implemented. They are stored in the currently selected preset file. Click on "Load" on the home page and specify a file path to create one.

OtisInf wrote: * The 'LinearizedDepth' sampler included in Reshade.fxh in a shader can't be accessed in a function, only in a pixel shader. This is likely to do with the definition of it (as it probably has to be defined differently now) and me not knowing that. It's a shader compiler error: "unknown identifier LinearizedDepth". Accessing it in a pixelshader instead works fine.

You probably got the ordering wrong. Could be that the vertex shader is defined before the fxh file is included and it's therefore not available to it. Because you access samplers in vertex shaders just fine.

OtisInf wrote: My main ideas are the following

How you want to layout your shaders it entirely up to you. ReShade 3.0 does not come with shaders by default anymore. They can be downloaded separately and each developer may choose how to distribute them themself.

Last edit: 7 years 10 months ago by crosire.

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

7 years 10 months ago #3 by OtisInf Replied by OtisInf on topic v3 shader development

crosire wrote:
OtisInf wrote: * The global.cfg values, they're going to be editable in the 'Settings' section I presume? The main issue is of course the settings for the depth buffer. As various effects use the depth buffer, it's silly to have each effect edit the same settings for depth buffer linearization.
No. You need to do the depth linearization yourself.

After first thinking it is a problem, I saw your comment on github and it makes sense to do it in-place now.

Indeed if several effects use a linearized depth buffer it might be better to have them in 1 file and linearize the buffer into a texture, but indeed, it isn't a problem anymore.

That leaves the settings problem, namely every depth buffer using shader needs to have settings for whether the depth buffer is logarithmic/reversed/upsidedown etc. This should be centralized as the game is the dictating factor here and users expect this to be edited in the UI (as all other settings are there too). Having to specify the same values which are tied to the game used and won't change for every shader using a depth buffer is a bit of a pain.

OtisInf wrote: * Do you have a small list of ui_type values? E.g. what to use for bool or key selectors? Float3/4's are now displayed as a 3 or 4 value drag set, but if it's a color, a color picker would be better. This might be doable by specifying what ui_type is required. Same goes for settings which are currently an int as they're #defined and used in preprocessor directives, but are actually toggles.
The only existing values for ui_type are "input" (default) and "drag" right now. I'm already experimentating with a color picker. I noticed you entered the variable type in your ported shaders there, that's not what the annotation is for, that type is read from the variable directly.

Ok. A checkbox input is also required I think, considering we're moving from #ifdef defined_constant to if(defined_variable)

OtisInf wrote: * I defined a toggle key variable as uniform, but it's then not usable in a technique. How should shader devs define their toggle key variables so they're also editable?
It's not possible. Uniforms are only accessible by the shader on the GPU. Any additional features ReShade provides does not read them. The toggle key will probably be editable separatly in the future via the in-game menu.

Got it. It's not a big deal I think: most users will toggle effects on the Home tab in the UI, advanced users might edit some file to get a specific key bound.

OtisInf wrote: * Passed in Reshade.fx to linearize depth and to make reshade work (like VS_PostProcess), I have redefined them once now in Reshade.fxh, and the 'Setup' technique they're contained in is showing up in the list of techniques on 'Home'. This is of course not useful, as this isn't an optional shader. Not sure what to do with this.
You can hide techniques by adding "hidden = true" to the technique annotations. Also, to make sure the header is only included once (which you want in this case): ReShade supports #pragma once.

Each .fx should include its own includes, no? So if I include reshade.fxh in shader1.fx, I also have to include it in shader2.fx, or am I mistaken?

OtisInf wrote: * ui_tooltip doesnt seem to work for e.g. float3: I get the color as tooltip, not the description This might be by design.
The color tooltip is built into the edit control, I'm not sure if I can overwrite it. Will look into it.

I couldn't get any tooltip to work though...

OtisInf wrote: * Are there any plans for pre-defined ordering of shaders? I.e. an overlay shader shouldn't be before a DoF but after. I know you can drag/drop the order, but it might be good as well to have some sort of precedence value specified with the technique: by default it's e.g. 10, if specified, it can e.g. be set to 20 to be sorted after the ones with values < 20.
The initial order is determined by the order the effects were first loaded. So you could achieve that by naming your files accordingly (e.g. 1_DOF.fx, 2_Overlay.fx, ...).

The order is persisted, I presume? If a person wants to share a preset, they have to share shaders, and the ini files with values (which include the order)? That would be enough I think.

OtisInf wrote: * Probably not implemented yet, but if I alter a shader var's value in the Reshade UI, where are the values stored?
* Probably not implemented yet, but if I make changes to the settings, they're saved in the ini files in <game>\Reshade, as they're also loaded from there, but restarting the game will not load the values back.
Is implemented. They are stored in the currently selected preset file. Click on "Load" on the home page and specify a file path to create one.

That's not very intuitive. A 'new' or 'create' button might be good to have there (I couldn't get it to save any ini files with values as well... it does save the ini files after every change?). Also it still creates appdata\roaming\reshade\*.ini files, even if I have specified a folder for the ini files in the game folder.

OtisInf wrote: My main ideas are the following
How you want to layout your shaders it entirely up to you. ReShade 3.0 does not come with shaders by default anymore. They can be downloaded separately and each developer may choose how to distribute them themself.

Ok. Are there any plans porting the shaders currently in v2 over to v3 or is that to be done by the authors themselves?

Please Log in or Create an account to join the conversation.

crosire

7 years 10 months ago - 7 years 10 months ago #4 by crosire Replied by crosire on topic v3 shader development

OtisInf wrote: That leaves the settings problem, namely every depth buffer using shader needs to have settings for whether the depth buffer is logarithmic/reversed/upsidedown etc. This should be centralized as the game is the dictating factor here and users expect this to be edited in the UI (as all other settings are there too). Having to specify the same values which are tied to the game used and won't change for every shader using a depth buffer is a bit of a pain.

I could provide a few more hardcoded preprocessor defines which can be modified in the UI. Whether shaders use or don't use them would be up to the authors though.

OtisInf wrote: Each .fx should include its own includes, no? So if I include reshade.fxh in shader1.fx, I also have to include it in shader2.fx, or am I mistaken?

Each fx is compiled separatly, so yes. But things like the following could happen (both Main.fx and SomeOtherFile.fxh include ReShade.fxh, so the file is copied into the source twice):

Main.fx
  -- ReShade.fxh
  -- SomeOtherFile.fxh
     -- ReShade.fxh

Adding "#pragma once" to ReShade.fxh eliminates the second copy. The same way it works in C++.

OtisInf wrote: The order is persisted, I presume? If a person wants to share a preset, they have to share shaders, and the ini files with values (which include the order)? That would be enough I think.

Yes, the technique order is stored in the preset INI.

OtisInf wrote: That's not very intuitive. A 'new' or 'create' button might be good to have there (I couldn't get it to save any ini files with values as well... it does save the ini files after every change?). Also it still creates appdata\roaming\reshade\*.ini files, even if I have specified a folder for the ini files in the game folder.

Any change in the shader parameter window is immediately saved to the selected preset INI (provided the location is writable).
There has to be a .\ReShade\Settings.ini in the game folder for ReShade to start using that location for storing settings. a .\ReShade folder alone is not enough.

OtisInf wrote: Ok. Are there any plans porting the shaders currently in v2 over to v3 or is that to be done by the authors themselves?

Marty already has standalone versions of most of his work. The rest I hope the authors can update themselves, but I'll probably have to port some too.

Last edit: 7 years 10 months ago by crosire.

Please Log in or Create an account to join the conversation.

crosire

7 years 10 months ago - 7 years 10 months ago #5 by crosire Replied by crosire on topic v3 shader development

crosire wrote: I could provide a few more hardcoded preprocessor defines which can be modified in the UI. Whether shaders use or don't use them would be up to the authors though.

Or provide a window to add/edit global preprocessor defines that are set for every shader. Then I wouldn't have to hardcode anything.

Last edit: 7 years 10 months ago by crosire.

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

7 years 10 months ago - 7 years 10 months ago #6 by OtisInf Replied by OtisInf on topic v3 shader development

crosire wrote:
crosire wrote: I could provide a few more hardcoded preprocessor defines which can be modified in the UI. Whether shaders use or don't use them would be up to the authors though.
Or provide a window to add/edit global preprocessor defines that are set for every shader. Then I wouldn't have to hardcode anything.

I think that's best. Not that these depth buffer related values will change much, but this is more flexible indeed.

crosire wrote:
OtisInf wrote: Each .fx should include its own includes, no? So if I include reshade.fxh in shader1.fx, I also have to include it in shader2.fx, or am I mistaken?
Each fx is compiled separatly, so yes. But things like the following could happen (both Main.fx and SomeOtherFile.fxh include ReShade.fxh, so the file is copied into the source twice):
Main.fx
  -- ReShade.fxh
  -- SomeOtherFile.fxh
     -- ReShade.fxh
Adding "#pragma once" to ReShade.fxh eliminates the second copy. The same way it works in C++.

Got it, didn't think of that situation. Will use that from now on in includes

OtisInf wrote: That's not very intuitive. A 'new' or 'create' button might be good to have there (I couldn't get it to save any ini files with values as well... it does save the ini files after every change?). Also it still creates appdata\roaming\reshade\*.ini files, even if I have specified a folder for the ini files in the game folder.
Any change in the shader parameter window is immediately saved to the selected preset INI (provided the location is writable).
There has to be a .\ReShade\Settings.ini in the game folder for ReShade to start using that location for storing settings. a .\ReShade folder alone is not enough.

I think I had that, but will recheck. I also specified a different folder for where the shaders were, but that too wasn't persisted. Might be related to program files, although I'm on win8.1. I'll try later today to see whether I can cleanly reproduce it.

OtisInf wrote: Ok. Are there any plans porting the shaders currently in v2 over to v3 or is that to be done by the authors themselves?
Marty already has standalone versions of most of his work. The rest I hope the authors can update themselves, but I'll probably have to port some too.

Ok. I'll port mine at least.

Last edit: 7 years 10 months ago by OtisInf.

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

7 years 10 months ago - 7 years 10 months ago #7 by OtisInf Replied by OtisInf on topic v3 shader development

Regarding value storage for shaders: can't get any value stored.

I have removed the Reshade folder in the game folder, I have only the C:\Users\MyUserID\AppData\Roaming\ReShade folder with the 3 .ini files. When I start the game, crysis3, I do ShiftF2, it shows the contents of the ini files, so that's good, I can edit the shader values, but the values aren't persisted.

Settings.ini:

[C:\Program Files (x86)\Origin Games\Crysis 3\Bin32\crysis3.exe]
DeveloperMode=1
ScreenshotPath=C:\Program Files (x86)\Origin Games\Crysis 3\Bin32
MenuKey=113
ScreenshotKeyCtrl=0
MenuKeyCtrl=0
ScreenshotKey=44
MenuKeyShift=1
ScreenshotKeyShift=0
ScreenshotFormat=0
EffectSearchPaths=C:\Program Files (x86)\Origin Games\Crysis 3\Bin32\Reshade,C:\Users\MyUserID\Documents\GitHub\reshade-shaders
TextureSearchPaths=C:\Program Files (x86)\Origin Games\Crysis 3\Bin32\Reshade,C:\Users\MyUserID\Documents\GitHub\reshade-shaders\Textures
Presets=C:\Users\MyUserID\AppData\Roaming\ReShade
CurrentPreset=0

No ini file is written in the folder specified in Presets, nor any other ini file contains the values. Perhaps I'm looking at the wrong location. The folder is writable as the other ini's are written properly.

Last edit: 7 years 10 months ago by OtisInf.

Please Log in or Create an account to join the conversation.

crosire

7 years 10 months ago - 7 years 10 months ago #8 by crosire Replied by crosire on topic v3 shader development

You have to specify a preset file, not a directory, e.g. "C:\Users\MyUserID\Documents\MyPreset.ini". That's how you can choose between different presets. Each is stored in its own file.
"Presets" is a list of files. It's the list displayed in the combo box on the home page of the UI. "CurrentPreset" is an index into that list.

Last edit: 7 years 10 months ago by crosire.

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

7 years 10 months ago #9 by OtisInf Replied by OtisInf on topic v3 shader development

ah!

Will try that, thanks

Please Log in or Create an account to join the conversation.

Marty McFly

7 years 10 months ago - 7 years 10 months ago #10 by Marty McFly Replied by Marty McFly on topic v3 shader development

Short question: if we have uniforms, how does constant folding work? Defined variables can be folded but uniforms that should be editable can't, right? So it makes the shaders slower if they use a lot of ui variables.

Also, what about enabling/disabling effects? In some shader combos like in MasterEffect you can't just put those in different techniques, that still requires editing of the game files.
ENB does some things I personally find reasonable: the gui has a save and load button so you can change your configuration as you wish but if you want to revert your changes, click Load. If you want to keep your changes, press Save. If some variable that is changed requires recompiling (like defines), you need to save the settings and click apply changes, that will trigger recompiling. That way you can make all defines somewhat editable in the ui and are not bound to change them in code. However this cannot be done in the external shades, only the internal ones have this, like AO debug output requires recompiling.
About colors: I guess the way you select colors right now in the customization menu is alright but in case you want a color picker, don't use the bloody awful windows integrated one. Photoshop color picker is pretty cool.

Last edit: 7 years 10 months ago by Marty McFly.

Please Log in or Create an account to join the conversation.

crosire

7 years 10 months ago #11 by crosire Replied by crosire on topic v3 shader development

I'm going to add support for editing constants soon (constant variables, not defines), which can be optimized by constant folding. A Save/Load button is an easy thing if that's preferred.

I'm not sure what you are trying to tell me regarding enabling/disabling effects?

Please Log in or Create an account to join the conversation.

Marty McFly

7 years 10 months ago - 7 years 10 months ago #12 by Marty McFly Replied by Marty McFly on topic v3 shader development

Oh that's great!
About the enabling/disabling: a lot of effects can't be toggled via UI because it would be an insane waste of performance to put them into 2 different techniques, such as say 2 color graders which can fit in one pass. So the only thing that could be done is using a bool which kills performance with branching. ENB solves that by having a button that forces recompilation and you can edit the #defines in the UI. So let's say I have vibrance enabled but not lift gamma gain. Both are in the same pass so toggling the technique does nothing.
I set the #define USE_LIFTGAMMAGAIN in the UI (which can't be done yet) to 1, click a button to force recompilation and then it's enabled. Right now, I'd have to use branching to make vibrance and lift gamma gain separately toggleable in the UI or put them into different passes and techniques.

Last edit: 7 years 10 months ago by Marty McFly.

Please Log in or Create an account to join the conversation.

crosire

7 years 10 months ago #13 by crosire Replied by crosire on topic v3 shader development

Not possible yet, but the following is what I meant. Since this is a constant that's known at compile time, the branch will be optimized away.

static const bool use_liftgammagain < ui_type = "checkbox"; > = true;
...
if (use_liftgammagain)
{
}

Please Log in or Create an account to join the conversation.

Marty McFly

7 years 10 months ago #14 by Marty McFly Replied by Marty McFly on topic v3 shader development

Is that really so?

so this runs with the same performance as using defines? Also, how are bools handled/will be handled on gui? I tried int annotation, did create floats anyway. Are you doing some kind of check box or something?

Please Log in or Create an account to join the conversation.

crosire

7 years 10 months ago #15 by crosire Replied by crosire on topic v3 shader development

Yes, constant branches are optimized away. I could do this in the ReShade FX compiler already, it's not complicated, but the HLSL/GLSL compilers do that too.
And yes, I'll add custom controls for integers and booleans (most likely a checkbox), but they aren't implemented yet.

The following user(s) said Thank You: OtisInf

Please Log in or Create an account to join the conversation.

crosire

7 years 10 months ago #16 by crosire Replied by crosire on topic v3 shader development

I chose a slightly different path now, which I think is preferable to everybody. ReShade now lets you switch between three modes: performance mode, configuration mode and developer mode. If the second or third are enabled, the uniform editor is shown and lets you modify variables in real-time (now on the home tab instead in a separate window). If the user then switches to the first option, the editor is hidden, all shaders are reloaded and every uniform variable in shader code is replaced with a constant value automatically before passed on to the native compiler. This way it's possible to edit all values in real-time, but also to get the best possible performance via constant folding after one is finished with tweaking.

The following user(s) said Thank You: OtisInf

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

7 years 10 months ago #17 by OtisInf Replied by OtisInf on topic v3 shader development

crosire wrote: I chose a slightly different path now, which I think is preferable to everybody. ReShade now lets you switch between three modes: performance mode, configuration mode and developer mode. If the second or third are enabled, the uniform editor is shown and lets you modify variables in real-time (now on the home tab instead in a separate window). If the user then switches to the first option, the editor is hidden, all shaders are reloaded and every uniform variable in shader code is replaced with a constant value automatically before passed on to the native compiler. This way it's possible to edit all values in real-time, but also to get the best possible performance via constant folding after one is finished with tweaking.

Excellent compromise!

Please Log in or Create an account to join the conversation.

crosire

7 years 10 months ago #18 by crosire Replied by crosire on topic v3 shader development

github.com/crosire/reshade-shaders is now open for 3.0 shader development. I added a SMAA port as an example to study.

The following user(s) said Thank You: piltrafus

Please Log in or Create an account to join the conversation.

Marty McFly

7 years 10 months ago #19 by Marty McFly Replied by Marty McFly on topic v3 shader development

As far as I see:

-standalone FX'es into "Shaders"
-includes of FX'es called .fxh, same folder
-Textures into "Textures"
-ReShade.fxh for common utils like depth linearization and standard vertex shader

is that everything?

Please Log in or Create an account to join the conversation.

crosire

7 years 10 months ago - 7 years 10 months ago #20 by crosire Replied by crosire on topic v3 shader development

Pretty much, yes. This is only a suggestion, it's not required to follow that layout. But it's good practise to do, so all available shaders can be collected in a central place.

Last edit: 7 years 10 months ago by crosire.

Please Log in or Create an account to join the conversation.