This one has been rattling around in my brain since forever, but as an unformed infectious thought. I’ve been using “Library I/O” devices a lot since they came about, mainly for a WM to WM workflow (optimizing memory and automating repetitive stuff). For a baked memory dump, it’s been a massively helpful feature for me. I have a few feature requests that I need opinions on.
- Library file type optimization:
Right now, the Library file type is a big single “memory dump”. There have been steady updates to it, like saving of “Composite data” (mostly through my incessant requests…). But it’s still a hassle to use for anything besides “linking two world machine files”.
In my opinion, the structure needs some optimization to be used as a mid project caching utility.
Right now, when you load a library from disk, the whole dump is loaded into memory at once. Could the file type be customized to save data in a way that when you load it using a library input, only the output ports “connected” get loaded into memory? Maybe the library devices need a separate “Memory Conservation” mode and checkbox for this “Selective loading” feature? I think it will be very helpful. It will also help my second feature request, a “Disk Cache” or “Bake inputs” device.
- “Bake Inputs” Device:
A new device like checkpoints, but with above optimizations, and disk caching support would be incredibly powerful imho. The device takes in an arbitrary number of inputs, and after the the input gets connected, the connected part of the graph gets disabled (I know there’s a big monkey wrench called “final build” that can be thrown in there). Once you have most of your inputs connected, you can build to that device (disabling of connected graphs could be coupled to that build, could also be a “memory conservation” checkbox). The build would bake a granular TML library to disk at your specified location, and now the node will spawn outputs for each of your inputs, similar to a “Library output”. But this time, only the output you connect, will be loaded from disk.
If this device be compatible with macros and parametric inputs regarding the same, this would open up so many possibility for full terrain pipelines within one project file (basically I can stop splitting my project files for memory reasons while creating materials).
)