Default fragment shader is always red

[mgold]

I'm guessing the default fragment shader should respect the material properties defined in the record data, so that the user changes that and never worries about glsl. How exactly we want to do that is a bit of an open question.

At the moment I see you are using strings. Maybe we should use elm-webgl's shader type?

[TheSeamau5]

Yeah, so the goal would be to have a "good enough" basic shader with lighting.

About the strings... I don't know how that would be possible without exposing implementation details to the user.

First, in order to use uniforms in GLSL, you have to declare them... I don't want to have to do that all the time as a user. All the uniforms should just be available by calling them without having to declare them. Same goes for the attributes.

Second, all that precision mediump float business... I have yet to put all the necessary if-defs, but in, general, I think that useless boilerplate should be abstracted away.

Lastly, since we're just concatenating strings, I can sneak in a little library to make things easier to work with. If we bump into very commonly used functions in shader programming, we can just add them to the library and the user can just call them without having to define them manually. It makes things easier.

Obviously, since everything is a trade-off, using strings means that there is a chance the shader crashes at run-time... and I hate run-time errors. But I don't see any other way unless you could somehow append two webgl blocks and that somehow made sense....

[mgold]

Hmm. I see, so we create the shaders at run-time. That could be really neat actually. I was thinking we'd have a standard shader that read the record data, but instead, maybe we don't have standard shaders in the records. They're just made on-the-fly by the render function based on the data. That way they're completely abstracted.

[TheSeamau5]

Yup, the shader is just a string you pass to a couple of Javascript functions that then take care of actually sending the program to the GPU. So, even the GLSL block is "created at run-time". The big difference is that the GLSL block is statically analyzed for uniforms, attributes, and varyings and their types in GLSL inform the type in Elm. This allows for type safety. But in the end, that thing is just a string. So, what I do is just use the string part (which you can do by using unsafeShader instead of the GLSL block). That allows me to concatenate strings in all sorts of ways.

I was thinking about making the shaders from record data, but I can't figure out how that could work. Shaders have functions, and for-loops, and if statements... I wonder how you could write interesting shaders just from record data.

The idea now is that the data just changes the uniforms, not the shaders themselves.

[TheSeamau5]

In the latest commits I've added my first attempt at a Gouraud shader. You can see it if you open test.elm. I don't know if it does what it's supposed to do yet, but for the moment I don't dislike the result.