Geometry shader

[Mrowqa]

Hi!

Did you, Laurent, think about add support for geometry shader? I wanted to write dynamic shadows* in GLSL, but I realised that SFML doesn't support geometry shaders. Of course, I can compute it on CPU, but I'd like to learn GLSL and write something cool. Actually my only solution is use OpenGL to load shaders.

* of course there's much more situations, where it'd be helpful; I only wrote example from my life

Regards,
Mrowqa

[Groogy]

It has already been up and suggested once. (By moa) and the answer was no, the practical applications was too few according to Laurent if I remember correctly.

Though doing shadows/lighting in 2D can like you said be done on the CPU and I think it's more preferable as you can cache the result. The only time you need to recalculate is when something changes. While with a geometry shader you would have to recalculate every light every frame.

[cpolymeris]

[...] and the answer was no, the practical applications was too few according to Laurent if I remember correctly.

I don't know much about shaders, but I'd think the implementation would be similar to that of fragment and vertex shaders. If anything, IMO, it should be added for consistency. It feels arbitrary that some shaders are supported and others not.

Of course, I also have selfish reasons: I was thinking of dynamically modifying my map projection (plate carrée to something old looking like 2-point equidistant) using shaders, and while it's possible with vertex shaders, geometry shaders would be more efficient, I believe, because I wouldn't have to feed that many vertices to the pipeline to begin with.

[Laurent]

I would have to change the API:
- I already have two loadFromXxx overloads to handle combinations of fragment/vertex shaders, supporting combinations of 3 would be impossible (or at least bloated) with this approach
- Sometimes vertex and fragment shaders are supported but not geometry shaders

So I would most likely have to change the whole design, put each shader type into its own class.

[Groogy]

If you are interested in a possible design I have implemented something I kind of like that also extends GLSL with some more functionality. Though I guess it would perhaps change waaaay too much but might be interesting for SFML 3.0 or something

Shader file example:
https://github.com/Groogy/Tyr/blob/master/dist/resources/shaders/geometry.shader

Shader source:
https://github.com/Groogy/Tyr/blob/master/Tyr/include/Tyr/Shader.hpp
https://github.com/Groogy/Tyr/blob/master/Tyr/source/Shader.cpp

The point of it was to add custom preprocessor commands(like include) but it kind of grew and now I have added support for stuff that HLSL effect files has. I got kind of annoyed that I had to have different files for the same shader chain, the case where I have same vertex shader for several shaders are never for me and if it would ever occur I could just use the include preproccessor command that I added.

The benefit, the rendering pipeline is fully programmable from the shader,  not just the specific shader stages.

[Mrowqa]

- I already have two loadFromXxx overloads to handle combinations of fragment/vertex shaders, supporting combinations of 3 would be impossible (or at least bloated) with this approach

It could be done like sf::RenderStates. You can keep method for one type of shader and write second method for all three types - if you don't want one of types you can simply pass empty string/stream.

- Sometimes vertex and fragment shaders are supported but not geometry shaders

Clean and easy:

static bool isAvailable (Type shaderType);

So I would most likely have to change the whole design, put each shader type into its own class.

No, you don't have to. Just use two previous ideas. If one of shader's type won't be supported - you simply fail loadFromXXX method - programmer should check which shaders are available before using them.

It's not difficult, is it? It won't limite functionality. On the contrary, it will expand library's possibilities. So?

[Laurent]

You can open a task on the tracker if you want

[Mrowqa]

If someone needs this feature, you can find code here: https://github.com/Mrowqa/SFML/commit/321c806eae6a5bb412e127732c7b0955fa57b3ae
I've implemented it according to my previous idea and corrected the documentation What do you, Laurent, think about it?

[Laurent]

If you can pass an empty string to skip one of the shaders, what's the purpose of the overload that loads one shader?

[Mrowqa]

I didn't think about it - I simply keep it. You're right, it doesn't make sense. I'll delete them then and update pull request

[Hanmac]

i would like to stay with

loadFromFile(const std::string& filename, Type type);

so it could be easly addable if there are other shader types in the future

like ogre3d trunk has

                GPT_DOMAIN_PROGRAM,
                GPT_HULL_PROGRAM,
                GPT_COMPUTE_PROGRAM

i dont know that they do, but if they are usefull for sfml too, than its good if the api is easier to extend

[Nexus]

i would like to stay with

loadFromFile(const std::string& filename, Type type);

But then it's not possible to have a program object (sf::Shader) consisting of multiple shader objects (vertex, geometry, fragment shader).

A possible API (for SFML 3) would consist of two separate classes sf::ShaderProgram and sf::Shader, so you could have more control: Load only the shaders you need, reuse shaders in different programs without resource duplication, ...

[Hanmac]

you can not? i thought that is what sf::Shader is for that you can use an vertex and fragment program together ... or did i get it wrong?

[Nexus]

No, you're right. But only with the function signature you suggested, multiple shader stages are not possible. That's why you need an overload that takes 3 filenames (at least if you stay close to the current API).

[Hanmac]

huch ok you are right

this is a part of the code i currently use in my binding

VALUE _loadFile(int argc,VALUE *argv,VALUE self)
{
        sf::Shader *image = new sf::Shader;

        VALUE vert,frag;
        rb_scan_args(argc, argv, "11",&vert,&frag);

        if(!NIL_P(frag))
        {
                if(image->loadFromFile(unwrap<std::string>(vert),unwrap<std::string>(frag)))
                                return wrap(image);
        }else if(rb_obj_is_kind_of(vert,rb_cHash))
        {
                VALUE temp;
                if(!NIL_P(temp = rb_hash_aref(vert,ID2SYM(rb_intern("vert")))))
                        if(!image->loadFromFile(unwrap<std::string>(temp),sf::Shader::Vertex))
                                return Qnil;

                if(!NIL_P(temp = rb_hash_aref(vert,ID2SYM(rb_intern("frag")))))
                        if(!image->loadFromFile(unwrap<std::string>(temp),sf::Shader::Fragment))
                                return Qnil;
                return wrap(image);
        }

        return Qnil;
}
 

so it seems that the second part does not work if you use an Hash with both "vert" and "frag" keys ...

imo its a little bad but i think i can write around of that :/