Sooo, gonna tackle now the problem of materials in my track editor.
Until now, the circuits were loaded from java files and made from calls to high level methods.
I’m in the process of moving towards loading json files instead, for 2 reasons:
my high level methods were all based on the idea that the tracks were built sequentially, as in one track before the next, but I wanted the editor to allow crud operations on any track of the circuit
security… I really don’t like the idea that people would open security holes the size of a continent each time they loaded a downloaded map… and none of my tests with sandboxes pointed towards me having any chances of securing that loading. So it’s another humbling experience, but I’ll have to admit you peeps were right all along :.
But, with java files, the materials could be defined directly in there and the editor would just allow selecting the material for the different tracks. This won’t work with json files.
Now, I have some “ideas” for resolving that:
using j3M files located in a mod/materials folders but that would probably be expecting too much of my users (if there ever are any )
having interfaces in my editor to build materials from the ground
having interfaces in my editor to only modify the most common properties of a set of provided j3m’s
In order to make a better choice, I would like to know:
what would you peeps think would be a good way to do this?
where can I find the source of the sdk window that allows modifying/creating materials?
is it possible to ask the assetmanager for a list of available j3m’s? I think I read that it wasn’t possible, so mostly looking for a confirmation of that. The default provided j3m’s would be located in the assets jar.
if I create materials from the same j3m file… will they still be considered like one material as far as batching goes? I suspect no, but crossing my fingers haha.
any data you think might help
Thanks in advance :).
NB: I feel stoupid due to my remarks somewhere else about the complexity of json… nothing complex in there… just an exchange format and some simple libraries to serialize/deserialize.
If you go with the vanilla engine you will have to do with loading j3m files, everything else is implemented in the SDK. If your plugin was made for the SDK it could access the classes and utilities to create j3m files etc., this way it can’t really. If I were you I’d probably go a similar way to pauls tree editor, having one file type for your data with everything including material etc. in it, creating the scene from that in code and then being able to save the results in a j3o file.
The “problem” with this approach is that all asset paths are static once in the j3o, so you will always have to know the final path in the user project for e.g. image and j3m files. So j3o isn’t an exchange format but more like a java class its specific to a project. This is basically why the SDK handles j3o conversion and model/asset handling the way it does. If the plugin was in the SDK it would simply support opening “your” file type, creating the scene from that and placing all image/material files in the project as needed, then saving a j3o file. If you have a standalone editor you will probably have to implement this about the same one way or another.
Thanks for your answer @normen … I’m looking into it :).
Yah, I’m planning to have the in-game editor allow to select/modify/create/delete materials to be used by parts of the edited circuit. So the facilities of the sdk sadly won’t be available. But I sure will use the sdk to make the starting pool of j3m’s.
Unless I missed something, I’m not expecting troubles linked to my j3o models since the editor will allow selecting materials and the materials UI will allow pointing towards textures and stuff.
While models could be indeed exchanged, their materials would be added either via the editor or a json loading, so if not mistaken, shouldn’t become a problem for me? I hope I’m right :D. All materials would be created. Would not use the ones contained in the j3o’s.
I’m thinking:
the game would come with a bunch of j3m’s
there would be a mod/materials folder
the editor will allow:
displaying a list of available j3m’s (original + contained in the mod/materials) folder
creating materials from selected j3m’s from that list
filling/modifying the most common parameters of those materials (diffuse texture, transparency etc)
displaying a list of available materials for use
cloning of materials for convenience
selecting, for each track/model track, the material to use
Json circuit files would contain the name of the used j3m’s and a list of their parameters and their values.
I haven’t started playing with shaders yet, so one j3m might do the trick for now?
In all honestly, I’m pretty clueless here, so while I feel like I’m in the good direction… could totally be that this is going off the cliff :D.
)