Feature Request: Slidable Values! about glsl-sandbox HOT 16 OPEN

Hehe. I thought about implementing it when I saw the video. I'll have to do a proof of concept ;)

from glsl-sandbox.

There is this directly from him:

http://worrydream.com/Tangle/

Maybe it could be usable, not sure how much it would interfere with existing code highlighter.

from glsl-sandbox.

ohoh... i'm so distracted from work and tempted to implement this right now! (#'_')

from glsl-sandbox.

http://jsdo.it/zz85/5Ad2

I believe Codemirror already tokenize keywords and place them in divs. Now someone just need to place the ballons above the numbers =D

from glsl-sandbox.

here's my attempt an integration with codemirror in a glslsandbox branch.

click on a number, the the slider would appear above it.
right now it supports only position numbers right now (perhaps due to how the tokens are parsed)...
https://github.com/zz85/glsl-sandbox/compare/numberslider

i'm calling it a day, perhaps you might have a better way of integrating this :-)

from glsl-sandbox.

i fixed the parsing in glsl.js mode to take in -1.0 as a number token instead of - as an operator token and 1.0 as a number token so negative numbers are now supported...

a live link is at http://jabtunes.com/labs/graphics/glslslider/

from glsl-sandbox.

That's a great start @zz85! Couple of comments:

• After playing with the same number in a vec4() sequence several times, the comma following the number can be deleted, causing a syntax error.
• Since we're following Bret Victor's advice, the slider should recompile the shader on-the-fly and show you intermediate values and their results. This might be near-impossible for systems that are slow to compile, such as ANGLE systems. Perhaps we should time the compile stage to know for a given shader on a given system if it can happen interactively or not. This could turn into a large pile of work.
• Could there be any way to guess the range? Often GLSL values are in the range [0, 1] or even [-1, 1], but other values are relatively unbounded. Not sure how best to handle it. Maybe make it exponential, so range scales with distance. For example: intermediate_value = starting_value - 1.0 + pow(10.0, 0.02 * mouse_horizontal_offset_from_start_in_pixels);

Anyway I'm excited to see where this goes!

from glsl-sandbox.

great feedback, @emackey!

1. not sure why this happens, either events are not hooked with codemirror correctly or tokens are miscalculated :(
2. very true. i think a better solution would be to compile the current slider variable into a uniform and avoid recompilation while sliding - except that wouldn't work with constants (then again if we parse the document, we can guess whether its a constant or not)
3. awesome idea! i initially thought of using keys - CTRL for (+/- 0.001), SHIFT for (+/- 10) etc, but using the exponential scale allows it to be really usable without the use of keyboard :)

updated in git and http://jabtunes.com/labs/graphics/glslslider/

from glsl-sandbox.

Hi @zz85,

When you get a chance, pull the updates to the numberslider branch from my repo...

emackey/glsl-sandbox@jfontan:master...emackey:numberslider

I've done a few things. First I made it so you really have to click on the number to get the slider, because otherwise, values could change when just mousing around the screen. So you have to click to turn on the slider, and click again to accept the result, otherwise it will cancel out.

Next, I made it so when the slider activates, it compiles your shader with a special hidden uniform in place of the constant you clicked. As you move the slider, the hidden uniform changes values interactively, without recompiling the shader. When you accept the new value, it removes the uniform and turns it back into the new constant.

There are a couple remaining bugs I wonder if you could look at. Floating point numbers don't need to exist on both sides of the decimal point. Floats like "1." and ".5" are common in GLSL Sandbox, but they don't get properly recognized and they don't produce sliders. Also, single-digit integers also don't get recognized, although two-digit integers work fine.

Also I'm having a Ruby issue, but I sent @jfontan a separate email about that one.

Keep up the great work!

from glsl-sandbox.

Wow, that's awesome. One very minor nit though: the newly added static/js/numberslider.js doesn't end with a new-line, which will confuse some text-editors.

from glsl-sandbox.

@emackey you did the compiled uniform! very cool! :D

i briefly tried the new behavior. i think that should be fine, i probably need to play more esp. with keyboard combinations to see if behavior is optimal.

i'm still fiddling with the regex and token parsing to get that working. its a little nasty not having them to work as intended >.<

from glsl-sandbox.

patched the single integer, and the 'shorthand' floats.

added bubble canceling behavior on keypress too.

from glsl-sandbox.

@emackey
the new slider parameters seems okay. perhaps i could make the slider longer too.

however, seems like number parsing is still causing a little frustrations

1. (1.0 /30.0 ) causes /30.0 to be tokenized instead of 30.0
2. vec3(1.2, 3.2, 32.3) changing the value of 1.2 can dislodge after sometime..

will have to look into it when i get a little more time :(

from glsl-sandbox.

spent some time today trying to tweak the number parsing. trying to modify the way the tokens are parsed in codemirror has been too painful, and i've attempted a new method. basically, from a click, search forward and backwards from the cursor to find where a potential number is. this would hopefully support hard to parse numbers, like

float a = 1.0;
float b = 1.;
float c = .1;
float d =1.;
float e =.1;
float f = 32.34/43.2;
float g = (43.34/43.43);

somehow i might have introduce some strange bugs - it requires double clicks at times to activate the slider :<

its feels really close to a really usable and useful feature but at the same time i'm almost on the verge of giving up. maybe an extra eye could help...

zz85/glsl-sandbox@eeb6cf2...7b5b2bf

from glsl-sandbox.

My home machine is having HD problems, so it will be a few days before I can look at this again, but it would be great to get it working someday.

from glsl-sandbox.

sure... perhaps its a good time to get a solid state harddisk too :)

from glsl-sandbox.