0005674: Why doesn't heading = forwardDirection + rotationDegrees for all morphs all the time?

Notes
(0008768 - 1673 - 2056 - 2056 - 2056 - 2056 - 2056) wiz 12-30-06 01:22	Hmmm. that was easier than it should have been. >Ralph Johnson wrote: > 0005674: Why doesn't heading = forwardDirection + >> rotationDegrees for all morphs all the time? > >You could write a generic test that would take a morph, rotate it 22 >degrees, and then check that heading = forwardDirection + >rotationDegrees was still correct. If you could get a typical morph >of each type then you could test all morphs at once. Will >#initializedInstance be good enough for this? If you could make a set >of tests, fix the code to pass all the tests, and then let people play >with it for awhile and give good feedback, the release team would >almost certainly accept your changes. And your tests! > >-Ralph The result ( to date is MorphicBugz.1.st ) which demonstrates that all test classes violate the proposed invarience when tilted. headingReadout.gif is the explorer results from: rejects := cases reject: allAreInvariant . (rejects collect: [ :each \| { each . each heading . each forwardDirection . each rotationDegrees } ] ) explore . The two important things to note is that any turn breaks the relationship. And second, polygons and circle break it in a way totally different from Rectangles and ellipses. The invarient is kept by the renderers of the Rectangle and the Ellipse. On the tests: I had originally envisioned more comprehensive tests. Basically by making the test cases more intricate by embedding morphs in the test cases. I'm going to hold off there until a repair or remedy is available for this failure. I will consider the remedy in a separate note. Yours in service, -- Jerome Peace

(0008774 - 3005 - 3185 - 3185 - 3185 - 3185 - 3185) wiz 12-30-06 02:11	Discussion: Polygons and circles answer the same thing for forward direction as for rotation degrees and for heading. So they will never be kosher whenever they have been rotated. So how to handle? First, Polygons (and Circles) can have submorphs. If they are to be first class citizens then they need to behave visually as rectanges (and ellipses) with submorphs do when rotated by the blue handle. Currently tilting polygons do not affect their submorphs. While tilting rectangles also (thanks to the renderer) tilt the submorphs a similar amount. Furthermore tilting a rectangle moves (tilts) the reference points of the submorphs around the morphs reference point. The end result is the user sees a tilted object congruent to the original. When tilted the growth(yellow) handle turns orange (becoming a scale handle) . Using the scale handle will enlarge or shrink the tilted image keeping it congruent with the original. This breaks down for polygons. They do not rotate their submorphs. And they reference the location of the submorphs not to the polygon's reference point but to its bounds topleft. (Which changes as the polygons vertices are rotated about their reference point.) and so the submorphs move (annoyingly) when the polygon is rotated. So what I found is that I could fix this if the ref points of the submorphs get treated to the same transformation as the polygon vertices. And the submorphs get asked to change their heading by an amount equal to the tilt. A similar fix proved very useful for the yellow growth handle. When a morph is stretched also stretch the submorph ref points (relative to the owners ref point). This is astonishingly pleasing when dealing with a polygon representing a face and submorphs represent eyes, ears, nose and mouth. Now the above is a litte OT for this report which is considering the proposed invarient. But it also points to the crux of the problem. While Polygons can rotate themselves w/o a renderer. And therefore choose to use heading=forwardDirection=rotationDegrees, when they have submorphs they should care about the difference in meaning between forwardDirection (face is normal but moves sideways) vs. rotation degrees (face has been tilted) . There is probably a command somewhere that asks morphs to home themselves to a default position and orientation. The polygon now will not know how to do that properly. So my conclusion is that polygons should keep a distinction between forward direction and rotational tilt. and heading should be the sum of the two. Forward direction must get changed explicitly. (Either programaticly or by changing the arrow on the center handle). Rotational tilt gets changed when the morph and it's submorphs are is rotated. Adding, deleting or moving a vertex in a polygon would not change either of those values. And homing the morph would undo the rotation but not the forward direction. Enough analysis for one go. Yours in service, --Jerome Peace

Issue History
Date Modified	Username	Field	Change
12-27-06 06:39	wiz	New Issue
12-30-06 01:00	wiz	File Added: headingReadout.gif
12-30-06 01:03	wiz	File Added: MorphicBugz.1.st
12-30-06 01:22	wiz	Note Added: 0008768
12-30-06 02:11	wiz	Note Added: 0008774
07-05-07 00:54	wiz	Relationship added	related to 0005560
11-05-07 03:22	wiz	Relationship added	parent of 0006747