ISF editor ShaderToy import does nothing

[MacroMachines]

I am currently getting very deep in making some rather large projects realized partially through ISF, increadible little clever format. I am learning the ShaderToy API and hoping to bring together some integration between ISF/ ST and maybe shaderfrog. one of the features I was most excited to try was the shadertoy import, but it looks like maybe the recent updates in their site and API have broken the import, as it appears to do nothing after many tries. GLSLsandbox still works, but we all know shadertoy is where its at.

[mrRay]

thanks for reporting this, as you surmised a number of changes in shadertoy's backend obviated the conversion code in the ISF editor. i think i've resolved these issues with commit 54f8cceb2ea6b198966dd09347be777f36e4cdb2- please let me know if you have any additional problems with the editor.

some shaders still don't convert cleanly and need minor adjustment for a variety of reasons- sometimes it's a weird #define in the source, sometimes it's a gl_FragColor.a that's being set to 0 (invisible in the ISF editor), sometimes it's a duplicate function used in multiple passes, sometimes the shader simply needs to be run in a newer version of GL (everything here is run in GL 2.1/GLSL 1.2, as both CoreImage and Quartz Composer are incompatible with newer GL environments). i've got a c++ rewrite of the ISF lib in another repos that works in GL 3/4/ES, so at the very least i should be able to make some more headway on that last point...

"I am learning the ShaderToy API and hoping to bring together some integration between ISF/ ST and maybe shaderfrog"

what sort of integration did you have in mind?

[MacroMachines]

oops! i guess i had thought you also owned the repo for the JS implimentation, and had been posting on there, heres a link to the ideas ive been posting : https://github.com/msfeldstein/interactive-shader-format-js/issues/14

[MacroMachines]

Might be worth splitting off the ISF related git into its own comprehensive repo, I had been forming that ideas for roadmap in the isf-js git because it looked more specific.
Should i keep commenting there or somehow copy over to here?
or maybe i could help set up a new repo collecting the relevent implimentations along with my ideas for v3?
@mrRay do you have any other current plans/roadmap for ISF?

[MacroMachines]

I just downloaded the current build from the site, It says its from sep 2016, v2.9.3, so I assume it doesn't include your new update to importing shadertoy? Is there a more recent build I could download?
You also mentioned another C++ repo for a newer editor? could I have a link for that?

off topic / road map____ I have a project for kineticcreations.com programming ISF resources to be used in Millumin, large scale projection mapped stage work, and I plan to be working on this heavily through 2018. In my R&D testing through the past few months, I had found some worthy considerations mentioned in the roadmap thread I linked in my last post. I would like to begin making progress / testing my ideas for growth of the ISF format. Currently I am working on prototyping through JS / lua as it is most convenient.

I was just thinking JS might be a good platform for the growth, as it is rather ubiquitous, web, and cross platform. And since most of ISF is parsing into a set of controls and glsl shaders, using a scripting language vs compiling native C++ code for specific implementations might be the best route.. as it is mostly happening briefly at the initial compiling stage and likely to have a marginal impact on performance during the realtime render (I think, though maybe I am wrong? I suppose it depends on the render engine).. but expanding to cross platform and growing the community seems to me to be more pros than cons.

If you have a chance check out the linked thread of v3 ideas, and maybe we can commuicate directly or if there is a forum / thread somewhere, or a slack that would be good, I would like to hear your thoughts https://github.com/msfeldstein/interactive-shader-format-js/issues/14

[mrRay]

belated happy holidays!

"Might be worth splitting off the ISF related git into its own comprehensive repo,"

doing so would require submodules and dependencies to other frameworks in this repository. i appreciate your suggestion, but i'm not going to do this.

"Should i keep commenting there or somehow copy over to here?" / "Do you happen to have a slack or is there another way i could contact you to expedite this collab / diacuss details?"

sure- send me an email and we can figure it out from there, i'm ray at vidvox dot net.

"or maybe i could help set up a new repo collecting the relevent implimentations along with my ideas for v3?"

sure, i'd love to hear your ideas for v3 of the spec. i don't know what you have in mind for a repo or what you plan on collecting, so if you'd like to coordinate briefly with me on that so we can avoid duplicating efforts that would probably be a good idea.

"do you have any other current plans/roadmap for ISF?"

yes, lots- while we open-source everything when it's complete, nearly all development on this project happens privately.

"Is there a more recent build I could download?"

sure, you could give this a shot- we've been distributing it with vdmx for a few months now, i just haven't updated the download URLs:

http://vidvox.net/rays_oddsnends/ISF%20Editor_2.9.6.zip

"what is the 'IDENTITY" property?"

the IDENTITY property was originally intended to express the "identity" of a given parameter- the value at which the parameter has no discernible effect on the output. for example, if i were writing a "zoom" shader, i could specify that the IDENTITY of the "zoom" parameter is 1.0 (no zoom). i never really did much with it and nobody else did, either; the attribute isn't even relevant in many filters which are incapable of expressing an "identity" value. this attribute could probably be removed from the spec without causing any problems.

"caveat fix: i think it would be good to support native texture/2D/rect, it is the one place i always find myself addressing loads of errors in translating shaders, and I dont really understand the crux of why this is an issue. IMG_PIXEL() is cool, but maybe with a mix of my afformentioned regex code i made to search for native uniforms, the vast number of shaders out there could be instantly compatible. Is there anything i might be overlooking with this?"

yes, but it's easy to overlook if you haven't run into it before: you can't access a 2D texture with a Rect texture call in a shader (if you try to call texture2D() on a Sampler2DRect the program won't even compile), and you can't convert a texture from 2d to RECT within the shader. you propose supporting the "native" texture calls- but if you write an ISF that has "native" rect calls then everyone who uses that shader is required to submit that texture as a rectangular texture or the shader won't work (and vice versa- if you write an ISF that has 2d texture calls then everyone who uses that shader is required to submit textures to it as 2d textures or it won't work). in addition to being less compatible, this would require the ISF to express to the dev implementing it what kind of textures it requires for every input, and it also would also require the dev to convert their textures to those formats before passing them to the ISF.

...or you could write an ISF that uses IMG_PIXEL and IMG_NORM_PIXEL, which gives the backend an opportunity to insert the appropriate native calls when the shader is compiled (2d or Rect, depending on the nature of the supplied textures for those inputs and the platform/environment the shader is running in) so it will work with any kind of texture you throw at it.

[MacroMachines]

Good work! The new version of the shadertoy import seems to work pretty well. I did find one thing I can't quite figure out a good solution to yet, calls to texelFetch and textureSize. I am trying out making some different things with #define or functions as a patch, what version of GLSL is in the ISF editor?.

I also notice a couple issues with the spacing of the passes/inputs frame on the right, if I edit a few shaders things start to overlap and I can't access the box, Ill make a separate issue and send a picture.