skeletonbow / obs-shaderfilter Goto Github PK

An en-US.ini file installed by OBS Studio gets overwritten by a customized one supplied by Shaderfilter. Shaderfilter has no installer so copying the files into one's OBS installation just blows away the OBS Project supplied files with Shaderfilter modified versions that may be significantly out of date, in particular as the OBS Shaderfilter project has become unmaintained for some time.

This practice should be discontinued and replaced with a proper installation program that merges any custom changes into the file rather than blowing it away and possibly losing updates provided by the OBS Project.

When using a custom texture with a supplied filename in the shader file, Shaderfilter does not honour the filename provided and defaults the field to blank, requiring the end user of the shader to manually specify each texture every time they use the shader. It would be much more convenient and user friendly to have it pick up and use the filename specified by the shader developer by default.

The original OBS Shaderfilter and the prominent forks have never supplied a proper EXE file based installation package, which would make it much more convenient for users of the plugin to install the software.

Additionally, many of the problems with the current drag-n-drop files using File Explorer would go away such as bug #3, and #6, by instead merging the changes into these files by using a JSON library to insert elements into the configuration upon installation, and remove them upon uninstall.

The InnoSetup installer software should be used to create a new installer for OBS Shaderfilter in the future. Various other plugins such as StreamFX, and Exeldro's various plugins all use the InnoSetup installer so there are plenty of existing plugins InnoSetup configs to consult for creating one for OBS Shaderfilter.

Shaderfilter contains PNG files that end up installed into obs-studio\data\obs-plugins\obs-transitions\luma_wipes which are not actually useful, and just show "SEE SURN FOR MORE TRANSITIONS". It's not clear what the purpose is, unless it is just an advertisement, but they are really just unnecessary clutter.

It is my goal to build OBS Studio and OBS plugins from source code on the Windows operating system using an open source toolchain such as Clang/MinGW or similar, in order to avoid reliance on Microsoft's proprietary toolchain.

The OBS Project official Build Instructions For Windows currently provides 2 supported methods for building OBS Studio for Windows, both of which use and require Microsoft's free proprietary Visual Studio 2019 Community Edition in order to build the software at the time of this writing. While the Community Edition of Microsoft's software is currently available at no cost it itself is not open source, and this older version of Visual Studio requires authenticating with the Microsoft website using a Microsoft login account in order to gain access to download which is undesirable.

A minor amount of research has suggested to me that it may be possible to build OBS Studio and plugins for it on Windows by using Clang with MinGW, however it will require a deeper investigation to figure out how to do this as it does not appear to be documented anywhere and is most likely not an officially supported way of building OBS by the project on Windows.

Nonetheless, I will need to find a solution to building OBS Studio and plugins on Windows that do not require Microsoft's proprietary tools in order to proceed, so this should be a fun project to take on.

Requirements:

• Build OBS Studio, and OBS Shaderfilter from source using only open source tools on the Windows operating system.
• The built plugin needs to be compatible with and loadable with the official OBS Studio binary release distributed by the OBS Project for Windows.

Additional notes:

• The use of open source or proprietary tools which are available free of cost, and do not require a user account login or present any other limitations or restrictions is potentially acceptable depending on the circumstances.

Rationale:
I want to develop and contribute to an open source project's ecosystem without requiring permission/approval from Microsoft to do so, in the spirit of fundamental open source principles.

If OBS Shaderfilter is installed into a brand new never used OBS installation (OBS 27.2.4 used in testing), and OBS is started up and then immediately exited, with no scenes added and no filters being used, OBS will exit with a log file indicating that over 3000 memory leaks were detected. If OBS Shaderfilter is removed, this goes down to 1 memory leak.

If this makes it to release status in the future, there will be people naturally having common issues installing, etc. so it would be a good idea to make a pre-emptive FAQ to handle predictable common problem situations people are likely to have, based on the problems people have installing and using other common OBS plugins.

This issue can act as a holding place for possible FAQ entries.

• Use float or uint instead of int.
• Use swizzle to reduce code and improve readability.
• Use step() instead of conditionals.
• Use mad() fused multiply-add intrinsic instead of discreet math operations.
• Explore optimizing the blur operation by sampling multiple pixels at a time with bilinear filtering to reduce GPU cost.
• Use clamp() for binding the blur radius range instead of min()/max().

Shaderfilter includes a PNG texture file in the luma wipes directory for AMD Ryzen. It's not clear why this is present currently, but it is probably a good idea to remove 3rd party companies' trademarked logos from the software to avoid any potential issues.

• Use float or uint instead of int.
• Use vectors instead of floats.
• Use swizzle to reduce code and improve readability.
• Use mad() fused multiply-add intrinsic instead of discreet math operations.

Shaderfilter 1.21 comes with a handful of shaders which appear to have had development started on them but never finished so they are completely non-functional, which could confuse users trying to get them to work. Many months ago someone was trying to port all of the shaders to GLSL to get them working on Mac without being very experienced in such matters and a stumbling block they fell upon was some of these non-functional shaders.

These shaders should be completed or more likely just completely removed as they're non-functional. The software should only ship with working code. Development should occur in one branch and get merged to master only when it is functional and ready to be included.

This may not be a complete list but some of the shaders which are incomplete and non-functional include:

• darken.shader

I'll complete the list as I go through them at a later date.

The OBS Shaderfilter plugin provides shader transitions for the StreamFX plugin which is odd to say the least, but it does so inside of the StreamFX package's directory namespace and overwriting stock files that ship with StreamFX with older versions that are modified that ship with Shaderfilter. This is bad software distribution practice, and should be removed in a future release.

gxalpha has submitted a PR to OBS to add radio button options to the OBS properties system. This would provide tremendous value in improving the user interface and overall friendliness of how shader options are presented to end users by being able to provide a list of choices verbally, rather than the current workarounds of having to use an integer with no visible user text and just having to know what each integer "mode" results in, or using a farm of checkboxes and remembering to never enable more than one in order to create fake makeshift radio buttons.

obsproject/obs-studio#7833

OBS Shaderfilter by default uses a built in template for ALL loaded shader files which includes a default vertex shader, technique, sampler types and uniform variables etc. If you wish to supply your own vertex shader or modify what is in the internal template, then you have to enable the checkbox "Use Effect File (.effect)" which disables the use of the built-in convenience template, and supply everything yourself in your shader file.

There is a convention that the file extension ".shader" is used for shaders that use the built in template, while ".effect" files specify everything themselves and need to bypass the built in template, however the user is required to manually check the checkbox to tell the plugin which type of shader the given shader file is. So the extension of the files is just a mental convention not actually observed by the plugin itself.

Forcing the user to manually check this checkbox requires more knowledge from the user concerning this convention, and makes it much more likely that an end user who is not a shader developer will get confused and not know what the checkbox is for or when to click it.

It is bad user interface design to present options to users that they must choose the correct choice to get the correct result in the software, if the software has the ability to determine this on its own, and then remove the option and present a simplified user interface to the user.

As such I posit that the plugin should not just suggest the file extensions as a convention, but actually enforce it by removing the "Use Effect File (.effect)" checkbox entirely, and using the filename extension of the shader it's been given to determine whether or not to use the built in template.

For shaders that are included with the plugin, they will just automatically work without having to check the checkbox and get it right, and for 3rd party shaders developed for Shaderfilter which do use the same naming convention, they will continue to work as well. The only problem case is if someone has a shader file named something other than .shader or .effect, or if the contents of the file do not match the convention for how Shaderfilter expects them to be named.

Possible solutions to this are:

1. Have the plugin installer or plugin itself look inside of the shader files and attempt to intelligently rename the file extension to the correct thing and/or determine it from the contents of the file.
2. Issue an error to the log file if a file has the wrong extension or can't be determined.
3. Just enforce the file naming convention with code, and leave it up to developers and/or users to rename the files correctly themselves going forward.

Unknown: If there are any commonly available shaders or shader packs for OBS Shaderfilter in widespread distribution that misuse the file naming convention, or use alternative extensions altogether.

Ideally, whichever gives end users the best experience by not breaking their setups or requiring manual intervention by them, is likely the better choice to go with.

• Use swizzle.
• Use Rec.709 or #include from a common include file.

• Some of the shaders duplicate code between each other which would be better shared in a common include file.
• Standardize the luma coefficients to be Rec.709 everywhere, possibly providing a global or shader specific where sensible.

Shaderfilter has no tooltips to explain what each shader property is for, nor way of specifying such. The current convention is to put a fake "string" property in the source called "Notes" and put a blurb of terse text instructions there to document some of the shader functionality.

By removing this convention and replacing it by using a combination of tooltips and a button that hyperlinks to opening a manual on the web with detailed instructions for the user, and possibly a YouTube tutorial for how to use the given shader, it would greatly improve the end-user experience of using shaders, while allowing people to use more of the shaders as they'd be able to figure out how they work more easily. It would also reduce the number of people potentially seeking technical support in web forums or github issues, as well as filing bug reports unnecessarily.

Whenever a shader has a property for user configurable color, specified as in the form uniform float4 color = { 0.5, 0.5, 0.5, 1.0};, OBS Shaderfilter does not successfully translate these supplied color channel values correctly, resulting in incorrect default colors showing up to the shader. They appear to be floating point values being interpreted as integers. This bug appears to go back to the original OBS Shaderfilter as well.

OBS Shaderfilter 1.2.1 is installed by manually copying the 'data' and 'obs-plugins' directories out of the ZIP archive into the OBS Studio top level directory 'obs-studio'. The plugin contains additional luma-wipe transitions, and includes an updated 'wipes.json' config file to inform OBS about them, however since the plugin contains no installer, this simply overwrites the existing config file that ships with OBS which may or may not be newer, or may have been customized by the user, thus blowing away the configuration and overriding it.

A far better way of integrating into the OBS software would be to merge the desired changes into the file by modifying and integrating it into the JSON, either by processing it with a JSON library and adding entries during installation, or by using text file scraping methods. Likewise, upon uninstall, it should remove such entries from the OBS configuration.

This is bad form and could result in new luma wipes that get added to OBS by the project or by the user in having their configuration overwritten with old data.

The "Shader text" property that first appears when you add the "User-defined-shader" property filter to a source has never really worked properly and is just clutter in the user interface that likely confuses some non-developer end users. I doubt there are many developers that would use it either as it is of extremely limited use at best.

Removing this feature would simplify the user interface and reduce non-developer end-user confusion. Nobody would likely miss it, and OBS Shaderfilter 1.21.1 would still exist if they needed to use this for some odd reason.

For this reason, I plan to remove it from my build in the future unless I come across a good enough reason to keep it. The "Load shader text from file" checkbox can then be removed also, and replaced by a "Shader file:" textbox.

Another option to consider, would be to scan the supplied shader examples directory and preload a combo box with all of the shaders so users can just pick one without having to navigate their hard disk, and then have an optional "manually specify shader file" option or something to navigate to a custom location to load a shader file.

All things worth exploring somewhat before committing to any specific changes though.