glsl shader problem

[neoz]

Hey there!
Got a few shaders that are very important for me, but they're not running in Magic...
Here's on of them:
http://glslsandbox.com/e#30173.1

[Magic]

That one seems to work fine for me. What version of Magic are you using?

[artnik]

I also noticed a number of ISF files that run fine on the website http://www.interactiveshaderformat.com/ on my hardware also don't run in Magic, or exhibit strange behaviour. GreatBallsofFire (http://www.interactiveshaderformat.com/sketches/822) and BlackCherryCosmos (http://www.interactiveshaderformat.com/sketches/824) are two recent examples that posted this week.

[Sadler]

BlackCherryCosmos works for me though I have to turn the dials down to almost zero. Some other ISFs don't work though. Would it be possible to report why these fail in the compiler errors file?

[Magic]

There aren't any compile errors actually. All the shaders compile fine in Magic. And somewhat interestingly, if I get the original shaders from GLSL Sandbox (http://glslsandbox.com/e#30176.0 and http://glslsandbox.com/e#28545.0), and I load them into Magic via the GLSLShader module, they also work fine.

As Sadler noticed, I think the issue might have to do with how certain parameter values are handled in the ISF web site versus in Magic. There may be some small things which aren't fully compatible. It may also have to do with the so-called "automatic conversion" to ISF format (which I think comes from the ISF editor you can use on a Mac: http://vdmx.vidvox.net/tutorials/using-the-isf-editor). I'll have a closer look and report back.

[artnik]

@Sadler When you say it works, is it scrolling into the screen (Z) or across it (XY)?

[Sadler]

You're right in that the z-movement isn't there which I neglected to mention in my post.

[neoz]

Eric, v1.64.2 x32
There's just a black screen with inactivated all parametrs incl speed..

[Magic]

I also noticed a number of ISF files that run fine on the website http://www.interactiveshaderformat.com/ on my hardware also don't run in Magic, or exhibit strange behaviour. GreatBallsofFire (http://www.interactiveshaderformat.com/sketches/822) and BlackCherryCosmos (http://www.interactiveshaderformat.com/sketches/824) are two recent examples that posted this week.

Ok, I figured out the problem, and unfortunately there isn't a one-size-fits-all solution. It has to do with the way X/Y coordinates are handled in ISF shaders. I guess it's up to you guys to tell me what you prefer. It's a bit of a technical explanation so bear with me.

In most of the original ISF shaders that were created by Vidvox, X/Y coordinates are treated as pixels. So, the shader expects parameters that look like (1280, 720) for example. I've treated this as the standard, and underneath the hood, Magic supports things this way. It scales the values up so that when you enter a value like .5 or 1 for a module parameter, it actually gets multiplied internally by the image size. Thus, for an image width of 1280, .5 becomes 640, 1 becomes 1280, etc. Scaling the values allows Magic to retain its convention of having most parameters be in the [0, 1] range, which works best with audio/MIDI linking and with modifiers. Also, and perhaps more importantly, it's resolution-independent, so (.5, .5) will always be the same point in space regardless of the image size.

But in the ISF shaders posted above (and not created by Vidvox), X/Y coordinates are treated as points in 3D space. The shader expects them to be in a range of [0, 1] or [-1, 1] or something like that. The problem is that there's no way for Magic to know *not* to scale the values, so it does, and they become way out of range. I would have actually preferred it if Vidvox's shaders worked this way, but they didn't.

I could solve the problem by removing Magic's internal scaling, but then most X/Y ISF module parameters would have to be specified in image dimensions, so you'd have to enter large values (640 or 360 or whatever). This would make audio/MIDI linking and modifiers more complicated to use, and it's inconsistent with the way all non-ISF Magic modules work. Also, it would break everyone's current projects which use ISF shaders.

Another way to solve the problem would be to make *very* minor edits to the shaders to accept image-scaled values, but that's up to every individual author and not something under my control. Unfortunately, the ISF standard doesn't seem to specify how this should be handled when writing/converting shaders.

A third solution would be for me to add a custom ISF parameter (only supported by Magic) that allows you to mark a shader as scaled or not scaled, but then you'd have to know to do that, which would require analyzing the shader to see how it works.

I hope that all makes sense. So, let me know what you think.

[Magic]

Eric, v1.64.2 x32
There's just a black screen with inactivated all parametrs incl speed..

Hmm, that's strange. It's working on my computers, so I'm not exactly sure what's going on. What kind of graphics card do you have?

Also, you can see if there were any shader errors by going to C:\Users\Public (Windows) or /Users/Shared (OS X) and opening the text file called "Magic_GLSL_compile_errors.txt". If that file exists, and it has errors related to the shader you're trying to load, can you post the results here?

[artnik]

Thank-you for taking the time to look into this Eric. Ah, when standards aren't actually, eh?

I guess it's a little inelegant, but the third option is probably the one that would satisfy the largest number of users with the minimum amount of user effort.

Also, it's the only option that gives a user the chance of correcting the issue without creating additional problems for other users, and without having to modify the code for each individual shader.

As long as the manual section on ISF shader support had a paragraph to identify the issue, and suggested it's a "Maybe it works, maybe it doesn't" thing to try when an ISF shader is not behaving as you expect, then a non-coding saavy user wouldn't have to analyze the shader, just give it a go.

2¢.

[Magic]

I guess it's a little inelegant, but the third option is probably the one that would satisfy the largest number of users with the minimum amount of user effort.

Thanks, I agree. I'll do a little more thinking though; maybe I can come up with an even better solution. If not, I'll try contacting Vidvox and see what they think.

As long as the manual section on ISF shader support had a paragraph to identify the issue, and suggested it's a "Maybe it works, maybe it doesn't" thing to try when an ISF shader is not behaving as you expect, then a non-coding saavy user wouldn't have to analyze the shader, just give it a go.

Yup no problem .

[neoz]

Eric, thanks a lot for the hint about "Magic_GLSL_compile_errors.txt"
Found a line:

ERROR: 0:18: error(#132) Syntax error: "buffer" parse error
ERROR: error(#273) 1 compilation errors. No code generated

Will gonna go to meditate with coders...

[Magic]

Ah, thanks. I know what the problem is . Whoever wrote that shader shouldn't have used the word "buffer", because it is a reserved GLSL keyword and can't be the name of a variable.

If you just do a Find/Replace and change "buffer" to something else, like "myBuffer", it should work. Try it and let me know.

I'll also see if there are any improvements I can make to handle this kind of situation.