3.1
- alex
- crosire
- Topic Author
- alex
- Eddy Stylez
kingeric1992 wrote: It's merged to lut.fx
Are there any guides on how to use lut.fx? I liked multilut.fx because in the config window I could just pick a preset and be good to go.
- kingeric1992
- crosire
- Topic Author
- OtisInf
Users now have to mess with # defines, shader files to use it, most don't know how to do this. Before it was just picking a technique. Sorry, but this isn't a good move. I understand that the shader can use 1 texture and it has to be picked in code, but hey, there's a reason I defined a separate shader for it: so users could have both without tinkering with code. Now people can only use the multiLUT if they know how to add #defines (really most don't users know how to setup depth buffer settings, you expect them to look into the effect code and distillate the #define to add to the settings?).
This is done to keep down the compilation times as for people who pull down all shaders it's longer than needed with 2 shaders instead of 1? Why not compile to disk and timestamp the binaries with the timestamp of the source files, so recompiling isn't needed only if the file is changed (read: almost never)?
- kingeric1992
//multiLUT.fx
#define fLUT_AtlasAmount 12
#include "LUT.fx"
//eof
@crosire
if you have texture size default to file dimension when annotation "source" is specified, something like fLUT_AtlasAmount could have integrated into shader. (tex2Dsize just obsolete right now as the size still need to be predefined in the file. )
- crosire
- Topic Author
This is fully intentional, because by default the shader is supposed to work like the default LUT shader without an atlas. It's not a mistake, nor did it brake MultiLUT in any way, since settings that value to 12 or any other value effectivly activates the MultiLUT part of the shader (It's disabled by default) and everything works as expected. It's also not supposed to be forced to only work with the provided 12-part texture but with any sort of atlas the user comes up with. So there's that.OtisInf wrote: So the person who merged my multiLUT shader into the lut shader effectively broke it (blame says, that's you Crosire ) ? It's now defined as '1' which makes the multi-lut part useless, as the texture has 12 parts, not 1, hence 'multi' Not sure why this is defined to 1: github.com/crosire/reshade-shaders/blob/...r/Shaders/LUT.fx#L12
No, they don't. They have to add one line on the settings tab in the GUI.OtisInf wrote: Users now have to mess with # defines, shader files to use it, most don't know how to do this.
If things were that simple this would have been done a (really) long time ago. There is a lot more attached to a ReShade effect than just shader code, that cannot be reconstructed out of thin air.OtisInf wrote: This is done to keep down the compilation times as for people who pull down all shaders it's longer than needed with 2 shaders instead of 1? Why not compile to disk and timestamp the binaries with the timestamp of the source files, so recompiling isn't needed only if the file is changed (read: almost never)?
- OtisInf
No there's not 'that'.crosire wrote:
This is fully intentional, because by default the shader is supposed to work like the default LUT shader without an atlas. It's not a mistake, nor did it brake MultiLUT in any way, since settings that value to 12 or any other value effectivly activates the MultiLUT part of the shader (It's disabled by default) and everything works as expected. It's also not supposed to be forced to only work with the provided 12-part texture but with any sort of atlas the user comes up with. So there's that.OtisInf wrote: So the person who merged my multiLUT shader into the lut shader effectively broke it (blame says, that's you Crosire ) ? It's now defined as '1' which makes the multi-lut part useless, as the texture has 12 parts, not 1, hence 'multi' Not sure why this is defined to 1: github.com/crosire/reshade-shaders/blob/...r/Shaders/LUT.fx#L12
1) the user doesn't know what to add to the settings. Like I said before, the user on average doesn't even know how to change the depth buffer to logarithmic, that's not because they're stupid, but because they're not shader devs, don't know how code works and just want to use what's provided. How is the user going to find out what to add and *where* ? By reading all the posts on this forum?
2) I think you make a mistake with how it's used. The normal LUT shader is only usable if you give it a LUT you want to use, so you have to do work anyway, look up what a LUT is, how to make one etc. That tutorial likely also tells you what to add where. That's fine. The thing with the MultiLUT was that the atlas texture is ready to go: it contains 11 LUTs I created myself which are ready to use after install. It instantly gives you the shading effects also seen in photomodes (that was the whole idea of it): user enables the shader, picks one of the LUTs available and is done. So they don't have to alter anything, create anything or lookup anything. So the LUT and MultiLUT shaders don't have the same use case: the latter is a ready-to-use shader with LUTs people like to use and requires no setup. That was the whole point of it: drop it in and go.
Your action killed that. The user now has to go through hoops s/he never heard of to add some line they don't know to enable a shader which was previously simple to use.
I hope you can see why I'm slightly not amused by this.
I've added the shader here: github.com/FransBouma/OtisFX/tree/master/src/Reshade3 for people who want to get the old shader back.
As I made the shader and people come to me when things don't work (e.g. they forgot to copy the texture), I now also have to tell them they have to add a line to settings, while it was an easy to use shader before. Why on earth did you do this? Just make things easier for the user, not more complicated.
No, they don't. They have to add one line on the settings tab in the GUI.OtisInf wrote: Users now have to mess with # defines, shader files to use it, most don't know how to do this.
I was under the assumption your speedup work was intended to limit the # of compilations of shaders. My idea (given without looking at the sourcecode!) was about just that: compile only when needed, and e.g. pass in values that change once (constants that are defined e.g. resolution width/height) not as constants but as references in a uniform buffer. Which of course causes wrath being given by many so not a good idea then.
If things were that simple this would have been done a (really) long time ago. There is a lot more attached to a ReShade effect than just shader code, that cannot be reconstructed out of thin air.OtisInf wrote: This is done to keep down the compilation times as for people who pull down all shaders it's longer than needed with 2 shaders instead of 1? Why not compile to disk and timestamp the binaries with the timestamp of the source files, so recompiling isn't needed only if the file is changed (read: almost never)?
Anyway, I was merely asking that as I wondered why the shaders were merged to begin with and the only reason I could think of was that it was now 1 less shader to compile, but other than that, I have not the faintest idea how users are helped with this merge.
- crosire
- Topic Author
- OtisInf
Heh no it was plainly targeted at novices who have no idea what to do and just want to quickly change the shading of a picture using a different LUT. Otherwise indeed I can understand the change completely as it's mainly the same idea and the core code is similar.crosire wrote: I was operating under the assumption that MultiLUT was for advanced users who want to create an atlas of multiple LUTs and then allow selection from those in-game (since that's what the name implies, the original LUT shader isn't targeted at beginners), not that it was intended for beginners to have a selection of quick filters. Apparently I assumed wrong, so sorry for that.
I recon you'll roll back the change for this? Want me to create a PR for this?
- crosire
- Topic Author
- lowenz
- JBeckman
Though yeah as OtisINF mentioned which I can definitively relate to in my experiences with the utility and it's shader effects so far the shader code itself even with comments and instructions is mostly foreign to me, I barely understand the ReShade settings at all besides trial and error ha ha.
But the same goes for pretty much all software really, whether it's Afterburner/Rivatuner or ReShade or others let alone the OS itself or components like the drivers.
Testing and seeing what happens, slowly getting some understanding on how things are set up and how they work and what is compatible and in which way which isn't always easy but I find it fun though time consuming especially since math and programming in general is not something I've ever excelled at unfortunately.
I'm glad the latest update to SMAA added back predication, been missing that but never had the means to add it back myself, pretty obvious when you compare the pre and post commit on Github and have everything laid out and still don't understand a thing, eh maybe one day I'll have some understanding on this entire thing.
(For now, just another user ticking a few things here and there and observing the results.)
My own inexperience and lack of knowledge aside though 3.1.0 is working really well so far in the games I've stuck it into so far, some good fixes and additions.
- Gamerboy
Thank you for all your efforts and hardworking only because of you the Games looks beautiful. Please i have some request if u will do it it will be very big achievement.
Please make a Real HDR 10 Shader which is currently a famous and high demand among the gamers. Most New TV and consoles they provide HDR in their games but for PC we have only in few games. Please its humble request to consider.
- Mobeeuz
- crosire
- Topic Author
- Martigen
THANK YOU FOR MENTIONING THIS!JBeckman wrote: I'm glad the latest update to SMAA added back predication, been missing that but never had the means to add it back myself
I didn't know until you said this, I only update my shader repository from github very occasionally. Fantastic to have predication back!
- Gamerboy
crosire wrote: HDR is not something you can do in post-processing alone. It needs proper software support. It's not something I can try out though due to the lack of HDR capable hardware (and lack of motivation for getting such).
Thank you for your kind reply Sir. Will u try at least may b u can figure out something? By the way HDR is most beautiful and epic if it applies on any games through Reshade.