gl-transitions icon indicating copy to clipboard operation
gl-transitions copied to clipboard

how to express constraint on parameters?

Open gre opened this issue 8 years ago • 1 comments

just defining default parameter values is limited in some aspects.

Firstly, it makes it hard to constraint the values: (which includes validating them)

  • in bunch of parameters, we would like to express the "min" and "max" bound. because usually a transition goes crazy if out of expected bound. (like it's no longer valid in the fact it no longer render the images from and to respectively on 0.0 and 1.0 bounds.)
  • in some cases, we have more implicit constraints for instance in colorphase.glsl we want to express that fromStep < toStep.

Secondly, and more wider, it makes it hard to implement a proper UI:

  • what input to use? at least, if we have a min/max being defined, we can choose a proper stepping based on that, we can also chose int vs float based on the type. However, it's not so easy to infer what component it should be. A range, a input type=number, something else?
  • one example is the vec2 and the vec4. Usually we use vec2 for position and vec4 for colors, but it would be better if it was clearly defined. Especially for vec2, it's very not clear if it's a position OR a vector. Identifying different usecases and providing them with the shader would allow to have a decent UI (like imagine we could have a "position picker" vs a "vector" – well, a vector still needs to have an origin, we can use the center for now,.. but this can be extended)
  • in example colorphase.glsl, one interesting UI for this is to have one range slider per component ( like to define the from and to steps: screen shot 2017-05-27 at 14 17 33 ) – which sounds very tricky to express. even tho, the fact one variable is <–constrained with the other makes it "solvable".

So yeah, tricky topics but this is worth thoughts to make better UIs that can be automatically inferred and offers to final users a way to customize a transition nicely.

One important aspect to me is that that way we describe the constraints & the "categories" of parameters should be independent from the actual implementation. It's also unclear where this should live... I wish it would be part of the shader as continuation to that // = 1.0 format but this might be a bit too verbose. another way is to make a foo.json next to foo.glsl but this makes it no longer one file to commit and cannot be unified with the shader source...


So basically i'm looking for a concise/extensible/generic descriptive format that can express constraints between numeric variables (on numbers/vectors/..). Does that even exists for some libs?

gre avatar May 27 '17 12:05 gre

more advanced topic is also the textures. there are different categories of texture ("luma"s kind of texture, the "displacement" texture, etc..)

gre avatar May 27 '17 12:05 gre