Author Topic: Pixel re-ordering?  (Read 2078 times)

Is there a way to rearrange the pixels of a texture using something like a UV Coordinate map? I've tried a setup that uses multiple directional warp nodes, but that didn't work at all. Take a look at the attached image to see what I'm referring to.

I'm trying to arbitrarily rearrange sections of a map so that the output has a completely different distribution.

I'm thinking of using this technique for things like parquet floors, mosaics (with arbitrary shapes), rock walls, etc.. Using the Fx-map and it's quadrants wouldn't work on shapes like cobblestone, fishscale tile, or things of that nature (or at least, I couldn't get it to do what I want).

Essentially, I'd like to be able to feed n number of texture sets through this graph and get  rearranged pixels as the output.

Does this make any sense? I can try to clarify if you need me to.

This is one of the main new nodes on our roadmap for the near future.

I'd hate to put you on the spot, but is there a rough eta on that?

Actually, this can be done with the FX-Map, however, there are two drawbacks:

1.) It's kind of slow (almost 100ms for a 512x512 image)
2.) You need to make a fx map for each resolution

To get this to work, make sure you completely understand the second example in the manual (the tutorial on fx map : using vector maps).

Here is roughly what you can do:

- Import the uv map(s) and your image in one resolution (eg. 512x512)
- Add a fx map (color mode)
- Feed the uv map into the fx map (not as backbround but) as input image 1 (internally #0)
- Feed your image into the fx map as input image 2 (internally #1)
- Edit the fx map, add quadrant nodes until you have a total of 10 (for 2^9 = 512) quadrant nodes, autolevel (more or less nodes for other resolutions!)
- Set the pattern of the first quadrant to square
- Set the color on this quadrant to a custom function like so:
- get $pos var, sample color of input 0 (image 1),  swizzle float 2, sample color if input 1 (image 2), set this as output


Thanks for your response GerryM.
This had occurred to me, but I kind of shrugged it off due to the fact that we're targeting 2048 and higher resolutions, and we'd likely be running this on 10+ input images at a time. In fairness, I haven't actually tried it out yet, but I don't imagine it'll be terribly speedy. I'll try it out, and if it works, I'll update.