Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005674 [Squeak] Morphic minor sometimes 12-27-06 06:39 11-05-07 03:22
Reporter wiz View Status public  
Assigned To
Priority normal Resolution open  
Status new   Product Version 3.9
Summary 0005674: Why doesn't heading = forwardDirection + rotationDegrees for all morphs all the time?
Description This is actually a MAJOR bug with a minor urgency.

This is an integration issue.

The meaning of heading forwardDirection and rotationDegrees varies between morph species
morphs (inflexible),
transformation (nothing but flex)
polygons and circles (self flexing)
matrixtransform, flash and truetypefonts ( ??? )

Since many of these interact with each other and all of them should be able to interact. There should be a consistent (non recursing) protocol aided by consistent definitions of these words and the referencePoints they depend upon.




Additional Information The only way to solve this is to come up with a consistent definition (not hard)
Publish it. (Where)
Get consensus (Good luck)
Repair and refactor and reinforce it in the code. (Ahhh)

My proposal for the definitions starts with the invariant

heading = forwardDirection + rotationDegrees

My understanding of the difference between the three words is:

Forward direction is the direction an unrotated object will go in when told forward.
You can have a rectangle that looks like a rectange. Set it forward direction to East.
It still looks like itself an unrotated rectangle. When tell forward it marches east instead of the default north.

Now you can take the blue halo handle and give the rectangle a tilt say 90 degress.
When you ask it to go forward in marches south.

Now our outside understanding of this is that it marches south because it has a forward direction of 90 degrees and its been tilted another 90 degrees.

Which brings me to the other two words.

Heading is the direction that it marches.
And rotation degrees is the amount of tilt. That is the difference between the direction and the forward direction.

There are various way that these notions break down in practice.

In particular a tilted rendee does not answer correctly when ask its rotation degrees because it relies on its owner for that data.

Polygons and circle don't remember they have been tilted because the always adjust the forward direction. This loses an important distinction.

The reason to fix this bug is once it has been tackled a clarity can be achieved that will disolve a great number of sticky bugs.

You can find most of them by searching mantis for the word rotation.

Yours in service, -- Jerome Peace



Attached Files  headingReadout.gif [^] (6,387 bytes) 12-30-06 01:00
 MorphicBugz.1.st [^] (1,618 bytes) 12-30-06 01:03

- Relationships
parent of 0006747new  [Bug] How to make a dizzy Morph Bounce 
related to 0005560new  MatrixTransformationMorph needs examining and fixing. 
Not all the children of this issue are yet resolved or closed.

- 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


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
51 total queries executed.
35 unique queries executed.
Powered by Mantis Bugtracker