Suggestion to the predefined materials and shaders

Development
1

Hi Monkeys,
I have a suggestion to the predefined materials and shaders, why there isn’t a class that contains strings to the position of this materials for example instead of this:

Material mat = new Material(assetManager,"Common/MatDefs/Misc/Unshaded.j3md");

we could do this:

Material mat = new Material(assetManager,Material.UNSHADED);
1 Like
2

I guess because everyone tends to make a class that has these definitions along with links to their custom shaders.

¯\_(ツ)_/¯

3

I do it too, and it’s the main reason that made me open this topic, but why I will do this every time I create a new project it’s a waste of time.

4

:+1: for this great QOL improvement from me.

5

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…

6

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.

7

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.

8

It would solve the problem with custom shaders as well as making code easier portable from other projects. But it could indeed create a mess.

9

It starts with things like the scope then (how about texture/buffer names), how about filters?

To me it is a bit spoonfeeding for 4 Lines of Code

10

I think we can add these paths as constant strings, which takes these paths from system property on initialization. I can make a PR with this to review from you :slight_smile:

11

That sounds even more complicated and dissuades me even more. If you do it keep it simple, please.

12

the main reason of this approach is to have a possibility to override these values from user code :wink:

13

Yes… and all this code to not write 3 Strings that you should know by heart by now…

EDIT: Make a Materials class with static final strings and were good.

2 Likes
14

yep, these 3 constants will take paths from system properties with default values(current paths in the engine), if a user wants to use his custom materials instead of these, he can override it.

15

yep, we can do it in static initializer block of the class.

16

Not Material, Materials.
Same pattern as Collection / Collections etc…

17

I see, ok, I will update the PR with SSBO today and will make this PR.

2 Likes
18

@nehon

19

That’s silly.

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”:
-system properties
-environment variable
-local config file
-global config file
-system registry

…all to avoid typing a string. Now you’ve introduced ‘yet another thing that can go wrong’.

1 Like
20

It’s just my suggestion, if you don’t like it, you can reject it :wink: . I have absolutely different points of view with you in the most cases which relate to the engine :slight_smile:

1 Like