Open nmonkee opened 11 months ago
I haven't looked at how that import works but I have executed it with a single 250 string cause I taught how to do it at the Florida Mega Mini. I'm wondering if its a case of the grid being created for the custom model causes more than one pixel to fall into the same grid cell and only one pixel can exist in each cell of a custom model. At some point I was going to be adding a new import option that was going to use the actual floating point positions so nothing would be lost. Unfortunately I've gotta setup my show now and then after going hunting I'll be working on finishing up the moving head work so not sure when I could look into this.
I manually edited the models where it was causing the biggest issue (two sets of clusters with 400 where only 280 or so where mapped). FWIW I did not map the clusters, I used the default map. Anyway it’s not the end of the world for my current show. Hardly noticeable. So it can wait. But if you want any tests run or more outputs etc, before the end of the season is best. As I’ll be packing away. Basically I’ve worked round it. But happy to help solve for future, if and when you / someone has time to investigate. Thanks
If you're still fighting this issue, Artnet 2 Twinkly can generate an xmodel file for xlights to import from, and it doesn't leave out the nodes. You are correct about the cause. If the lights are too dense, it will leave out identical x/y coords.
I manually fixed up the models. The 2D ones at least, not sure how I'd go about fixing up the 3D one. I've seen Artnet 2 Twinkly, but is for Windows, so not for me. I did see they are working on a cross platform, and tried it out. But its not ready yet as seemed quite janky and buggy. Something to consider in the future if and when more progress is made.
the cross platform version i'm working on doesn't do exports yet
On Fri, Dec 22, 2023 at 4:59 AM nmonkee @.***> wrote:
I manually fixed up the models. The 2D ones at least, not sure how I'd go about fixing up the 3D one. I've seen Artnet 2 Twinkly, but is for Windows, so not for me. I did see they are working on a cross platform, and tried it out. But its not ready yet as seemed quite janky and buggy. Something to consider in the future if and when more progress is made.
— Reply to this email directly, view it on GitHub https://github.com/smeighan/xLights/issues/4145#issuecomment-1867546928, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADB6POPV6GI73HVHSR54O63YKVRYBAVCNFSM6AAAAAA7USVZCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRXGU2DMOJSHA . You are receiving this because you commented.Message ID: @.***>
When importing model data from Twinkly Controllers where the pixels have a custom map (using the Twinkly App) sometimes not all pixels are in loaded into the model.
e.g From a Twinkly String with 250 LED, instead of 250 pixels being loaded into the model, you get what feels like a random selection like 231 or 242 etc. Basically some are missing on the imports.
Steps to reproduce the behavior:
Here are some example discrepancies I had accross devices:
Window Left = 231 ! 250 Window Right = 245 ! 250 Door = 230 ! 250 Wreath = 94 ! 100 Tree = 591 ! 600 Tree 2 = 249 ! 250
XLights populates the model with the correct coordinates / number of pixels present on the controller / model.
The Twinkly API returns the correct coordinates, here is the output from a small Python utility:
date and time = 21/11/2023 13:15:16
fw version: 2.8.18 device name: Window (Right) sync: {'mode': 'slave', 'slave_id': 'F665D445-A470-4B6D-9D69-63576802857D', 'compat_mode': 0} num LED: 250 LED profile: RGB bytes per LED: 3 max frame: 750 max packet size: 760 strings: [{'first_led_id': 0, 'length': 125}, {'first_led_id': 125, 'length': 125}] source: 2d synthesized: False uuid: 858B600D-4347-FCBF-6FBA-8462181838A7 LED coordinates count:250
coordinates: [{'x': 0.473511, 'y': 0.393738, 'z': 1.0}, {'x': 0.473511, 'y': 0.393738, 'z': 1.0}, {'x': 0.455322, 'y': 0.39386, 'z': 1.0}, {'x': 0.434082, 'y': 0.396545, 'z': 1.0}, {'x': 0.412842, 'y': 0.393555, 'z': 1.0}, {'x': 0.392456, 'y': 0.39386, 'z': 1.0}, ...
I've truncated the above, but all the coordinates are returned.
Versions (please complete the following information): Apple M1 Pro running macOS Sonoma v 14.1.1