|Anonymous | Login||06-05-2020 18:07 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0005498||[Squeak] Morphic||minor||always||11-23-06 06:33||10-09-07 01:45|
|Summary||0005498: Polygons don't render/orient submorphs correctly when tilted or grown.|
For this one make a compariison.
Put an ellipse inside a rectangle.
And another one inside a polygon.
Using the blue handle rotate each.
The rectangle and its ellipse rotate in tandem.
The ellipse inside the polygon does not rotate and its position relative to the ellipses referencePoint changes (because it maintains a positon relative to the polygons topLeft.)
Using the grow handle grow each.
Here neither submorph grows.
The rectangles ellipse remains in its originaly location. Because the rectangles top left stays stationary as it is grown.
The polygons ellipse moves as the polygon is grown. Because the polygons top left moves as it is grown.
If you rotate and then grow a rectangle it doesn't actually grow but scales.
When it scales the submorph seems to scale in tandem. (Actually it is the rendered image that is scaling.
Morphic AFAIK has three ways of dealing with tilt grow and scale.
1) Morphs rendered with Transformation Morph. (rectangle and ellipses)
2) Polygon based morphs (which modify their shape as the are transformed)
3) And morphs rendered with MatrixTransformationMorph (True type fonts mostly)
Halos work well with one and two but are not cleverly integrated with three.
Halos ask a lot of questions they shouldnt about whether morphs are flexed or not. And a lot of IMHO ugly and buggy code has been written to try to get type one rendering to work.
I've adopted polygons as the place to start to cure this madness. First by making them pass as ovals. And now its time to work on how they rotate.
My user stories are these:
All morphs should behave in a similar fashion when manipulated by halo handles. You don't want to build separate models in your head for rectangles and polygons. Also polygons submorphs don't move right. If you tilt a poly you have to always relocate the submorphs even if you like the fact they dont rotate.
Changing what rectanges do when rotated would be messy and hard. Also they seem to get it mostly right. Rotating submorphs in tandem seems "right" and doesn't make-me-think. While what polygons do does.
So Polygons should rotate and their submorphs should rotate in tandem.
Since polygons change their shape when rotating their submorph will have the responsibility of rotating themselves to an appropriate heading.
The rotation of the polygon will have to relocate the referencePoints of its submorphs and move them s.t. their referencePoints windup in those relocated postions.
This suggests that the same thing happen when a polygon is grown.
Its points and submorph ref points should be relocated. And the submorphs should have their ref points aligned with the new location.
If the polygon is scaled instead of grown then the submorphs have the responsibility of scaling themselves as well.
The other problem with polygons is in 0000803 the referencePosition of a polygon can get out of whack if the polygon's shape changes and there is bad feedback between the halo handles and the referencePoint.
That needs to be fixed too and can be considered part of this reports project.
(0008431 - 2435 - 2639 - 2749 - 2749 - 2749 - 2749)
edited on: 11-25-06 10:09
Results of experiments
I've been able to get a variation of polygons that rotate and resize in a way that I think is useful.
The means of rotating from a halo is passing a #heading: message to the morph.
The to getting submorphs to rotate in tandem has been to collect their pre rotated referencesPoints and rotate them relative to the morphs reference point.
Then after setting the vertices of the morph (since that 'adjusts the submorphs positions.)
you must update the submorphs with #referencePosition.
And then recursively ask each submorph to change its heading by the same amount as the morph.
This gets the proper stability and allows polygons to look as good as rendered morphs.
One of the differences between growth and scale is that in the type one morphs when you scale the submorphs scale in tandem but when a morph is grown its submorphs stay their original size. (and essentially stay in the same place as well. But that is because when grown the topRight of the morph acts as the defacto unmoving reference.)
When polygons are grown they expand around the center of their bounds.
and the submorphs move to maintain a constant distance from the bounds topLeft.
What worked well for growing polygons was to do the updating of the submorphs reference points.
Keeping the submorphs their original size gave interesting results. Especially as my test morphs were in the form of faces. The facial features each readjusted to maintain their relative positions. The change in scale of face to features produced a rather interesting effect on the perceived expression. So I would like to keep that.
I think it would be appropriate to define two handle behaviors for polygons.
The growth one as described above.
And a rescale behavior where the squbmorph recursively rescale to match. I haven't tried that yet. So the results are yet to be judged.
I am also recommending that type one morphs change their growth behavior to update the reference points of their submorphs. (possibly using the topLeft as the morphs reference point. One of the real annoyances when shrinking a morph is that if a submorph falls outside its bounds then you can not put halos around the submorph to more it to a more appropriate location. (which is a bug that deserves it own report)
A Work in progress project loadable into 3.9 is available
on Bobs super swiki at:
|11-23-06 06:33||wiz||New Issue|
|11-25-06 10:05||wiz||Note Added: 0008431|
|11-25-06 10:09||wiz||Note Edited: 0008431|
|10-09-07 01:45||matthewf||Relationship added||related to 0000803|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
40 total queries executed.|
29 unique queries executed.