search

gpstar81 / GPStar-proton-pack

GPStar Proton Pack and Neutrona Wand
https://www.gpstartechnologies.com
GNU General Public License v3.0
37 stars 8 forks source link

New 9 led Cyclotron rotation animation #317

Closed Toy203 closed 2 months ago

Toy203 commented 3 months ago

Just got the new leds in and it feels like the "rotating" animation is still a bit choppy. It doesn't feel constant and smooth to me especially after the first rotation. I currently have a single paper sheet inside as a diffuser and the stock plastic ones mounted on.

To be fair, it might be the diffuser that makes it look more jumpy than it is. I'm always picky about it so it also might be me lol.

Without the paper and with only the plastic lids I can still see individual leds and don't like the effect.

DustinGrau commented 2 months ago

Hmm, I've added those to my lid just recently and don't notice it. Either the current code fixes something that affected that animation or it's subjective. Is it the animation for each cell, or is it between the lenses? Can you be more specific about what you are seeing as choppy?

Toy203 commented 2 months ago

It might indeed be very subjective, i'm super picky and possibly way too much in general, maybe i'm overobsessing over this way too much honestly. My main gripe is the initial "rotations", during the ramp up/down (i'd say the first and last three cycles), the jump from each disk, especially the topmost two feels a bit "jumpy". I feel the light just jump from a disc to the next and doesn't look lika a proper "rotation" as it should be. I wish it looked more regular like it is a proper led ring or something spinning inside the lid. I do use a sheet of plain paper as a makeshift diffuser in the halves of the lid, and i have enabled the led ring simulation in the eeprom.

nomakewan commented 2 months ago

Oh, that actually makes perfect sense!

It's actually because the ring simulation code is based on the spacing from the 40-LED NeoPixel ring. The Hasbro LEDs and Frutto 5-LED boards had very similar spacing, and so there was plenty of "void space" to account for "invisible pixels" that were "behind the lid".

However, since the pixels on the 36-LED setup are so crazy dense there is in fact only a single pixel of gap between each board.

Now that I understand what you mean, yeah, this is a bug but fixing it will require making an entirely new ring simulation specifically for the 36-LED setup.

Toy203 commented 2 months ago

I can't believe I might be right again on this thing, honestly! XD

DustinGrau commented 2 months ago

The issue comes down to the distance between the pixels which are nearly double the resolution. So if a "particle" made a revolution once per second around a circle with a 125mm diameter, the calculations would need to be adjusted to account for the difference in steps:

What we need to do is crunch the numbers based on which device is selected and account for the time to spend illuminating each pixel--including the ones you wouldn't see (that's part of the "simulated ring" effect). However, as I'm thinking about this and looking at the calculations, that 13ms is approaching the limits of human vision and that's at normal speed--we still have the multiplier that speeds up the spin during use. So I wonder if using a single pixel on the denser components may not be giving the same visual effect. Perhaps what we should look at is not just reducing the delay between pixels but also making sure we fade out behind the lead pixel by 1-2 pixels (as half and quarter brightness, respectively).

DustinGrau commented 2 months ago

And it appears that the circumference really doesn't have a bearing on the calculation, it's more a matter of how long do you want it to take to complete a revolution. I happened to pick 1 second as an example, but the end result is just dividing the time by the number of steps. This might actually solve the other request which was to adjust the speed of the revolutions. The current code somewhat works backwards to use a base delay during the ramp-up and does some math as the ramping increases to full speed, then uses a constant divisor to increment. If we were to switch to a "steps per revolution" we could then simply set the time and work backwards based on the density of the lights.

nomakewan commented 2 months ago

Much like the Frutto barrel, I do definitely agree that we are not presently using the insane pixel density of the Frutto 36-LED arrays properly, and that working in finer animation techniques such as fading to create a "trail" effect for the whizzing particles would really make this particular unit pop. In fact the lack of a trail is one of the things I'd always wanted to see if we could do something about!

That said, I already have a potential solution that at least fixes the incorrect gap between lenses. @Toy203 please check your FB messages if you can!

Methinks a lot of LED-related code in both the wand and pack are going to need rebuilding from the ground up come v6.0.x. It'll take a lot of time and effort, but with these amazing new boards from Frutto, boy will it be worth it...

Toy203 commented 2 months ago

I'm Mario Toy Rossi over at fb, feel free to reach out when you like. =)

DustinGrau commented 2 months ago

If we can get this "close enough" on the next update, I've got some ideas for testing out code to make the animation more modular so it could be applied to either the cake or lid lights. Since both work similarly, it would be nice to know the same code does the same calculations for each.