Replace vertex bounds constraints with a constraint that you cannot create a concave shape

[jessegreenberg]

We talked about how to do this. One way would be to limit the angles so that each cannot be greater than 180 degrees. Another approach would be to limit such that a vertex cannot cross a line.

[brettfiedler]

Copying from the meeting notes/Zoom chat for log purposes:

BF: Just as a note - none of our parallelism focused sonifications will give you much of anything in the concave shape world. So, it'll come down to: Do (we) think that is a case worth exploring for a user to figure out or prove their theories on the model? Can ask Sofia and Dor.

EM: I think we should note any decision with respect to the design of the model that precludes the concave shapes, and proceed with excluding these shapes. That way, in the future if we want a version that allows this, it’s clear to all what’s needed (in the model) to do it, but I do not think we want to support the creation of these concave shapes. I think it’s a non-trivial, but challengingly subtle, kind of geometry and we want to keep things as simple as possible for as long as possible.

Another thought to log (not to act on atm):

• Worth considering down the line how the tangible/sim coupling responds to either of these constraints. Degrees of freedom for the CHROME Lab 3D printed quad are less than say a decoupled 4 sensor tangible (e.g., rings or tabletop markers), so while the angle restriction will likely not intrude on the former, it might be more evident in the latter.

[jessegreenberg]

What if we still had four quadrants but the size of quadrants changed as other vertices moved. For example as the top right vertex moves to the left, it reduces the available horizontal space for the top left vertex. This way the top left vertex could never go farther right than the top right vertex. Kind of like a 2D GFL:B.

[jessegreenberg]

I don't think "concave" vs "convex" is really what we should be thinking about. Its that we don't want to "twist" a shape and have one vertex cross beyond another. I am not sure what this is called geometrically...

EDIT: it seems like this is what we want to avoid:

[brettfiedler]

What if we still had four quadrants but the size of quadrants changed as other vertices moved. For example as the top right vertex moves to the left, it reduces the available horizontal space for the top left vertex. This way the top left vertex could never go farther right than the top right vertex. Kind of like a 2D GFL:B.

I think I am having a hard time imagining this. We might need to chat or sketch it out quickly... I think this might create more confusing walls as you move multiple points or rotate sides? But I am not sure.

[jessegreenberg]

Im still kind of thinking out loud here...But I was thinking it would work like this, just considering Vertex1:

Vertex1 cannot go below P4 vertically, and cannot go beyond p2 horizontally. Say the shape changed a bit:

Same rules apply, different set of bounds constraining Vertex1. I think we only run into problems if Vertex1 can go below vertex3 or go to the right of Vertex2.

[brettfiedler]

Yeah, I believe I made a much more confusing, complete version of that. I think it maybe creates confusing boundaries because I still can't arbitrarily create the concave shapes, though there is much more play than before.

[deleted image, too confusing]

[brettfiedler]

For simplicity, let's just go with the angle restriction for now. Especially after the discussion during the sound design meeting.

Perhaps some give as well (178/2 degrees? Vs. 180/0 degrees)

Edit: Jesse and I met briefly after this to discuss the downfalls of an angle based approach and determined a potentially easier solution that is also simpler to integrate based on irregular regions instead of rigid right angle quadrants (see below).

[brettfiedler]

Initial shape:

After movement into disallowed zone:

JG Edit: These images demonstrate that the proposal in https://github.com/phetsims/quadrilateral/issues/15#issuecomment-946999626 will not work because even with those bounds constraints it is possible for the quadrilateral sides to cross.

[brettfiedler]

COnfiguration that "works" by preventing crossing:

This essentially requires calculating which vertex is the limiting one at any given moment (generally closest to the center, in this case the red vertex) and creating disallowable zones based on its position. Even after figuring out how to do that, it still limits the movement of a vertex unpredictably (though with more play area than with rigid quadrants)

[brettfiedler]

Possible solution of irregular boundaries that is easier to develop than angle restriction:

[jessegreenberg]

Made some progress in the above commits but it isn't general enough and will break when the vertices rotate more than 90 degrees around the center of the screen. Will need to come back to this later. Progress is in a branch shapeWIP.

[brettfiedler]

For posterity, I wanted to quickly edit the above illustrations to something more than Jesse and I could understand :)

Ideally, this scheme would allow free rotation. Unclear how it performs when multiple vertices are moving and how resource intensive it may be.

[jessegreenberg]

I got this working well enough to see a potential issue when vertices change to create a concave shape. For example, we have this area for vertex2:

But when vertex2 is dragged down so that it becomes concave the bounds for vertex1 change:

So I think this algorithm will effectively disallow concave shapes.

[jessegreenberg]

@BLFiedler this can be tested at https://phet-dev.colorado.edu/html/quadrilateral/1.0.0-dev.7/phet/quadrilateral_en_phet.html?showVertices&showPointerAreas&showDragAreas. Do you have any thoughts about how to handle this? EDIT: Its prototypy and buggy, beware!

[jessegreenberg]

Perhaps one way would be to disallow concave quadrilaterals by creating a shape between connected vertices like this:

I think this has similar behavior as https://github.com/phetsims/quadrilateral/issues/15#issuecomment-947719793 but it does prevent concave shapes.

[brettfiedler]

Will need to flesh this out later - but let's discuss your last comment and this idea. Effectively adding the bisector of the adjacent vertices as an allowable area. Opens up some weirder "irregular quadrilaterals". The possible uncomfortable zone I've darkened where you can make overlapping lines.

[brettfiedler]

JG and I met to discuss. The following, after verifying a few cases, appears to be a proper solution for all convex and concave quadrilaterals.

On the side of the vertex of control, the allowable regions are bounded by:

• The lines formed by the opposite vertex and adjacent vertices (i.e., the sides not connected to the vertex of control)
• Lines radially outward from the adjacent vertices to the play area along the line formed by the adjacent vertices.

1. Example for a convex quadrilateral for the red vertex:
2. Example for a concave quadrilateral for the red vertex:
3. Example for the same concave quadrilateral for the green vertex:
4. Example 1 with previous bound overlayed to highlight new allowable areas:

[jessegreenberg]

The above commit implements what is described in https://github.com/phetsims/quadrilateral/issues/15#issuecomment-961184570. It works pretty well, but there is a breaking case when there is a concave shape:

@BLFiedler can you check the shapes, did I get the shape for the bottom right vertex wrong, or do we need to reconsider the approach? Here is a dev version to test as well: https://phet-dev.colorado.edu/html/quadrilateral/1.0.0-dev.8/phet/quadrilateral_en_phet.html?showVertices&showDragAreas

[jessegreenberg]

During meeting today we discussed a solution to this where if the angle of the opposite vertex is greater than 180 degrees, we need to constrain the drag area to something that will not allow twisted quadrilaterals. For example, when concave, the drag area for vertex1 will look like this:

IN this case, a ray is formed from vertex2 to vertex3 and a ray is formed between vertex4 and vertex3 which intersect with the model boundaries and create a shape that will prevent twisting.

When convex, the area is quite a bit larger as described in https://github.com/phetsims/quadrilateral/issues/15#issuecomment-961184570.

@BLFiedler can you please review this in https://phet-dev.colorado.edu/html/quadrilateral/1.0.0-dev.9/phet/quadrilateral_en_phet.html?showDragAreas&showPointerAreas You can drag a side to see the drag areas of both connected vertices change at the same time

---

Edit by @BLFiedler for archival purposes:

[brettfiedler]

This is beautiful and makes for a very trippy experience. Tested via cursor, keyboard, and iPad touchscreen (2 & 4 fingers). I was not able to break it myself. It did not interrupt any of the parallel maintenance movements. The only time it is obvious is during single vertex manipulation and especially when trying to rotate the entire shape using only single vertices (this is not a problem, only a note).

Keeping issue open to discuss @ Thursday meeting & virtual model meeting. Specifically, I would like to know thoughts on allowing a vertex to make a line with another vertex.

[brettfiedler]

Let's make a pass on giving the lines a defined width in model space and preventing overlap of vertices and lines.

[jessegreenberg]

I have an initial pass at changing the Sides so that they have model bounds and adding their intersection to the calculation of allowable shapes. But somehow it is is possible now to get crossed shapes:

Ill return to this part next time.

[jessegreenberg]

This bug is unrelated to these changes. Here it is again where the bottom right vertex crosses. It seems to be that a position perfectly vertically aligned with another vertex.

[jessegreenberg]

I started https://github.com/phetsims/quadrilateral/issues/39 this bug is unrelated to the changes here.

[jessegreenberg]

I have a workaround in place for #39, and opened an issue in kite to investigate the identified problem in that repo.

Back to https://github.com/phetsims/quadrilateral/issues/15#issuecomment-970580310...

This should be done, can you please verify @BLFiedler? IS there anything else you would like for this issue?

[brettfiedler]

A couple of points to bring up at our meeting today:

• "Stickiness" of vertex when it meets a boundary during drag
• Side overlap with adjacent vertex

[brettfiedler]

Oops - also found a crash. Placing in this issue for now. Happens whenever a vertex means the leftmost play area boundary (by keyboard, touch, and cursor) - (on Chrome & Edge (Win10) and Chrome (iPad))

[jessegreenberg]

I believe the crashing is fixed with the above commit.

[brettfiedler]

We concluded in the meeting that there should not be overlap with sides and vertices, even for those not currently being dragged to avoid the situation pictured in https://github.com/phetsims/quadrilateral/issues/15#issuecomment-1009981737

However, side overlap that occurs when a concave shape is alright.

After this addition, this issue can be closed.

[jessegreenberg]

I spent a few hours on this issue this morning, I ran into the issue again where the entire shape instead of just the proposed position for the vertex (https://github.com/phetsims/quadrilateral/issues/33) - I replaced the function with isQuadrilateralShapeAllowed so we can verify all of the requirements of the shape when we change it instead of just verifying the position of a vertex.

It is working pretty well but for some reason vertex 3 cannot move beyond this position vertically:

[jessegreenberg]

Ah, I think this is the same issue as https://github.com/phetsims/quadrilateral/issues/39. That explains why it is only an issue for the third vertex.

[jessegreenberg]

OK done in the above commit. @BLFiedler is there anything else for this issue? One thing I am feel is that the "stickiness" is really noticeable along this constraint as well (#41).

[brettfiedler]

I think this is instantiated for the purpose of this issue. The stickiness issue can continue over in #41