Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File extensions other than .frag, .vert #9

Open
dy-dx opened this issue Sep 28, 2014 · 4 comments
Open

File extensions other than .frag, .vert #9

dy-dx opened this issue Sep 28, 2014 · 4 comments

Comments

@dy-dx
Copy link

dy-dx commented Sep 28, 2014

Hi! This plugin is awesome but its usefulness is limited by the file extension requirement. For example, I cannot use it with the shader-school exercises because their files all end in .glsl.

I understand that the ANGLE translator uses the file extension to decide what type of shader it is. Do you see any way to get around this restriction?

@brendankenny
Copy link
Member

Hi!

So, actually, ANGLE just needs to know what kind of shader the file is (vertex or fragment); it doesn't care how you tell them apart. It's the plugin that (currently) uses the file extension to tell the difference. We're definitely willing to add other ways of identifying the file type if there's a good way to tell them apart.

Two separate concerns:

  1. It looks like shader-school uses vertex and fragment somewhere in the file name (e.g. here), which might be something we could add. It seems unlikely that someone would have a vertex shader with fragment in the file name, but we'd probably want to make this an option (and probably off by default).

  2. shader-school uses glslify to be able to do export/require in shaders, so in this exercise, for instance, the validator plugin wouldn't know how to validate expected.glsl and you'd get a permanent no matching overloaded function found error in vertex.glsl because matrixPower wouldn't be able to be resolved.

Obviously this is a problem larger than just the shader-school exercises, as glslify is used in quite a lot of projects, so this is something I've been thinking a bit about.

Short of integrating glslify into the plugin, I'm not sure how to solve this issue right now, but some initial thoughts:

  • For vertex.glsl: solution for (1), above, might be sufficient at least to start with, as you'll only have the single error.
  • For expected.glsl: we could add an inline directive that tells the shader validator at the top of the file whether to treat the file as a vertex or fragment shader, similar to the current spec override

What do you think?

@dy-dx
Copy link
Author

dy-dx commented Sep 28, 2014

Those features sound like a great step forward, even if the glslify case isn't solved.
In my case it's not a huge deal anyway, since the files that the students are supposed to edit (e.g. transforms.glsl, mpow.glsl) would still validate correctly.

@traviswimer
Copy link

One simple solution to this is to just add a key binding to run the specific validator. So maybe something like (CTRL + SHIFT + S + V) to validate vertex shaders. This doesn't fully solve the problem, but I assume it would be easy to implement.

Another thought:
I'm not really a GLSL expert, but aren't certain OpenGL variables, such as gl_FragColor, only available in fragment shaders? Do you think it would be reasonable to scan the contents of the file for these variables to determine the shader type?

@marquizzo
Copy link

This would be very useful for me too. Right now, I have to save my local files as .frag and .vert, but when committing to the main repo, where my team is working, I have to rename them to .fs and .vs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants