GLX3 Shader/Shader-toy compatible plugins!

[AmmarkoV]

Hello, Πρώτα από όλα είμαι Έλληνας :P , ωραίος και πολύ ωραίο project! :D Having said and for this message to be readable from other people browsing github, I am trying to port my GLX3 shader based standalone renderer to create a xlivebg "plug-in" for shaders :)

I think this can be a great addition to this tool that will make this application compatible with a ton of great work @ https://www.shadertoy.com/ . It will also be possible to have a single plug-in that can load from a multitude of different shader "text" files which will make extending xlivebg much easier for newcomers.

I have forked your repo ( https://github.com/AmmarkoV/xlivebg/tree/master/plugins/shadertoy ) and added my source that renders this example https://www.shadertoy.com/view/Ms2SD1 using pure C / GLX3 / glew code.. I don't know if you want to pull it, currently I have changed nothing on your code, my code is also GPL3 so it is compatible with yours.

However upon trying to add your plugin system I think that there may need to be some changes in xlivebg for my use-case ..

You can compile my sample to check it out ..

However I think that maybe my glx3.c/glx3.h has to be merged inside your code base in order to be able to have OpenGL3+ shader support..

Looking forward to your feedback or comments, and once again great job!

[AmmarkoV]

By the way the output of the above mentioned shader looks like this..

I have also added some primitives on top as a way to showcase opengl3 primitive rendering..

[jtsiomb]

Heh, nice! It so happens that a friend of mine also suggested that I should write a shadertoy-compatible live wallpaper plugin for xlivebg a couple of days ago. And I agree, it would make a nice feature. Although most shadertoy shaders are a bit on the heavy side, and would hit the GPU pretty hard.

I haven't seen your code yet, I'll take a look soon and get back at you. But if we're talking about merging it in xlivebg, it'll have to drop all unnecessary dependencies. So for instance helper libraries like glew will certainly have to go, and if an OpenGL 3+ context is not absolutely necessary for this (which I can't imagine why it would be), that requirement should be dropped too.

[AmmarkoV]

I think the OpenGL3+ is needed for the more "advanced" shaders that use GLSL 1.3+ shaders ( a.k.a. most of them ) https://en.wikipedia.org/wiki/OpenGL_Shading_Language#Versions

Compiling the code can be done with this one-liner

gcc -o gl3Tex -DUSE_GLEW glx3.c glx_testRenderToTexture.c shader_loader.c matrix4x4Tools.c matrixOpenGL.c -lm -lGL -lGLU -lX11 -lGLEW

As you can see it relies on pretty vanilla stuff, I also tried to avoid the GLEW dependency ( this is why you also need the USE_GLEW define ) however unfortunately it makes good sense to use it to avoid directly dealing with openGL version crazyness..

I hope that the code snippet might be the basis for something useful, in any case once again, good job and keep up the good work..!

[jtsiomb]

No, OpenGL versions are more or less meaningless. Any feature can be accessed through the extension mechanism. There is the possibility that an implementation might decide to expose a certain feature only to core profile contexts, but that's extremely rare and silly, and it's not going to be an issue just for running shaders.

Adding a dependency just to avoid the effort of manually handling OpenGL extensions does not make good sense.

[jtsiomb]

Ok I just took a first quick look through your code. There doesn't seem to be a lot related to xlivebg in there. It creates its own context, doesn't use the xlivebg API to retrieve viewport information about the user's screen(s), and has some completely unrelated things in there. Also it's been some time since I've looked into what shadertoy provides to its shaders, but this doesn't seem to attempt to emulate it very much.

So I assume this is work in progress? What's your intention? Do you want to continue working on it to make a live wallpaper out of it? If so, then feel free to ask (here or through email) any questions about how to hack the integration, and also take a look at the xlivebg manual, where it has a section about how to write live wallpaper plugins, including a simple example plugin.

If you don't intend to work on it yourself, then I shall take this issue as a feature request, and possibly write a shadertoy wallpaper myself when I get the chance.

Let me know your intentions either way, so we can coordinate, and avoid duplicated effort.

[AmmarkoV]

Since as you said the standalone application I added on the forked repo is not based on xlivebg and is actually a minimal cut of my renderer :P , that I wanted to work its way using xlivebg until I saw the different core profile context stuff and stopped, I think the final solution would probably be best if you develop it, so consider this a feature request :)

The stub I added is pretty bare-bones, I haven't added a more general ichannels logic because as I can see in your code you already have a way to receive mouse/keyboard events and parse textures. I guess that it still contains some useful code segments such as the render to texture pipeline which could be useful since its the basics of how shadertoy handles the declared variables etc.

Shadertoy has "ichannels" that are control devices, webcam, microphones, textures, cubemaps, videos etc.. that are similar to your PROPLISTs so it makes better sense to use this mechanism for "ichannels"

I think developing a tool that handles all of them correctly is going to be very time consuming effort, and ultimately not worth the effort. ( I guess it would be a fun toy to have microphone input make ripples in your desktop, however it is probably both too CPU/GPU intensive as you said in your original message as well as a bad "feature-creep" that will add too much functionality unrelated to X-Server ). A minimal set of keyboard/mouse/textures should cover a very big number of the most interesting shaders and effects in shadertoy.com

[jtsiomb]

Agreed, a best-effort approach of implementing whatever makes sense, but not necessarilly all the potential shadertoy inputs is probably best.

Multiple shaders drawing to textures should be easy enough to accomodate, and there should be a pack of all textures provided by shadertoy, either compiled in the plugin, or installed under /usr/local/share/xlivebg-shadertoy or something during installation. Another possibility would be to download them on demand, especially if shadertoy accepts plain http connections, to avoid depending on openssl/gnutls for this. Alternatively we could mirror and host the data files at the xlivebg web site for easy access.

It would be nice, but not essential to provide shadertoy urls to the plugin configuration, and it figures out what it needs to get and what inputs/stages to configure automatically. Again I'm hesitant to do this if it means adding another dependency, but if shadertoy accepts non-SSL connections, it should be relatively simple to hack.

Unless I get distracted by other projects I think I'll give it a go. Possibly the best way to do it is to first bring my old standalone shadertoy-view program up to date with current shadertoy shaders (https://github.com/jtsiomb/shadertoy-view) and then use that code to make a new live wallpaper plugin.

[AmmarkoV]

Great! Best of luck man, upon its completion I think xlivebg will be a seriously sexy and nice application for the GNU/Linux desktop .. 2021 Year of the GNU/Linux Desktop :D !