How to hide unused textures/options in material?

Troubleshooting SDK
1

As in title. How can I hide for example that items:

q1.jpg652×543 73.1 KB

2

Is that a custom material definition? What does it look like?

3

There is no way to do this…
That’s funny because I was thinking of a way to store meta data with our j3m or j3md files for an editor purpose and, tbh I have not yet found a satisfying solution.

The obvious choice is to store meta data in the files themselves (for example in comments store some data that would allow to group the textures fields or hide them), But this data is completely irrelevant and useless for the engine itself and for your game, will clutter the file, and will probably produce some unnecessary loading overhead of the files.

The other choice is to have a separate file with this data… That’s what is done in the sdk with j3o btw (we have .j3odata), but these files are hidden to you and if you lose them, discard them in any way, or just move your original file in another folder, you loose your meta data. It’s usually kind of complicated to keep track on a file when you can’t see it.

So I’m shamelessly use your post to open the discussion about this, What you monkeys reading this think of those solutions, which one would you use, and above all… do you have another, more satisfying solution.

4

This sort of thing doesn’t belong in core for the reasons stated. The engine has no use for it and our typical policy is that editor-specific things should be external. I think that’s a good policy because it rapidly slides down a slippery slope (what about localization? What about generated documentation? etc.)

Better if this is meta-data (like a properties or json file) that you could associate with your material simply by naming/placement convention.

But I’m curious, what is the general use-case for having material parameters in your shader that you don’t want to use?

5

Material parameters that are set by the engine, for example the shadow maps.
You will never assign them in the editor that’s something done at runtime.

Also you could want to group attributes in the UI depending on some criteria. (same example shadow maps could be in a shadow section along with all shadow related parameters). All this dynamically, without having to develop a custom UI for each material definition of course.

Another example is for the shader node editor. I store the position of the nodes in a meta data file that is stored in a hidden subfolder of the project. But the issue is that you can loose it, and if the link to the original file relies on a naming convention, you have to update that when you move/rename the original file. That’s a bit cumbersome tbh, and doesn’t prevent 100% the loss of the meta data file.

6

That’s why I suggested a completely visible file.

So the typical convention might be:
MyMaterial.j3md
MyMaterial.vert
MyMaterial.frag
MyMaterial.metaData

All located together. Forgetting to copy one of those is a problem no matter what… but at least it’s not hiding.

7

Also, i already don’t like the fact that our j3m are not self contained and contains absolute paths, and that when you move a file, it’s broken. That’s another issue of course, but adding yet another separate file, that you can’t really track will dig this hole a bit more.

But yeah… visible files maybe could be a solution.

8

You mean absolute paths within your assets folder?

That’s like everything else in JME… a pain, but consistent at least. I’ve often wished for a more flexible asset location system… would smooth over a lot of asset import woes.

9

I couldn’t agree more. :stuck_out_tongue:
But I guess that’s another story :stuck_out_tongue:

10

I don’t know how its made “inside” but maybe one little option (comment or something) can tell SDK to not show in material list but still be usable in engine (as shadowsmaps)?

11

We would like to avoid dirtying up material files with 100 special little comments for editors that aren’t needed when you deploy your game. So will do some sort of metadata file (that can be easily stripped from distributions).

12

OSX stores metadata in a directory structure - maybe that could be a convention the SDK and IDE could make use of. I’m thinking like ‘terrainlighting.j3m’ is a directory and contains the file ‘terrainlighting.j3m’ and related metdata files. The SDK does not have to enforce this in any way (I hope) but when loading the j3m it could check if it is a directory and load the file from the directory.

13

When loading things from the classpath, you have no idea if something is a directory just by name… just that you can’t get it.

With a metadata file, you can easily look up related files on the classpath just like all other assets.

14

You are correct ofc but you can try the convention first and if that fails just try the ordinary way.

    private void load(final String assetName) throws ResourceNotFoundException, IOException {
        URL resource = getClass().getResource("/assets/" + assetName + "/" + assetName);
        if (resource != null) {
            // Cool, maybe there are metadata files an editor can make use of
            URL metaResource = getClass().getResource("/assets/" + assetName + "/" + assetName + ".meta");
            if (metaResource != null) {
                System.out.println("Found some metadata");
            }
        } else {
            resource = getClass().getResource("/assets/" + assetName) ;
            if (resource != null) {
                System.out.println("Old school asset file");
            }
        }
        if (resource == null) {
            throw new ResourceNotFoundException("Unable to find asset: " + assetName) ;
        }
    }
15

That doesn’t seem any better to me than just looking for the extensions one is interested in. For every user who finds it convenient to have everything in one directory, there will be one user who wonders why a directory has a file name. Never mind that to add metadata to an existing file you now have to do a bunch of directory juggling.

Not a fan, personally.

16

For renaming/moving around a directory can help to keep everything together. inside that directory all the different files have the same name.

MyFooMaterial/
Material.frag
Material.vert
Material.meta
…

Maybe that solves the problem you discuss here? Maybe not :smile:

17

Seems a pretty huge confusing price to pay for a teeny tiny microscopic convenience of not having to ctrl+click all of the files you want when dragging.

Not to mention that it’s a CORE change to support editor metadata and we’ve already discussed we are 100000% not making core changes to support editor metadata. Editors are on their own.

So if the engine has to be hacked to load “Lighting.j3md/Lighting.j3md” instead of “Lighting.j3md” (why am I the only one that finds that absurd?) it’s not going to fly.

18

What about materials that share the same .frag or .vert?

19

I don’t know why you find that absurd - can’t help you there :slight_smile:
But I think you missed something because it shouldn’t be “instead”. Core could try the directory name-mumbo jumbo first and if that does not work it can fall back to the current behavior. The Core should not load metadata files, it only have to follow the same naming convention when looking for assets. Editors can use the naming convention to predict where metadata files are and load them however they like.

Shared shader files - exactly the same as now. It must of course be a backwards compatible change.

20

So, requirement number one: we will not be making core changes to support any editors.

…that pretty much rules the subdirectory thing out. It’s ugly and it has no real use other than shoving random metadata files in.

If you want to put all of your material files into a single subdirectory then do that. There is no reason to confusingly name that subdirectory with a redundant .j3md name.