Rogue Laser Beam Behavior

[EthanWJohnson]

Tested on: Chrome, Firefox, Edge,

OS: Windows 10

Description: On the multiple lasers mode of the prism module, whether or not the central laser beam is covered changes the behavior of lasers not covered by the beam

Related gif:

Drag any prism into the path of the laser beams. Drag another so it covers the emitter of the central beam. The beams not covered will act as though they are covered.

NOTE: This also occurs on the currently published sim on the website.

WHY THIS MAY BE OCCURING: The central beam seems to be acting as a guide laser, in a sense, regarding whether the emitter is covered. When it is covered, it tells the other lasers that they are also covered--even if they're not, and thus telling them to ignore the first prism wall/refraction they come across. (as hypothesized by @phet-steele )

As above, it can lead to things like total internal reflection under conditions that should be impossible.

Referenced Test: phetsims/tasks#682

Debug Information:
Troubleshooting information (do not edit):
Name: ‪Bending Light‬
URL: http://www.colorado.edu/physics/phet/dev/html/bending-light/1.1.0-rc.1/bending-light_en.html
Version: 1.1.0-rc.1 2016-08-22 20:48:08 UTC
Features missing: touch
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Language: en-US
Window: 1366x648
Pixel Ratio: 1/1
WebGL: WebGL 1.0 (OpenGL ES 2.0 Chromium)
GLSL: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium)
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: {"assert":{"sha":"7d27130a","branch":"HEAD"},"axon":{"sha":"1fd91832","branch":"HEAD"},"babel":{"sha":"5e625a61","branch":"master"},"bending-light":{"sha":"09962afa","branch":"HEAD"},"brand":{"sha":"f0b1f7da","branch":"HEAD"},"chipper":{"sha":"136b1d30","branch":"HEAD"},"dot":{"sha":"6e8a26f2","branch":"HEAD"},"joist":{"sha":"ab5582ab","branch":"HEAD"},"kite":{"sha":"88f0c3a0","branch":"HEAD"},"phet-core":{"sha":"c48bf320","branch":"HEAD"},"phetcommon":{"sha":"83ea84c8","branch":"HEAD"},"scenery":{"sha":"0ab22ac3","branch":"HEAD"},"scenery-phet":{"sha":"04cec216","branch":"HEAD"},"sherpa":{"sha":"5ddfccd4","branch":"HEAD"},"sun":{"sha":"061f2ea9","branch":"HEAD"},"tandem":{"sha":"43ebdfb3","branch":"HEAD"}}

[samreid]

@ariel-phet also could you help prioritize/schedule this work?

[ariel-phet]

Note, this behavior only happens when the object is close to the output of the laser, a bit further away and everything works as expected.

Still the issue should be addressed. However, marking priority deferred until we can get a chunk of @samreid time