Closed Nancy-Salpepi closed 11 months ago
Adding a proton and neutron at the same time causes the isotope present to shift one spot to the right and then one spot up on the nuclide chart. The equation that flashes, is the isotope that results after the shift to the right.
https://github.com/phetsims/qa/assets/87318828/b0741d2b-3f51-48bf-b603-56ae1d66c103
@ariel-phet had a great idea. Instead of making consistent animation speed to the destination, let's make a consistent animation time. So all animations take the same amount of time. Many animations presented as pretty long anyways. Let's start around 2 seconds or less.
I think this is the right path forward. We now have consistent animation time, and the speed changes depending on the distance. This was a bit more complicated by the fact that animation can change for incoming particles when reconfiguring an atom (when adding multiple at once), and so we sometimes don't want this consistency. It is a bit hard to explain, but you can get a case where a particle was just added, and one is only 10 pixels away from being done, but during reconfiguration the animationVelocity is reset. We don't want that small animation to take a second too.
Also when all 6 particles "smoosh" together and lock in, that should be speedy, and not play into this time-consistency.
@ariel-phet will you please review on main and let me know how this feels to you?
I just saw that outgoing decay particles are also using this constant time. Let's change that!
I also saw that the velocity of particles (particle1) that were still incoming were changing back to "normal" speed if a particle2 made it to the atom while particle1 was still animating. (upon reconfigure). Those two bug fixes really helped this feature, but maybe there are more that others will find.
@zepumph - just looked on main, and the current version looks great to me. I see no flickering of the equation, and the consistent animation time of particles feels very natural to me.
Well done!
@Nancy-Salpepi can you please test these animations kinda specifically. I am nervous that some of the animation cases may have gotten weird since animations to and from the particle creators and the particleAtom are all .75 seconds long.
Thanks so much for your help here.
- Is .75 seconds the right time for most/all cases?
I'm not sure if making the time shorter than .75 seconds would make particles that need to travel larger distances move too fast.
- Are there cases that should have consistent time but are still constant velocity animation (i.e. the decay particles emitted from the atom like electrons).
@ariel-phet, we are a bit stuck here. With a constant time of .75 seconds, most everything is good except when you return a particle that is really close to the creator nodes. But we can't change the timing for traveling to the first energy level without updating all (to fix the original bug). Will you please experiment with releasing dragged particles close to the creator node to slowly animate home and let me know if you want to do anything to manage this?
@zepumph @Nancy-Salpepi
I do not think the slow time releasing a particle near the creator node is a problem. Is it a bit slow returning...yes. However, I don't foresee that creating any pedagogical or interaction issues.
As for the first energy level, I do think that could be a bit faster. I would consider speeding the constant up to 0.6 or even 0.5 for everything. Basically, I think everything could be a bit faster which would alleviate some of @Nancy-Salpepi concern about the lowest energy level.
That being said, I do think the sim is acceptable as is currently. If a bit faster works in all cases and is an easy test, might be a good polish.
I totally agree. And I really liked 0.6.
0.5 definitely felt a bit fast to me.
@Nancy-Salpepi, what do you think? Anything else here?
@zepumph unfortunately the flashing is back for me (very noticeable when slowly pressing the add proton + neutron button 3 times).
@zepumph and I tried to reproduce this on our devices but were barely able to. Testing it with a slow CPU and normal CPU, we could reproduce it maybe about 1 out of 20 times. This new algorithm doesn't connect the two particles but it tries to make them arrive at the time, but the rounding errors in their position calculations can make them arrive in two different frames, causing the downstream flashing. It still seems like a big improvement from before, despite the flashing still being there. Thus we are ready to close, unless @Nancy-Salpepi you feel this is a huge setback to the usability of the sim.
Sometimes it occurs infrequently and sometimes it happens every 5 or 6 tries for me. It definitely isn't as bad as what I saw in the dev version. If you guys are OK with the current behavior, then you can close this issue.
Test device MacBook Air M1 chip
Operating System 13.5.1
Browser Safari 16.6
Problem description For https://github.com/phetsims/qa/issues/977 on the Chart Intro screen, pressing the Add Proton + Neutron button results in a brief flash of an equation in the Nuclide Chart Panel.
Steps to reproduce
Visuals
https://github.com/phetsims/qa/assets/87318828/bd688cca-1795-4fc7-9068-5965bfd1a3c0