Gotta make a new Shading Language for College Project - Opinions?

I’m planning to write a transpiler for a new shading language as a final year college project. This transpiler will read the SESL (what I call until I come up with a good name) code and produce valid GLSL or GLSL ES code. You can find the current thoughts here:

A glimpse of the code is as follows:


// Import shader functions from libraries
import sesl.phong.*;
import sesl.lights.*;

// Declare the VertexShader called as MyShader. This will be
// compiled to the output file MyShader.vert.glsl
shader vert MyShader
{
    uniform mat4 mv;
    uniform mat4 mvp;

    in vec3 position;

    // Pass variables are similar to inputs, but they are automatically
    // passed to the next shader stage.
    pass vec3 normal;
    pass Material material;
    pass PointLight pointLight;

    // Additional outputs can be added here
    out vec3 vertex;

    // The main shader function. Note that we avoid having a gl_ variables.
    // The return value of the main function will be automatically assigned
    // to gl_Position in GLSL target.
    vec4 main()
    {
        vert = vec3(mv * vec4(position, 1.0));
        return mvp * vec4(position, 1.0);
    }
}

// Declare the FragmentShader called as MyShader. This will be
// compiled to the output file MyShader.frag.glsl
shader frag MyShader
{
    // out variables of vertex shader as well as the pass variables
    // are in variables in the fragment shader here.
    in vec3 vertex;
    in vec3 normal;

    in Material material;
    in PointLight pointLight;

    // The main shader function. Older GLSL has gl_FragColor and in modern
    // GLSL, we have to declare an output of vec4 and assign to that. In
    // SESL, the shader simply returns the fragment color, which will be
    // handled automatically.
    vec4 main()
    {
        // Call the phong function from the sesl.phong package.
        return phong(pointLight, material, vertex, normal);
    }
}

You can extend shaders to create new ones!


import sesl.Math;
import sesl.Color;

shader frag MyNewShader extends MyShader {
    vec4 main() {
        return Math.mix(Color.BLUE, super.main(), 0.5);
    }
}

This is an interesting project to be done for a final year project. I’d like to know your opinions guys.

Object-oriented shaders, yeah!

But why have the frag/vert after the shader keyword? Looks more natural to write “vert shader” and “frag shader”.

No… you should first sell us your idea and list the benefits…

@65K Did you read the link?

  • Smooths over differences between GLSL, GLSL ES and GLSL for WebGL.
  • High level features allowing for better code reuse like inheritance and imports.
  • Uses return values instead of arbitrary fields like GLSL code does.

That’s what I gleaned from the link. Seems worthwhile enough to me.

Because I read the link I asked the question…

What I get is

  • a more complicated development process
  • another leaky abstraction

That was because I thought about the parser, which I plan to make in recursive descent manner. Having shader keyword in the start helps in keeping the code clean. Like we only care about the type only when we know that it is a shader.

I understand introducing a new phase in the development process is a bit of effort, but in the end it is worth of it. Even complex engines have asset pipelines, and shaders are assets too.

I don’t understand why call it a leaky abstraction. It doesn’t leak any memory like CG (known to leak memory when binding a texture with the shader in D3D), SESL is a transpiler that works on files and produces GLSL files. You use normal OpenGL functions, there won’t be any runtime specific to SESL.

Any somewhat modern build system is going to automate away the compilation step, no pain there. Besides abstractions are the root of productivity.

But, having some experience with parsers, surely when it reads ‘frag’ or ‘vert’ it automatically expects ‘shader’ and the shader body? That shouldn’t be too hard on the code, in my opinion.

That’s not what leaky means in this context. Leaky abstractions are the result of papering over the cracks where things don’t quite meet up. D3D and OpenGL aren’t quite exactly the same, so you’ll bodge over the top of the differences creating something that’s probably not optimal for one or both backends.

Cas :slight_smile:

I never meant that I’m going to abstract HLSL too, it is only for GLSL. I mentioned D3D when mentioning that CG had issues when it has custom runtime functions and causing memory leaks. I’m only interested in getting GLSL and GLSL ES outputs.