recognize iTime from shadertoy shaders

[joem]

I've been playing around with glslViewer, and I've notices that all the shadertoy shaders use iTime, but glslViewer only recognizes iGlobalTime. I'm not sure if there's a difference between the two, but I've been putting a simple #define iTime iGlobalTime at the beginning of those shadertoy ones, and they work fine then. Is there any chance of getting glslViewer to permanently recognize iTime?

I should note this is on MacOS and I installed it via homebrew.

[patriciogonzalezvivo]

Hi! Yes, ShaderToy's specs change more often than not. Here is the line where the mapping to iGlobalTime happen https://github.com/patriciogonzalezvivo/glslViewer/blob/master/src/gl/shader.cpp#L167 you could add another one for iTime for now if you want.

Moving forward, because:

• the always changing specs of ShaderToy
• the new features like multiple buffers or audio buffers that are not yet implemented on glslViewer
• suport of WebGL 2.0 GLSL that introduce new texture sampling functions like texture() with/without LOD and others
• the necessary wrappers for doing WebVR compatible shader and more

... I think eventually most of the shader on ShaderToy need to be adapted on some way or another and doing this conversion with hidden #defines is not a good practice or part of the responsibility of glslViewer. For that I think we should drop the conversion.

To solve that I also have been working on a Python wrapper that will be use by glslLoader (the python script that downloads and runs shaders from the web). I feel this job is more suitable for glslLoader and can be easily address by a language more focused on natural language like Python.

The intention behind glslViewer is more like a flexible low level swiss army knife to run plain GLSL shaders on Raspberry Pi, Linux and MacOS devices directly from the command line.

Wondering what's the opinion on this of @doug-moen and @yvan-sraka ??

[patriciogonzalezvivo]

Related https://github.com/patriciogonzalezvivo/glslViewer/issues/93

[doug-moen]

Here's my opinion. I use glslViewer as a component of my own project, Curv. It's a 3D modelling tool that uses signed distance functions and sphere tracing. When I started on Curv, I decided to use an "industry standard format" for my fragment shaders, and it looked like ShaderToy.com was a popular standard to use. As a result, one feature of Curv is that you can export your model as a ShaderToy.com shader.

There are a number of active projects on github that accept ShaderToy.com shaders as input, and then do interesting things with them. My project outputs them. So, supporting ShaderToy.com shaders is still a good idea in general.

"iGlobalTime" no longer works on ShaderToy.com, so that feature of my software is broken. To fix that, I would need to fix glslViewer to accept "iTime".

The other thing I could do is drop support for ShaderToy.com compatibility from my project. I might do the latter because my project is evolving. I need to start using 3D textures and compute shaders. Once I do this, I feel that I will no longer be able to be compatible with the ecosystem of tools that understand Shadertoy fragment shaders. Also, I don't know if glslViewer can or should be extended to support GLSL compute shaders, since Raspberry PI doesn't support compute shaders, and macOS doesn't support OpenGL 4.3.

I am still attached to the idea of a standard, mostly text based interchange format for procedural 3D models. Something that could contain meshes, textures and an arbitrary collection of GLSL shaders, including compute shaders. Ideally, this format already exists, and there are multiple open source projects for reading, writing and viewing these models. Any ideas?