Pretty straightforward: I think that the performers and brushes should have an option of reading in data NOT only from the actual minecraft world, but also from any sort of other, more generic, 3d matrix of data in a 3rd party file on the server box. Same for writing.

By default, right now, VoxelSniper reads IDs and data values from the NBT world files, and writes back into them, thus viewing the world we play in and changing blocks in the actual world. BUT you could have the option of instead linking a brush to a different input or output stream, that saves to a different file somewhere on the server.

So for instance, I could use Matlab to generate a weird, 3d shape, save it in a generic 3d ID and data value format compatible with VoxelSniper, and then push it to a folder on the server. Then, in-game, I could set my input stream to be "gavCustomInput.3dmatrix" instead of taking input from the game world. I would also specify an anchor point (so like, coordinate 0,0,0 in my custom matrix corresponds to 1230, 300, 47 in the game world. Could be done with a simple tool click)

Then, let's say I use a mat-mat ball brush. The brush will look for the replace material in my CUSTOM input matrix, and then it will write the new materials in the corresponding locations in the real world.

WHY?
This would be hugely useful. Essentially it would allow extremely customized selection shapes, without having to code any of the complexity of such a feature into VoxelSniper itself. I could use another programming language to make, let's say, a 3d Torus shape, with ID values 1 and 0.

Then, in game, I set the custom input to that, and do a ink-mat replace brush that replaces stone with blocks with data value 2, or whatever. Wherever I click in game, it will change only the ink values of blocks around my snipe in a torus shape. Essentially, I will have given myself a torus-shaped brush., without anybody actually ever having CODED torus shapes into VoxelSniper.

And THEN, I can set my custom OUTPUT to a file, and input to default, and build a shape, then use a sniper to save that shape into a 3rd party file, essentially saving it as a potential selection shape for later.

WHY #2?

Another, completely unrelated set of uses for this would be stuff like importing 3d rendered models easily into minecraft, by using any 3d modeling program to make a generic matrix compatible with VoxelSniper, then pasting in game with a replace brush using that as a custom input.

Why #3?

It would also allow VoxelSniper to be compatible with nonstandard block formats, like miniblocks, etc., by having a 3rd party program that translates one world file into a format readable by voxelsniper, and then reading that as custom input.

Oh also, this would allow us to basically use ANY feature that exists in ANY 3d modeling software on the market or coded by us for our own uses, to change things within our minecraft world.

So let's say I want to build a gigantic triangle of fabric hung from 3 points, and I want it to droop realistically, as if gravity were actually affecting it.

I could go in game, make a triangle with the triangle brush, export it to a 3rd party 3d matrix, then load it into some other program, or a custom made matlab or java script I made, or whatever, then apply the math to make it droop, then import it back in again, in the same, already-lined-up coordinates.

Essentially, it's like schematic files, but ONLY for data (like ID and data values) that fits into a true, cuboidal w_x_y*z matrix (3 spatial dimensions, and one dimension for any number of metadata, the first two being ID and data values). Thus making it extremely easy and convenient to write custom scripts or to convert to other strange formats, since it could be a standard, easy-to-understand, robust matrix format. One WITHOUT weird extra bundles of data like sign text, container contents etc. By getting rid of all that junk, you allow a reader program to literally read and write data using nothing but 4 for() loops (instead fo a full NBT library), thus making it much much much easier to apply functions not designed for minecraft, and to allow much faster and more compact code for what might be very complex 3d transformations.

All as an option, of course, NBT being the default input stream (and the very few brushes that actually use anything in NBT other than ID and data values could simply throw an exception if custom input stream is chosen)