Ok, I understand a bit better now. Basically, it`s an compact output storage device. A few more questions though: 1. Will the new Library" device have an mask input? In case I want to add the stored terrain to the main terrain in my scene and maybe use a Layout device to shape the contour of the "Library" stored terrain for a seamless blending. 2. Regarding the data segregation and memory usage, it will very convenient to load from disk only the data you want (heightmaps, or textures,...etc.), and interface wise, you control that with an specific output you set up the "Library" device. Something similar to the macros inputs/outputs setup. Having organised the Libraries organized as heightmaps, textures, etc., will split your terrains and I find this workflow solution more as a workaround. The main purpose of this device, for me, it is that it gives you the option to store my terrains in a organized and more compact way. 3. It will be nice to have a preview window in the "loading interface" of the Library device. Similar to the Photoshop preview. Or even a main Library presets tab/window for faster preview. this will spare me of rendering separate images for each library device. 4. Will these Library devices use less space on disk, compared to the standard images outputs? I know that different files types have different compression algorithms. Obj files are pretty big compared to an equivalent heightmap. 5. Considering the new multi-resolution feature, will I be able to store a terrain at 1024 pixels size and when I load the 1K stored "Library" device in a new scene, to setup the desired output at, lets say, 2048 pixels? If this option is not possible, maybe a specialized size/scale device will do the job? Many thanks.
The Library/Stage/Multi I/O devices operate as simply as possible.
In one sense, you can think of them as simply a file like a photoshop PSD that can contain multiple layers instead of just one dataset. On the other hand, the fact that the data packets preserve their world space information makes them much simpler to use, as they will import at the correct location/scale automatically.
The on-disk image/heightfield data file format is a custom one, but it is the same as is currently used to save sessions. Whether or not the format will be published for outside consumption is TBD, but it is a simple file format so it would probably be easy/useful to publish.
You can create or import one or many library files. To segregate data, I would simply use different "Banks" of libraries, for example one library might contain all of your texture / mask outputs, another the geometry, etc.
In terms of memory usage, the library input itself will continue to contain a copy of the imported data just like a current file input device does.
Regarding tiling: Since the library files are meant to be a tool for internal wm workflows, whereas tiling is almost exclusively meant for outside applications, the interaction here is TBD. Tiled output will Just Work much like the file output device does; however input of a tiled library would be more problematic as a tiled library would consist of many files and any given library wants to just accept one. It's a fair bit of additional work to implement tiling input. On the other hand, having a custom format makes the process easier. We will see, but at least initially it will not be able to.
What it would let you do is separate the process of "building the terrain" from the process of "finding good masks". The terrain and any additional input masks (erosion output, etc) could be stored to a library, then textures/weights constructed in a separate world (or just a different section of the same world) without having to ever worry about rebuilding the whole thing from scratch.
Awesome. Interesting article, and I love new features in WM.
I need to build a world then I need to tweak the output mask and try them in UDK. So I need to save a lot of World with different slope masks until I found the right one. It is easy for me to over wright the best one. Can this new node help me?
Library I/O sounds really exciting. And considering the other new feature, the muti-resolution support, it looks that the WorldMachine workflow might change quite a bit. I`m really curious how this new feature will work. And of course, a few questions: 1. You mention that: "The Library I/O devices allow you to store and easily load multiple data packets". Is this some sort of cache file format you use to store built worlds? Or parts of it? 2. How this Load Library device is affecting the memory usage? Using the Load Library device in a second .tmd scene and applying/connecting new erosion devices will change the terrain. After loading the library preset and the data is processed by the newly attached devices, will the memory be discarded? 3. Will I have the option to edit just a tile/chunk from the loaded Library preset? How am I going to do that? 4. Also, will I be able to, maybe, load only the heightfield from the source file, without using memory for the textures I don`t need?
Really curious how the new features will change the way we work now. :) Many Thanks.