Hi,
Attached is a patch that adds horizontal and vertical flip commands to the viewer along with some fixes to the corresponding player commands.
It should now be easy to create sketches with mirror symmetry.
Subbu
Hi, Subbu,
If the sketch has been rotated, this patch seems to produce incorrect results.
For example, given the following sketch, which has been somewhat rotated:
... then after applying your "flip horizontal" we get:
So I think that something more sophisticated than just flipping the unrotated bitmap and then applying the same rotation to it, which is what your patch does, is called for here.
Cheers,
-- Scott
On Nov 9, 2007, at 11:10 AM, subbukk wrote:
Hi,
Attached is a patch that adds horizontal and vertical flip commands to the viewer along with some fixes to the corresponding player commands.
It should now be easy to create sketches with mirror symmetry.
Subbu <flipfixes.2.cs>_______________________________________________ Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
On Tuesday 13 November 2007 6:06 am, Scott Wallace wrote:
Hi, Subbu,
If the sketch has been rotated, this patch seems to produce incorrect results.
Scott, Thanks for trying out the patch. I should have included a warning in my post. The patch only adds flip commands to the viewer of a SketchMorph. The SketchMorph methods themselves are broken. I use the patch to compose sketches with mirror symmetry and then grab the composite for a single sketch. Kludgy, but a stop gap till etoys get true transformation capabilities.
Flips don't work on rotated sketches because the flip* methods of SketchMorph are broken. They switch the form (which resets the rotationCenter) :-(. Rotations, flips, shear and scale, being views on the base image, should affect only the view transform values and not the base form.
Let me see if I can come up with a patch that will fix this. Subbu
On Nov 13, 2007, at 5:11 , subbukk wrote:
On Tuesday 13 November 2007 6:06 am, Scott Wallace wrote:
Hi, Subbu,
If the sketch has been rotated, this patch seems to produce incorrect results.
Scott, Thanks for trying out the patch. I should have included a warning in my post. The patch only adds flip commands to the viewer of a SketchMorph. The SketchMorph methods themselves are broken. I use the patch to compose sketches with mirror symmetry and then grab the composite for a single sketch. Kludgy, but a stop gap till etoys get true transformation capabilities.
Flips don't work on rotated sketches because the flip* methods of SketchMorph are broken. They switch the form (which resets the rotationCenter) :-(. Rotations, flips, shear and scale, being views on the base image, should affect only the view transform values and not the base form.
Sounds useful to get in for Update.2 - please open a Trac ticket.
- Bert -
On Tuesday 13 November 2007 9:59 pm, Bert Freudenberg wrote:
Flips don't work on rotated sketches because the flip* methods of SketchMorph are broken. They switch the form (which resets the rotationCenter) :-(. Rotations, flips, shear and scale, being views on the base image, should affect only the view transform values and not the base form.
Sounds useful to get in for Update.2 - please open a Trac ticket.
Done. Ticket #4969. I don't have access to XO. I would appreciate if anyone with XO can try out the fixes.
Subbu
On Tuesday 13 November 2007 6:06 am, Scott Wallace wrote:
Hi, Subbu,
If the sketch has been rotated, this patch seems to produce incorrect results.
Here is my second attempt at getting Etoys to flip and tumble. The flip command will do a left-right swap around the rotationCenter while the tumble command will do a top-bottom swap.
flip/tumble operations are not propagated to submorphs and I find that a bit disconcerting with embedded morphs.
Turn left/right, grow/shrink/flip/tumble, shear left/right/forward/backward, move left/right/forward/backward transforms can be defined directly on Morphs (+extensions). I am confused about the role and necessity of non-visual morphs like TransformationMorphs and FlexMorphs. What specific problem do these solve?
Regards .. Subbu
On Nov 14, 2007, at 20:46 , subbukk wrote:
I am confused about the role and necessity of non-visual morphs like TransformationMorphs and FlexMorphs. What specific problem do these solve?
They work around the problem that the regular Canvas does not support arbitrary transformations. Those morphs emulate transformations by warp-blitting to an intermediate form.
- Bert -
On Nov 14, 2007, at 11:46 AM, subbukk wrote:
On Tuesday 13 November 2007 6:06 am, Scott Wallace wrote:
Hi, Subbu,
If the sketch has been rotated, this patch seems to produce incorrect results.
Here is my second attempt at getting Etoys to flip and tumble. The flip command will do a left-right swap around the rotationCenter while the tumble command will do a top-bottom swap.
flip/tumble operations are not propagated to submorphs and I find that a bit disconcerting with embedded morphs.
Hi, Subbu,
So sorry to have let this drop for so long. I finally got around to taking a look at your "flipFixes.3.cs" fileout today.
It works nicely for unrotated Sketches.
As before, if "flip" or "tumble" is applied to a SketchMorph which has been *rotated*, there are surprising and (nearly) unpredictable visual results.
I think (maybe) people would expect that sending "flip" to an objet seen on the screen, whether or not the object had previously been rotated, would horizontally flip the bits of *as seen on the screen* -- not the bits of a different, unseen, "original form".
But maybe I'm wrong -- perhpas there are cases where flipping the original form is closer to what the user expects. Anyway, implementing what I suggest might be tricky and lossy. A replacement "originalForm" would need to be deduced from the form obtained by flipping the bits of the rotated, scaled form. Anyone care to try?
On balance, I think the "flip" and "tumble" features are useful for the kinds of examples you do; people will just need to know that they should be operating with *unrotated* Sketches if they want plausible results using flip and tumble. They'd learn, I suppose.
So, arguably, we should incorporate your code in etoys3.0...?
However, having waited this long, let's wait just a little while longer, in case anyone cares to try his hand at an implementation that gives what I suggest to be the more intuitive result for sketches that have been rotated and resized, and/or, more ambitiously, for sketches which have embedded submorphs.
In hopes of stirring up a little more conversation on this ...
-- Scott
PS:
Turn left/right, grow/shrink/flip/tumble, shear left/right/forward/ backward, move left/right/forward/backward transforms can be defined directly on Morphs (+extensions). I am confused about the role and necessity of non- visual morphs like TransformationMorphs and FlexMorphs. What specific problem do these solve?
This was a design choice made in the very early days of morphic-in- squeak, 1997-8. In practice, this has been a huge and unending -- and indeed ongoing, ten years later -- source of bugs. The specific problem being solved was that there had not been enough complexity and confusion, and that there had been too few bugs.
etoys-dev@lists.squeakfoundation.org