Slidable surface, and jsdiff with parent

[emackey]

This pull request contains two large features:

1. There's a new "diff" button for effects that have parent effects. It runs @cemerick's awesome jsdifflib and shows the changes between parent and child (or between any two effects if you hand-edit the URL).

2. This pull request also includes my "slidable surface" that allows users to explore things like fractals, by clicking 'hide code' and then using the mouse to drag (left) and zoom (right) the effect. I wrote this a while ago and I've done a lot of testing on different systems with different types of gfx cards, so I'm confident in it now. This new feature doesn't affect any of the current gallery of effects, you have to add a new line of code ("varying vec2 surfacePosition;") to a new effect to get new behavior. Adding that line to any existing effect, and swapping in the surfacePosition in place of the typical "vec2 position" that gets defined in main() is fairly straightforward, and will allow effects authors to turn on the mouse controls easily.

Let me know what you think! Thanks.

[jfontan]

I think I'll have tie this afternoon to check this pull request and other things still pending.

Sorry for the delay, these months were a bit mad here.

Thanks!

[jfontan]

The diff addition is great! I cannot see the zooming but I suppose it is because there are no effect taking advantage of it.

The changes are live now, thanks!

[emackey]

That was fast, thanks! I'll post some zooming examples soon. And you'll be able to diff them once they appear :)

[emackey]

First demo posted! More to come.

http://glsl.heroku.com/e#1872.0

[mrdoob]

So effects don't fill up the browser window anymore? All the effects on the site now show in a small frame and the screenshots have black bars too :(

Could we revert this? I'm giving a presentation in 3 hours to a pretty big audience and would love to show some effects at its full size :S

[emackey]

The black bar stuff is a horrible bug, it's not supposed to do that at all. As you can see from the thumbnails, not everyone's machine displays the bug, and obviously none of my machines (Win7, WinXP, Android, all on nVidia hardware) display the bug at all, so I can't reproduce it. I'd love to know the root cause of it, but if you have a presentation in 3 hours, we should ask @jfontan to push an older version to heroku master for now until this is resolved.

[jfontan]

I've rolled back to a previous version and seems to fix the problem.
We can look at it after the presentation.

On Mon, Mar 12, 2012 at 8:37 PM, Ed Mackey
reply@reply.github.com
wrote:

The black bar stuff is a horrible bug, it's not supposed to do that at all.  As you can see from the thumbnails, not everyone's machine displays the bug, and obviously none of my machines (Win7, WinXP, Android, all on nVidia hardware) display the bug at all, so I can't reproduce it.  I'd love to know the root cause of it, but if you have a presentation in 3 hours, we should ask @jfontan to push an older version to heroku master for now until this is resolved.

---

Reply to this email directly or view it on GitHub:
#7 (comment)

Javier Fontán Muiños
Project Engineer
OpenNebula - The Open Source Toolkit for Data Center Virtualization
www.OpenNebula.org | jfontan@opennebula.org | @OpenNebula

[zz85]

revert verified on heroku. (might need to clear cache)

at least that terrain demo with borders didn't look too bad on the webgl hangout.

have fun @mrdoob for the presentation! :)

[mrdoob]

Thanks guys!

@zz85 yeah, I first noticed the frame thing while in the webgl hangout. But somehow I assumed it was something to do with the screen sharing software.

This is the presentation/panel by the way:
http://schedule.sxsw.com/2012/events/event_IAP10450

The room is a bit intimidating. I wonder if WebGL will be able to fill up these 1000 chairs ;)

[zz85]

[Missing Picture]
Ricardo Cabello
Title: Mr.
Company: Mr.doob

i always hear sxsw's the big thing. perhaps the room might be packed with people who wants to see your face!

:D

@emackey i did a reset to initial commit 5decd8f. works well on windows 7. faulty on mac :( could be driver issue?
surface parameters seems fine.

[emackey]

So I have a theory. This commit introduced a second vertex attribute, and I think the systems that suffer this bug have got my new attribute mixed up with the original. The original vertex attribute is called "position" and is the normal 2D pattern of a pair of counter-clockwise triangles filling the [-1.0, 1.0] clip space (the whole screen). The new vertex attribute is "surfacePosAttrib" and its initial values put the Y range at [-0.5, 0.5]. This attribute gets fed into a varying vec2 that can be used by the fragment shader.

So in theory, if a system like the Mac were to get the two confused, and use surfacePosAttrib as the vertex position itself, you would see the shader render into a half-height window. Further, if you click 'hide code' and then drag the mouse around with the left button down, that whole window should slide around, potentially sliding out of view entirely. That's not the intended behavior, but it's what I imagine would happen if the attributes were swapped on a particular system.

So next question: Why would some systems get the attributes confused, if that is the root cause? I declare them in reverse order, but, I look them up by name, and Win7 and Android are fine with that.

@zz85 since you can reproduce this, can you try something for me? Look at the top of the script tag named surfaceVertexShader, and replace these three lines:

attribute vec3 position;
attribute vec2 surfacePosAttrib;
varying vec2 surfacePosition;

with something swapped around like this:

attribute vec2 surfacePosAttrib;
attribute vec3 position;
varying vec2 surfacePosition;

Does that fix anything?

Thanks everyone, and @mrdoob I hope the presentation was a huge success!

[zz85]

nope, doesn't seems like that helped.

perhaps create a simple use case in fiddle or webglplayground where we can trace the bug?

[emackey]

A friend of mine let me use his Mac for a while, so I was finally able to see this bug firsthand, as opposed to watching it on YouTube. It's very strange, it looks like the values for surfacePosAttrib are overwriting the values for position. On the Mac, the vertex shader sees incoming values as if position.xy = surfacePosAttrib, but on Windows/Android/Linux, the attributes get their values assigned separately (correctly).

None of my smaller test cases have any trouble with attribute buffer assignments on the Mac.

One clue can be found near the end of function compile() where there are some lines like this:

surface.positionAttribute = gl.getAttribLocation(currentProgram, "surfacePosAttrib");
...
vertexPosition = gl.getAttribLocation(currentProgram, "position");

On Win7, I get values I expect, namely surface.positionAttribute === 1 and vertexPosition === 0, reflecting the order they appear in the vertex shader. On my friend's Mac I saw different values here (I think they were swapped), and I tried swapping some lines of code around but the values didn't change. I didn't try hard-coding the values to the expected results, I'll try that next time.

Perhaps I'm abusing some part of the API, and the other platforms are being lenient with me?

I tried several code changes while I was in front of the Mac, and the only one of those that caused correct "position" values to flow into the vertex shader was to comment out surfacePosAttrib from the shader (with no JavaScript changes BTW). Of course this broke the surface but at least the position values went to the corners of the screen where they're supposed to be.

I'll keep hacking intermittently whenever I have access to a Mac. I'd love to hear any more suggestions you guys have!

[emackey]

I think I understand! Since the Mac decided to assign different vertex attribute IDs, we can no longer assume that "attribute vec3 position;" is the same ID (the same gl.getAttribLocation()) in both of our vertex shaders (one is for rendering the user's fragment to a texture, the other is for rendering that texture to screen).

Thus, the first vertex shader renders the user's fragment to the full-size texturemap correctly, but, the second vertex shader gets the wrong attribute buffer and only renders part of that texture to the screen. This would explain exactly what I saw on the Mac.

@zz85 I pushed a fix to master on my branch, can you test? Obviously it works fine on Win7 but I won't have access to a Mac again until tomorrow.

Basically the change is that I call getAttribLocation separately, and store separate locations for "position" in the two different vertex shaders. So the Mac can feel free to rearrange the IDs to its GPU's content. I hope it works!

[zz85]

uhoh

[emackey]

My fix had a copy-and-paste error. Try again...

[zz85]

doing a quick check before heading to sleep. looks like it works :)

[emackey]

Awesome, thanks! Just saw it work on a Mac here too. I'll send a new pull request.