I have been digging around for information about larger-scale pixel mapping, and I couldn’t find exactly what I was looking for yet.
I’m looking to output ~90 universes of DMX via sACN to a bunch of pixel tape. I am looking to do this by sampling one HD canvas, where the LED fixtures are arranged according to their geometry.
I have a CSV file that has the coordinates of each pixel to which I need to output data, as well as the universe and address of that pixel (each pixel’s footprint is 3 addresses - RGB 8-bit). Is there an easy way to import all of that data and have Touch output DMX by just sampling a TOP? Basically, the same way I would do it in Disguise by providing a DMX table for a particular DMXscreen.
The data is in CSV format currently, but I can manipulate it to JSON, text, etc. if needed.
If you bring in the CSV as a table, you can use DATto SOP to make 3D geometry from the XYZ coordinates, you can then use SOP tools to move around the sampling points and create different mappings. Your last step should be to get the SOP data that you want to use for sampling shrunk down into the unit range of zero to one XY, and then use a SOPto CHOP to create a CHOP that will provide UV coordinates to the TOPto CHOP. The zero to one part is because the TOPto CHOP expects UV coordinates to be in floating point but your CSV probably has units in pixels or some other real world measurement like feet or meters etc.
Assuming the DMX universes and addresses are relatively contiguous, you can split / trim / shuffle the outgoing CHOP data into universes and even use the names of the CHOP channels and the original CSV input to construct a DMXout CHOP “routing table” with DATs. If you have to skip DMX channels in universes, it gets a little more complicated, but if it’s just straight runs of RGB LEDs / pixels, then it should be pretty easy to get each universe separated out into separate CHOP channels with 510 samples each (170 pixels * 3 colors)
If you lock the final CHOP that is being input to the TOPto CHOP (for UV purposes), then none of the geometry or DATs before that will cook and thus your file should run pretty smoothly. With an eye for optimization, you can run literally hundreds of universes out of even a moderately specced computer, especially if you’re doing most everything in TOPs because for even the biggest PixelMapping projects, you rarely need source content that is even as high as 720p. Some of my projects don’t even require more than the default 256x256 texture size in a newly dropped TOP.
Thanks for the reply, Pete! So the CSV of pixels would need to be ordered in the same way that the pixel tape is ran, then? In order by universe, then address?
That would certainly make it easier on you, but if you also have a similar list of the DMX universes then you can take them in any order and re-order them in the output using the DMXout CHOP’s routing table. This is assuming the universes themselves are contiguous. If you need to skip specific channels or jump around different channels in each universe then it gets more complicated, but if you’re mapping LED strips that’s usually not the case.
If you’re mapping just the RGB of lighting fixtures in a regular lighting rig through a merge with a lighting console (moving lights, lekos, PARs etc) then it gets more complicated especially since you need to be ready to change your patch at a moments notice even mid-show since sometimes part of the troubleshooting process on a lighting rig involves technicians needing to re-address lighting fixtures on the fly and is a big part of why all lighting consoles separate the “patch” from the “channel hookup” and all the programmed cue-writing and data that goes with them.