Rays should look like they're passing through things.

[sarchang]

(This comment was edited by @pixelzoom.)

The optical axis should appear to poke through the object and the image (real and virtual).

The optical axis should also appear to poke through the projection screen, to prevent a 3D optical illusion effect.

Ditto for rays.

This should not apply to light sources.

[pixelzoom]

In #109 (comment), @veillette said:

In order to give 3D perspective, it was suggested that the object and images be split in half vertically, where each half would be on a different z layer. The optical axis and rays could then be allow to fit within the two z-layers to give a sense of depth.

The flash simulation uses a similar approach with the projector screen (but not the images).

[pixelzoom]

10/21/2021 design meeting: @arouinfar @kathy-phet @ariel-phet

Splitting each object, image, and projection screen into 2 Nodes is going to be quite a mess. I'm speaking from experience, since I did this in Faraday's Electromagnetic Lab.

I'm going to investigate another approach, where the optical axis and rays are split into multiple Nodes. The optical axis seems straightforward, the rays wil be tricky.

[pixelzoom]

Moving the optical axis part of this to #283, since it's going to be a separate chunk of work.

[pixelzoom]

From #283 (comment):

• For rays in Rays should look like they're passing through things. #125:
  • For real image, use this same approach.
  • For virtual image, do nothing. Do not want the rays to look like they're going through the (solid) object.
  • For projection screen, do nothing, the current look is desired.

[pixelzoom]

Similar to what I did in #283 with OpticalAxisForegroundNode extends OpticalAxisNode ....

Create class LightRaysForegroundNode extends LightRaysNode. Use clipArea: null for virtual image and projection screen. For real image, set clipArea to everything to the left of the image's position.

Then in GOScreenView.js:

const lightRays1Node = new LightRaysNode( ... );
const lightRays2Node = new LightRaysNode( ... );
const lightRays1ForegroundNode = new LightRaysForegroundNode( ... );
const lightRays2ForegroundNode = new LightRaysForegroundNode( ... );

... and adjust the rendering order.

[pixelzoom]

In the above commit, I did what I described in #125 (comment). ?debugRays renders the foreground rays with 'red' stroke.

This is looking pretty nice imo:

[pixelzoom]

@arouinfar This is ready for review in master. The current opacity of the image mask is 0.8. Let me know if you'd like to see more or less of the occluded rays. Note that this opacity will also affect how much of the occluded optical axis is seen.

[pixelzoom]

The problem noted in #125 (comment) is due to the clipArea not being properly transformed (translated and scaled). In the above commit, I added rendering of the clipArea with ?debugRays, and this is what it looks like (red rectangle). Rays in red are the foreground rays, inside the clipArea.

This was indeed a problem in 1.1.0-dev.14 and earlier, but only noticeable when you zoomed out. Here's ?debugRays in 1.1.0-dev.14, when zoomed out. clipArea rendering had not been added in this version, but the red rays are the ones the are inside the clipArea.

So it's not worth reverting a9b9e6a for #277 to address this. It was broken before that change was made, just less obvious.

[pixelzoom]

The problem noted in #125 (comment) is fixed in the above commits, published in 1.1.0-dev.17.

Assigned to @arouinfar for guidance on the cases where a ray appears to pass in front of the Object, as shown in #125 (comment). What would make the most sense to me is to have the rays stop at the Object. But that would require significant changes to the ray-tracing code - which I have so far managed not to touch much.

[ariel-phet]

@pixelzoom for the problems noted in #125 (comment) I think only the 2nd and 3rd case are egregious. However, in those case I do think the most correct thing would be to have the rays stop at the object, despite the unfortunate nature of modifications to the ray-tracing code.

[pixelzoom]

1/20/22 design meeting:

We all agreed that it would be preferable to not have rays going through the Object. But this could be costly, and would also involve adding information about the height (bisector line) of the framed objects. I'll do 1-2 hours of exploration and report back.

[pixelzoom]

In LightRay.js, here's the code that handles termination of a ray on the projection screen. Terminating a ray on the Object would probably involve something similar.

    // If we have a projection screen, check whether the last ray intersects the projection screen,
    // and therefore terminates at the projection screen.
    if ( projectionScreen ) {
      setFinalPointOnProjectionScreen( this.realRays, projectionScreen.getBisectorLineTranslated() );
    }

[pixelzoom]

We all agreed that it would be preferable to not have rays going through the Object. But this could be costly, and would also involve adding information about the height (bisector line) of the framed objects. I'll do 1-2 hours of exploration and report back.

It wasn't too difficult to locate the relevant ray-tracing code, and clean it up so that it could be used to terminate rays at the Projection Screen or the Object.

There are 2 additional changes that would need to be made in order to terminate rays that intersect the Object:

• add a bisection line for "framed objects" to the model (non-trivial)
• modify the ray clipArea used for mirrors (relatively easy)

Before making any big changes, I added a hard-coded bisection line, just so I could see what it looks like. And what I saw concerned me. The representation for rays has no directionality, and you only see directionality when rays animate (when changing Rays radio buttons, or pressing Show/Hide button). So when looking at the static "picture", reflected rays that stop at the Object might be misinterpreted as rays that originate from the Object.

Below are screenshot for 2 scenarios, comparing "Object blocks reflected rays" vs "Reflected rays pass in front of Object".

I discussed this with @arouinfar. She doesn't want to add directional indicators (e.g. arrows) to the rays, and I agree. While both approaches have problems, "reflected rays pass in front of Object" seems to be the less-problematic approach, and could be noted in Teacher Tips. So we're inclined to allow reflected arrays to pass in front of Objects.

@ariel-phet @kathy-phet do you agree?

---

SCENARIO 1: Concave Mirror

Object blocks reflected rays:

Reflected rays pass in front of Object:

---

SCENARIO 2: Convex Mirror

Object blocks reflected rays:

Reflected rays pass in front of Object:

[pixelzoom]

If you'd like to test-drive the "Object blocks reflected rays" approach, see 1.1.0-dev.18.

I reverted 75cf430 after publishing 1.1.0-dev.18.

[pixelzoom]

@arouinfar if you're confident about our decisions in #125 (comment), then there is nothing left to do, and you can close this issue. Or we can leave it open until @ariel-phet and @kathy-phet weigh in. Your call.

[arouinfar]

@pixelzoom I am confident in our decision to allow reflected rays to pass over the object. I've made a note to document this behavior in the Teacher Tips, so I'll go ahead and close.