Ability to export graphs as closed node networks, so other users can utilize nodes in their graphs without having access to the inner workings of those graphs. (I.E. .sbsar files for Substance)
It will provide InstaMAT authors the ability to develop nodes that they can provide to others, without having to offer up access to all of the source code/nodes.
Ideally it would be an option in the File menu. This may already be in the works, I know it was mentioned in a livestream that it was already a consideration, however its implementation would be a major boon for authors that intend to develop utility nodes for others to use.
Perhaps this would be a nice feature for the paid version. On the other hand, such solutions close access to the structure of the tool, which does not allow using it in commercial projects, as there is no possibility to modernize the tool for certain conditions. But if such “closed” tools will be free of charge, I see no reason not to do it. If you want a free implementation of the material, here is a closed access to the graph structure, if you want a paid one, here is an open functionality and change what you want. Objectively it is correct. Probably under the condition of changing the user agreement, it’s possible to do it. Again, closed tools that are no longer supported by the developer over time may cause bugs. If MAT changes something in its API and you stop updating your graphs, then the person who bought your product will be left without support in a year, and he will not be able to change the file himself. I will support you, but I think it is necessary to approach this problem comprehensively.
Thanks for the input!
I understand the concern. I feel it maybe lies outside the scope of simply creating closed/compiled node functionality though? It sounds to me like your hesitancy isn’t really with how this would be implemented by InstaMAT, but rather the ecosystem that would evolve around it.
Right now I work with a team that uses SBSAR files I’ve created. I’ve opted for SBSAR so that there is zero chance they will accidentally alter source files and mess up nodes for the entire team. I think having this functionality would be tremendously useful for instances like this.
API changes potentially breaking things will be incredibly frustrating, I completely agree. Unfortunately that’s inevitable and I’m not sure what a catch-all solution to that would be? I think that’s the risk you take when buying 3rd party nodes that don’t offer open/uncompiled graphs.
@Chunck I’m happy to report that this feature is now available in an internal build and might be available with the upcoming build!
Exporting a securely “cooked library package”
The way it works is that you can export your cooked project from the menu.
Once you’ve picked your path, MAT will ask you whether you want to just cook, or cook and secure:
Now that it’s cooked, the user can copy the IMP to his library in Documents/
Once loaded it will show up in the library and it can be used like any other node:
However, trying to open the node by double-clicking and MAT refuses to open it:
When trying to open the package directly using the open package option, it also refuses it:
Cooking projects that reference a securely cooked library package project
If you cook a project that uses a node or project from a cooked package, MAT will not include that project in the project that is now being cooked. This is done to avoid leaking of data but causes a hidden dependency as a project that has a dependency on your cooked library package may not load if your cooked package that contains this dependency is not available in the user library.
Are there other ways to crack open a securely cooked library package?
I’m not aware of other ways to open/load/inspect/extract data from a package so I believe this is secure and implements the requirements.
YESSSSSS : D
That’s fantastic to hear! I’m excited to see it roll out, you’ve got me all giddy haha.
Thank you for the updates, I’ll see if I can crack it and will report back if I have any findings.