OSC/stdin support for loading/removing files

[coderofsalvation]

awesome project.

Btw. would it be feasible to load files on the fly using osc/stdin? For VJ-purposes it would be nice to be able to be able to run an empty glslViewer, and add/remove models/shaders over time (using OSC):

• load and unload command maybe?
• translate, rotate & scale command (for models) maybe?

Right now, this is somewhat achievable by overwriting files (auto-refresh), or writing scripts which run glslViewer using the unix timeout command (however the latter requires a hard restart of glslViewer). However, it would be awesome to just have glslViewer sitting in a directory filled with files, and being able to do more animation / management using osc/stdin.

hope all is well

[patriciogonzalezvivo]

Hi! I'm very excited to hear this request. Although hot-reloading geometry will take a long time to implement because of how glslViewer is architecture I will try to add it into the plan it.

About reloading shaders: switch between files is totally possible using defines flags and the #includes. I know it's not exactly what you have in mind but you could have a shader that looks something like:

#if defined(ANIMATION_00)
#include "animation_00.frag"
#elif defined(ANIMATION_01)
#include "animation_01.frag"
#else 
#include "empty.frag"
#endif 

then relaying in the console command:

> define,ANIMATION_00
> define,ANIMATION_01

That in OSC should look like

/define/ANIMATION_00
/define/ANIMATION_01

You could trigger totally different subshaders.

About your last point: I have been thinking of this for a while because is a slippery slope of request that could escalate to an entire API. Mi initial thought was more related orbital cameras. But I settle down on keep focus around shaders. On my code I use similar "commands" but as vector shader uniforms:

uniform vec3 translate;
uniform float rotateX;
uniform float rotateY;
uniform float rotateZ;
uniform float scale;

void main() {
...

Then the values are pass through console or OSC as:

translate,0,0, 10 or /translate/0,0,10 rotateX,90 or /rotateX/90 etc.

This somehow a bit more tedious allows for more flexibility because keep things open for users to build their own API or set of commands (specially used together with defines keys. My thought regarding to having unique API commands is that reduce the number of options the user can choose.

Hope this thoughts are helpful. Please feel free to challenge them I'm really interested on the use of glslViewer for realtime performance. All the best and thank you

[coderofsalvation]

Hi thanks for sharing your thoughts.

then relaying in the console command:

define,ANIMATION_00 define,ANIMATION_01

Awesome, did not know about that. Will investigate.

About your last point: I have been thinking of this for a while because is a slippery slope of request that could escalate to an entire API. Mi initial thought was more related orbital cameras. But I settle down on keep focus around shaders.

This is understable, and I do share those feelings when thinking about it. Hotreloading & hardcoding OSC-command which can be done in shaders, could open a whole other rabbithole of testing & regressionbugs. I'll close this issue and re-open this in case we have new ideas.

On Thu, May 28, 2020 at 11:56 PM Patricio Gonzalez Vivo < notifications@github.com> wrote:

Hi! I'm very excited to hear this request. Although hot-reloading geometry will take a long time to implement because of how glslViewer is architecture I will try to add it into the plan it.

About reloading shaders: switch between files is totally possible using defines flags and the #includes. I know it's not exactly what you have in mind but you could have a shader that looks something like:

if defined(ANIMATION_00)

include "animation_00.frag"

elseif defined(ANIMATION_01)

include "animation_01.frag"#else

include "empty.frag"#endif

then relaying in the console command:

define,ANIMATION_00 define,ANIMATION_01

That in OSC should look like

/define/ANIMATION_00 /define/ANIMATION_01

You could trigger totally different subshaders.

About your last point: I have been thinking of this for a while because is a slippery slope of request that could escalate to an entire API. Mi initial thought was more related orbital cameras. But I settle down on keep focus around shaders. On my code I use similar "commands" but as vector shader uniforms:

uniform vec3 translate;uniform float rotateX;uniform float rotateY;uniform float rotateZ;uniform float scale; void main() { ...

Then the values are pass through console or OSC as:

translate,0,0, 10 or /translate/0,0,10 rotateX,90 or /rotateX/90 etc.

This somehow a bit more tedious allows for more flexibility because keep things open for users to build their own API or set of commands (specially used together with defines keys. My thought regarding to having unique API commands is that reduce the number of options the user can choose.

Hope this thoughts are helpful. Please feel free to challenge them I'm really interested on the use of glslViewer for realtime performance. All the best and thank you

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/patriciogonzalezvivo/glslViewer/issues/176#issuecomment-635629744, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABL6ZBKHPDHXSZO4CTM5ZTRT3M2XANCNFSM4NNIF5PQ .

--

Léon

/COMPANY

/WEBSITE

/MOBILE

/LOCATION

/COMPANYNR.

/TAGS

van Kammen

2WA Labs & Consultancy

2wa.isvery.ninja/hello

+31 20 3699836

Holland, EU, Galaxy 12B

08124656

Creative Technologist, New Media

consultancy, Tech concept design,

driven by open source &

lots of coffee.

https://www.linkedin.com/in/leonvankammen https://github.com/coderofsalvation