phetsims / build-a-nucleus

"Build a Nucleus" is an educational simulation in HTML5, by PhET Interactive Simulations.
GNU General Public License v3.0
0 stars 5 forks source link

Equation briefly flashes when adding particles #193

Closed Nancy-Salpepi closed 11 months ago

Nancy-Salpepi commented 12 months ago

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

  1. On the Chart Intro Screen, switch to the second scene
  2. Slowly press the Add Proton + Neutron button

Visuals

https://github.com/phetsims/qa/assets/87318828/bd688cca-1795-4fc7-9068-5965bfd1a3c0

Troubleshooting information: !!!!! DO NOT EDIT !!!!! Name: ‪Build a Nucleus‬ URL: https://phet-dev.colorado.edu/html/build-a-nucleus/1.0.0-dev.23/phet/build-a-nucleus_all_phet.html Version: 1.0.0-dev.23 2023-09-12 15:57:17 UTC Features missing: applicationcache, applicationcache, touch Flags: pixelRatioScaling User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Safari/605.1.15 Language: en-US Window: 1317x706 Pixel Ratio: 2/1 WebGL: WebGL 1.0 GLSL: WebGL GLSL ES 1.0 (1.0) Vendor: WebKit (WebKit WebGL) Vertex: attribs: 16 varying: 30 uniform: 1024 Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32) Max viewport: 16384x16384 OES_texture_float: true Dependencies JSON: {}
Nancy-Salpepi commented 12 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

zepumph commented 12 months ago

@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.

zepumph commented 11 months ago

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?

zepumph commented 11 months ago

I just saw that outgoing decay particles are also using this constant time. Let's change that!

zepumph commented 11 months ago

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.

ariel-phet commented 11 months ago

@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!

zepumph commented 11 months ago

@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.

  1. Is .75 seconds the right time for most/all cases? https://github.com/phetsims/build-a-nucleus/blob/5ba8c7d6b38fa5c9f030c7966eb18d55e5edbfc4/js/common/model/BANParticle.ts#L15
  2. 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).
  3. Are there cases that should NOT have consistent time but since this change do, and seem weird.

Thanks so much for your help here.

Nancy-Salpepi commented 11 months ago
  1. 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.

  1. 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).
zepumph commented 11 months ago

@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?

ariel-phet commented 11 months ago

@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.

zepumph commented 11 months ago

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?

Nancy-Salpepi commented 11 months ago

@zepumph unfortunately the flashing is back for me (very noticeable when slowly pressing the add proton + neutron button 3 times).

Luisav1 commented 11 months ago

@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.

Nancy-Salpepi commented 11 months ago

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.