Thanks

[BNNorman]

Just a quick thanks for this - I'm hoping to use it to generate a starry night scene with twinkling stars for a RGB LED matrix.

Did you get anywhere with adapting to use numpy?

Many Thanks
Brian

[IHautaI]

Hi Brian, Glad to hear it's getting some use! I did not get anywhere with that, I started working on it between jobs and lost track of it once I found one. If you decide to try that route it shouldn't be too bad!

…

On Wed, Dec 6, 2017 at 11:58 AM, Brian ***@***.***> wrote: Just a quick thanks for this - I'm hoping to use it to generate a starry night scene with twinkling stars for a RGB LED matrix. Did you get anywhere with adapting to use numpy? Many Thanks Brian — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAOj-okYH8YQr0UM71BBDt5ZCoJkP8gks5s9sefgaJpZM4Q4QKO> .

[BNNorman]

Understood.
If I get time I'll try to convert to numpy myself. The distribution works nicely but I thought it maybe ran a bit too slow for high FPS in animations on my 64x64 LED RGB matrix where I want the selection to change to immitate a shimmering/sparkling effect. If the RGB panel gets even bigger speed becomes even more important (I used a radius of 10 to reduce the number of coordinate pairs returned).
Anyway, thanks again.

[IHautaI]

If I end up revisiting I'll do the main portion in C/C++. Hopefully numpy will get you enough speed! On Dec 7, 2017 3:50 AM, "Brian" <[email protected]> wrote: Understood. If I get time I'll try to convert to numpy myself. The distribution works nicely but I thought it maybe ran a bit too slow for high FPS in animations on my 64x64 LED RGB matrix where I want the selection to change to immitate a shimmering/sparkling effect. If the RGB panel gets even bigger speed becomes even more important (I used a radius of 10 to reduce the number of coordinate pairs returned). Anyway, thanks again. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAOj0f8_0UvXJvqpwEiQyRBAAPxyTrDks5s96bagaJpZM4Q4QKO> .

[IHautaI]

Hi, I've done a quick look-through on the code. You may want to look at how neighbors are calculated. In the 2D case you can simplify this stuff a lot and it should get faster. For example, you could precalculate the relative coordinates of neighbors based on the chosen radius, then you don't have to search the 'self.cells' for neighbors - just look up the ones you need to check directly. Another thing you could do: Generate an offset (x, y) randomly, then use point + (x, y), point + (-x, -y), point + (-x, y), point + (x, -y), point + (y, x), point + (y, -x) , etc to search around the point in question instead of just generating a new random point if the first option doesn't work. Might be a little faster, fewer calls into random number generation.

…

On Thu, Dec 7, 2017 at 8:42 AM, Jeremy Gresham ***@***.***> wrote: If I end up revisiting I'll do the main portion in C/C++. Hopefully numpy will get you enough speed! On Dec 7, 2017 3:50 AM, "Brian" ***@***.***> wrote: Understood. If I get time I'll try to convert to numpy myself. The distribution works nicely but I thought it maybe ran a bit too slow for high FPS in animations on my 64x64 LED RGB matrix where I want the selection to change to immitate a shimmering/sparkling effect. If the RGB panel gets even bigger speed becomes even more important (I used a radius of 10 to reduce the number of coordinate pairs returned). Anyway, thanks again. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAOj0f8_0UvXJvqpwEiQyRBAAPxyTrDks5s96bagaJpZM4Q4QKO> .

[BNNorman]

Thanks for that. Still debugging and documenting my project so will be a while before i can delve. I did see someone has a similar project based on numpy arrays on github.

…

On 18 Dec 2017 9:36 pm, "IHautaI" ***@***.***> wrote: Hi, I've done a quick look-through on the code. You may want to look at how neighbors are calculated. In the 2D case you can simplify this stuff a lot and it should get faster. For example, you could precalculate the relative coordinates of neighbors based on the chosen radius, then you don't have to search the 'self.cells' for neighbors - just look up the ones you need to check directly. Another thing you could do: Generate an offset (x, y) randomly, then use point + (x, y), point + (-x, -y), point + (-x, y), point + (x, -y), point + (y, x), point + (y, -x) , etc to search around the point in question instead of just generating a new random point if the first option doesn't work. Might be a little faster, fewer calls into random number generation. On Thu, Dec 7, 2017 at 8:42 AM, Jeremy Gresham ***@***.***> wrote: > If I end up revisiting I'll do the main portion in C/C++. Hopefully numpy > will get you enough speed! > > On Dec 7, 2017 3:50 AM, "Brian" ***@***.***> wrote: > > Understood. > If I get time I'll try to convert to numpy myself. The distribution works > nicely but I thought it maybe ran a bit too slow for high FPS in animations > on my 64x64 LED RGB matrix where I want the selection to change to immitate > a shimmering/sparkling effect. If the RGB panel gets even bigger speed > becomes even more important (I used a radius of 10 to reduce the number of > coordinate pairs returned). > Anyway, thanks again. > > — > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > <#1 (comment) >, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AFAOj0f8_ 0UvXJvqpwEiQyRBAAPxyTrDks5s96bagaJpZM4Q4QKO> > . > > > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APHW3UbqsEQvOpyqgshTErWJ2RX8blq1ks5tBtrogaJpZM4Q4QKO> .