Orienting displays in a cube with 3x 64x64 displays

[elliotmatson]

I'm working on a cube with 64x64 panels on 3 neighboring faces. Because of cable lengths and routing, the panels are oriented as such:

I'm struggling with finding a way to set up this library so that I can draw text on each panel in a useable orientation, even with VirtualMatrixPanel. I might try modifying VirtualMatrixPanel so that I can somehow define the position and rotation of each panel individually, instead of the preset options. Is this something that would be useful to the library as a whole? Or should I keep that on a separate fork?

[mrcodetastic]

Indeed your best bet would be to take a copy of the virtual matrix class and make custom version with your pixel mapping for a 3d cube.

Realty is this should not be too difficult as you have a clean chain of 3 X 64x64 panels (opposed to say trying to make a cube out of 6x 32x64 panels trying to emulate a 3x 64x64 configuration)

I don't want to merge this into the 'core' library, but your custom class we could add as a cool example?

This looks like a cool problem to try solve by the way, happy to contribute my thoughts on your repo as well. You'll need to implement custom rotation for each panel in the horizontal chain... Could borrow code from any of the other GFX libraries floating around.

Two things:

• I can't quite see that order and orientation the panels are "chained". I see the top panel is the first one.
• How do you intend to 'address' the panels in your code? If you're treating them as individual screens then the problem is probably easier to solve. If you want it to all be some virtual display which is 128 wide and 128 high (but only for the middle 64 pixels), then it gets more interesting :-)

[elliotmatson]

That seems like it would work well! I'll start working on that!

In the picture, the top panel is the first one, then the bottom right, and then the bottom left

I'm not 100% sure how I want to address them yet, but individual seems the best right now. I actually built 5 of them, my brother and father and I are working on patterns for them together, so I need to connect with them on what would be most helpful.
Really, drawing text is the main thing that matters in this context, as everything else is pretty easy to rotate and move.

[mrcodetastic]

I took a clone of your repository and was going to start working on a virtual class for you, but I'd have no way of testing it so stopped.

But basically from what I see, my suggestion is in your initDisplay() function - this is the only place you deal with the underlying dma_display pointer, from there onwards all your Cube logic should call your custom virtual display class that does the translation from drawPixel()->dma_display (basically as I said, copy the Virtual Display class).

It's up to you if you want to initialise three copies of the same virtual display class (one for each face of the cube) or do something tricker within one virtual display class.

Of course, when initisalising this virtual display class it will need to be provided the co-ordinates for where it is allowed to paint horizontally within the physical chain (dma_display), and what rotation should be applied within that virtual co-ordinate space.

[elliotmatson]

I was actually about to sit down and work on this, so that's really helpful! What I might do is actually make several copies of the Virtual Display class that each map things in a different way, as it might be nice to have several different mappings depending on what kind of patterns are being used.

A bit unrelated, but how well have the ESP32-S3's been working? I'm considering swapping to those, as they would:

• be able to use PSRAM for DMA (Which means I can enable double buffering)
• Be more readily available with >4MB of flash
• Save me the cost of a USB -> serial chip
• Have better vector math acceleration

[mrcodetastic]

I was actually about to sit down and work on this, so that's really helpful! What I might do is actually make several copies of the Virtual Display class that each map things in a different way, as it might be nice to have several different mappings depending on what kind of patterns are being used.

Yeah, this would probably be the most sensible and workable approach.

A bit unrelated, but how well have the ESP32-S3's been working? I'm considering swapping to those, as they would:

* be able to use PSRAM for DMA (Which means I can enable double buffering)

S3 support works perfectly. Use release version 3.0.2:

Caveat: From my testing when using PSRAM for the DMA buffer:

• The maximum ESP32-S3 clock-speed to the HUB75 panel that could be achieved was 10Mhz - this is when using a N8R8 which has the best throughput PSRAM -> Octal PSRAM. No idea why, but I suspect the PSRAM can't keep up with the DMA throughput when > 10Mhz and bombs out.
• So test your cube using a clkspeed of '10Mhz' (can do this obviously with the hardware you currently have) to see if this is acceptable (not flickery). If not, you have a problem and you might need to:
• Not use double buffering on the S3 and therefore can use faster but limited internal SRAM for the DMA Buffer, which allows bits to be pumped to the HUB75 panel @ 20Mhz (or more) + and then create your own 'off screen' buffer like this: https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-DMA/tree/master/examples/ChainedPanelsScreenBuffer and then write a function to 'copy' from this buffer across to the single DMA buffer.
• or reduce the color depth a bit, but the library tries to do this anyway to keep the refresh rate up.

[elliotmatson]

@mrfaptastic this worked great! Still need to implement the fast drawing functions, but that can wait a bit

[mrcodetastic]

That is so cool!