Loading large numbers of textures in large file sizes.

    dream
    May 16 2013 | 3:12 pm
    Hi all,
    I'm trying to build a video wall-type Jitter patch that scans across multiple still photographs, arranged in a 4x4 grid. I'm doing this with 16 jit.gl.videoplane objects, referencing some of 50+ texture objects, each of which contains a high-res photograph. Scale and offset messages drive the photo motion. The system is efficient enough, getting 60+ fps. The problem I'm facing is loading the 50 images into the texture objects.  Loading one by one, as needed by the patch causes an expected drop in frame rate until the loading is complete. Not ideal with 50 loading events. Loading all 50 at once (inside 50 poly instances) or in quick succession causes Max to hang for a while, then give up on the operation after only a portion of the textures have been created. I don't know enough about scheduling and memory operations to know where to start fixing. How do I get fifty 3MB textures loaded quickly and dependably?
    I'm afraid I can't post a patcher just now, though I should be able to follow up with something.  I'd also be interested to know whether in general I'm going about this the right way. The method I'm using works, but this side of Jitter is new to me and it wouldn't surprise me if there's a proper way to do this that I'm missing.
    Thanks for reading.
    • Peter Castine
      May 17 2013 | 10:01 am
      It's been a while since I've done OpenGL stuff in Jitter, and I unfortunately no longer have access to the documentation I was using, but IMS, the amount of texture data you can load is limited by the memory available on the GL graphics card.
      If that is indeed the case, you'll have to check how much memory your card has for texture data. It might be a simple matter of buying a card with more memory.
      If that's not the cause, it's also possible that there are timing issues you'll need to look at. If you're sending all 50 textures on one bang, communication between Jitter and the GL card may get swamped. You could handle that by starting a metro to trigger one texture at a time and stopping the metro when the last texture is loaded, but that is kludgy (and you'll need to experiment to find appropriate timings for your hardware). If you can get feedback about when loading a texture is complete, it would be more robust to trigger one texture, wait for the feedback, then trigger the next texture (probably after at least a [del 0], just to give the Max scheduler a chance to look at other tasks).
      Sorry to only have vague ideas here, it's been a while since I've done this stuff.
    • dream
      May 17 2013 | 11:17 am
      Thanks Peter.
      I have 1024MB of video memory to hold ~166MB of texture data, so I'm pretty sure that it's enough. Unfortunately I'm on a laptop, so buying a card is out of the question. I'm pretty sure it's not a bottleneck here though.
      I've moved the textures on to an SSD, which has increased the number loaded before Max gives up to about 40. Not perfect, but an improvement. As far as I'm aware, jit.gl.texture doesn't give any feedback when a load operation is complete. It's frustrating, but I really don't think the object is intended to read from the HDD during real time rendering. Even a 100k file read will drop my framerate to about 16FPS for two to three seconds.  I had tried your metro based workaround already, and not found any joy, but I should try it again now that the SSD is involved.
      Thanks for the tips!