Intensity meter only works on small section of wave

[arnabp]

When the light hits a strong dense medium at a sharp angle, the total area covered by the wave is larger, but the area where the intensity meters works is not, making it so that you can cover the entire intensity meter in the wave and still have it detect nothing. This is not true for the speed and time meters.

[arouinfar]

It looks like the intensity meter is pickier about being more centrally located in the beam. These screenshots show closet the meter can get to the edge of the beam before it ceases to work:

[ChandrashekarBemagoni]

Currently it's matching java version.Assigning to @arouinfar for verification

[arouinfar]

@ChandrashekarBemagoni is correct. The behavior currently matches the Java sim.

@ariel-phet, is this something we would like to address when PhET takes over the development?

[arouinfar]

@ariel-phet, do you think this is something worth assigning to @samreid to handle before publication?

[samreid]

@arouinfar are you thinking that it would be best for the beam to be intercepted if any part of it hits the intensity meter? What do you recommend specifically?

[arouinfar]

Yes, I was thinking along those lines @samreid. The current behavior isn't sensitive enough, and users may think the sim is buggy in the scenario shown in @arnabp's screenshot.

[samreid]

It looks like one way to reach this goal will be to simulate multiple parallel rays when in wave mode and check each for intersections in addAndAbsorb. Alternatively, we could try for a shape/shape intersection, but that may be more difficult to decide where to truncate the wave.

[samreid]

I thought it would work to change like so:

    getIntersections: function( sensorRegion, flipRay ) {
      var ray = flipRay ?
                new Ray2( this.tip, Vector2.createPolar( 1, this.getAngle() + Math.PI ) ) :
                new Ray2( this.tail, Vector2.createPolar( 1, this.getAngle() ) );
      if ( this.waveShape ) {
        return this.waveShape.intersection( ray );
      }
      else {
        return sensorRegion.intersection( ray );
      }
    },

and

    addAndAbsorb: function( ray ) {

      // find intersection points with the intensity sensor
      var intersects = ray.getIntersections( this.intensityMeter.getSensorShape(), false );

      // if it intersected, then absorb the ray
      var rayAbsorbed = intersects.length > 0;
      if ( rayAbsorbed ) {
        var x;
        var y;
        if ( intersects.length === 1 ) {

          var intersectPointAtSensorStart = ray.getIntersections( this.intensityMeter.getSensorShape(), true );

          // intersect point at sensor shape start position when laser within sensor region
          x = intersectPointAtSensorStart[ 0 ].point.x + intersects[ 0 ].point.x;
          y = intersectPointAtSensorStart[ 0 ].point.y + intersects[ 0 ].point.y;
        }

But it is not working properly.

[samreid]

My mistake. To use the above, I would have to do a shape/shape intersection, not shape/ray. I'm not sure if kite shapes support shape/shape intersections at the moment.

[samreid]

Basic support is above. Next steps necessary:

1. find the intersection closest to the ray tail (not closest to center of ray)--this should address discontinuities when dragging the sensor across a wide wave
2. test performance on iPad and fine tune the number of parallel rays to keep performance acceptable.

[samreid]

I found an analytic solution, and implemented it above (I should note that the iterative approach was fast enough on the iPad3, so the analytic solution probably is as well.). Now there is just a problem where the incoming ray is being intercepted past the origin.

[samreid]

I think I have it working well now with the exception of one discontinuity when the sensor regions goes from one to two intersections, here's a movie about it:

Notice that the light ray jumps from the edge of the sensor to the middle of the sensor. I think it may be technically feasible to solve this, with a couple of hours of work, but I'm not sure that it is justified since I don't believe the discontinuity will cause any distractions or misconceptions. Reassigned to @ariel-phet to get another opinion. Here's a testable link: http://www.colorado.edu/physics/phet/dev/html/bending-light/1.0.0-dev.18/bending-light_en.html

Please review the behvaior in the 1st screen only, the 3nd screen still has issues from #171

[ariel-phet]

It feels a touch buggy, but I think the use case you are showing is pretty rare. Lets close the issue and see if one of the testers reports it (or an issue related that requires tweaking).