Pjh add linearbounce

[pjhatch]

Hi Aircookie. Love your project - thanks.

I added two modes to my project that you might like to include.
Ball track has a number of balls that "bounce" off the edges of the strip.
Ball track collision includes balls that collide with one another.

I need to continue working on the collision version - to handle cases when more than 1 collision occurs for a given ball in a single timestep. I'll keep you posted when this is done.

[HHHartmann]

This shouldn't be in a loop really.
BTW I think what you want to have here is a velocity from -5 to 5 but what you are calculating is -15 to -5 which would match the loop condition anyways.
EDIT: missed the (). It calculates something between -0,0005 and -10,0005

[pjhatch]

If the loop you are referring to is the "while" loop it is present to make sure the initialized velocities are not too close to zero.
Your right about the error in - I will update this to -.5+float(...) that will make this as I intended. Great to have another set of eyes. Let me test this and update.

[HHHartmann]

Maybe have something like this to avoid the loop

x = positive_value_in_range(); // x > 0,5 && x < 5 
if (random(0,1) < .5)
  x = -x;

The while loop with random can take infinite time, although it is not likely. But when running several times (once for each ball) it might sum up.
IMHO one should avoid it where possible.

I like the general idea though. I might implement it in the other project I am working on if you don't mind.

[pjhatch]

Thanks for the suggestion - this code concept is cleaner. No problem if you want to implement these ideas elsewhere.

[stale]

Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs.
Thank you for using WLED!

[pjhatch]

Dear Aircookie, I made some updates to my original version cleaning up some things suggested by HHartman. The effect I intended is working. Elastic ball collisions. If you do not want to accept the pull request, I’ll just keep my version around. Hope to add some more effects to this next year but I do worry about getting out of sync with the main project. Regards, pjhatch

…

On Dec 13, 2020, at 4:35 PM, stale[bot] ***@***.***> wrote:  Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs. Thank you for using WLED! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Def3nder]

Hi @pjhatch,

just a hint:
it's way easier for Aircooockie to check the code if the ONLY CHANGES are comming from your new code.

Now there are sooo many changes coming from I think automatic code clean-up ?!?
There are tons of white space deletions...

If you want to continue with this, I would suggest to copy your additions in fx.cpp and fx.h,
merge the latest upstream-master into your repository and then add your code again (and only your new code).

The effect number is another one right now - this should be changed - the rest could be copied 1:1.

...what do you think ?

[pjhatch]

Def3nder, That sounds good - I will do as you suggest - probably get to it this week. Regards, pjhatch

…

On Mon, Jan 4, 2021 at 10:33 AM Def3nder ***@***.***> wrote: Hi @pjhatch <https://github.com/pjhatch>, just a hint: it's way easier for Aircooockie to check the code if the ONLY CHANGES are comming from your new code. Now there are sooo many changes coming from I think automatic code clean-up ?!? There are tons of white space deletions... If you want to continue with this, I would suggest to copy your additions in fx.cpp and fx.h, merge the latest upstream-master into your repository and then add your code again (and only your new code). The effect number is another one right now - this should be changed - the rest could be copied 1:1. ...what do you think ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1039 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AP57PFGSHKTNJUKKTBA7OQTSYHUXDANCNFSM4OXZ2KTA> .

[stale]

Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs.
Thank you for using WLED!

[blazoncek]

@Aircoookie after 2 years this is ready to be merged.
@softhack007 if you can, please optimise it.

[softhack007]

@softhack007 if you can, please optimise it.

Wow, yes I see a lot of potential for optimizations.
Lots of floats that should not be there ... will take a look in the next days 👍

[softhack007]

Interesting effect :-)

After first look at the physics:

• initial conditions look right
• movement looks good
• momentum transfer at collision seems reasonable
• collision detection - well - needs improvements. Sometimes balls just cross each other without collision. Also the "last collision update time" does not make much sense to me --> i'll think of something in the next two weeks.
• float vs. fixed point: seems that I could change everything to fixed point: mass =8bit, positions = 32bit, velocities = 16bit. Needs some clever thinking still to find good fixpoint resolutions (i.e. decimal places need for accuracy).

[blazoncek]

@Aircoookie do you agree to merge this and optimise later?

[softhack007]

@Aircoookie do you agree to merge this and optimise later?

Makes sense, as the effect works basically, at least on esp32.

I have a few minor tweaks on my local PC, I can push them before or after merge.

There are some toDo's for optimizations and improving the math, however that would not change the basic look:

• there are some missed collisions right now, so I plan to revise the collision algo to make it more "n-body standard style"
• we can safe 4 bytes per "body" data as the "last bounce time" is an artefact of the cumbersome collision detection
• and finally everything can be changed to fixed point so it runs smoothly on slower MCU's.

I agree with blaz all this could be done after merge.

[softhack007]

Agreed to optimize after merge.

[blazoncek]

As I updated the original code to comply with 0.14 framework I am hardly a good reviewer. 😁

For TODO I would suggest to also include @ewoudwijma virtual strip approach to allow effect to play nicely on 2D matrices.

[blazoncek]

This could be changed to color_from_palette() to allow custom colored balls.

[softhack007]

Good point 👍 so we do this one, then merge into main
@Aircoookie ok for you, too?

[softhack007]

Merged 👍

For some unknown reason, github does not belief me ... well i'll find out later and fix it.
Could be due to "squash and merge" in GitHub Desktop.

[blazoncek]

Huh! You did a squash commit. That removed all history and removed code attribution and left this PR open.

[softhack007]

Huh! You did a squash commit. That removed all history and removed code attribution and left this PR open

Partly intended ... actually I wanted to it "squashed", so we don't have a two year commit history added into main.

Everything else was .... surprising.