It’s been asked many times… never been contributed.
The thing is the SDK has an auto completion for assets in the classpath so it’s even easier than a constant class, because it works on your custom materials too.
Now I use intelliJ and it has a similar auto completion for resources…
I’m not opposed to this… but in the end it will just be a class with a couple of constants… that you will probably never use in a full blown project as you will probably have custom shaders…
It would still be faster to find the proper constant than find the desired j3md out of LOADS of them you can have, especially if you have a separate project for experimenting with GLSL.
Also if we don’t make the constants final (well, they aren’t technically constants then, but eh), user could redefine what their unshaded, lighting, etc. j3mds are.
That’s an argument against it to me.
As said you’ll have pretty much 3 constants in this class
UNSHADED, LIGHTING, PBR …
If you redefined them in your project, it’s as fast to create a class in your project and add the path to stock materials in it.
EDIT: As said I’m not against it, if people feel like it would help so be it. It’s just that I feel it won’t be that much used in practice.
If a user wants to use custom ones in their application then why wouldn’t they just type the strings?
Or maybe we can make it super complicated and have a bunch of different ways to set these silly “constantys”:
-local config file
-global config file
…all to avoid typing a string. Now you’ve introduced ‘yet another thing that can go wrong’.