Morph 3.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Morph 3.0

Jerome Peace
Hi Juan,

Two thought have just come together and I am excited.

>From morphic 3.o I was looking at the ivars for
Location
and comparing them to problems I've been working thru
with making polygons tilt just like rectanges and
ellipses.

The problem I noticed with Location was that you had
angle but no scale.

>From my work with polygons I know that angle and scale
are natural partners.

xextent and yextent are not substitutes. Indeed they
cause ambiguity because unless you look at the works
you wonder if you turn the morph first then apply the
extent scalers or the other way around.

What I found was in any given operation you had to
choose rotate and scale
or
stretch and reflect (That's what should happen when
one of the extent scalers go negative)


The other decision I realized from my work with
polygons was to get polygons to truely rotate (with
their submorphs doing the same thing) I had to collect
the submorphs refernce locations and subject them to
the same transformation as the polygon (rotate and
scale or stretch and reflect)

So the insight as I put your work and mine together
came in the form of a question:

Do morphs have locations or do locations have morphs?


Yours in curiosity and service, --Jerome Peace

 


       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: Morph 3.0

Juan Vuletich-4
Hi Jerome!

I'm so glad you're looking at my work! Please note that my current email
is the sender of this message, [hidden email]. The addresses
@uolsinectis are no longer in use. The rest of the answer is inline with
your comments.

Jerome Peace escribió:
> Hi Juan,
>
> Two thought have just come together and I am excited.
>  
:)

> >From morphic 3.o I was looking at the ivars for
> Location
> and comparing them to problems I've been working thru
> with making polygons tilt just like rectanges and
> ellipses.
>
> The problem I noticed with Location was that you had
> angle but no scale.
>
> >From my work with polygons I know that angle and scale
> are natural partners.
>  
Well, having scale means that somewhere you also have the natural size,
i.e. the size when scale is 1. I think that rotating an object is
something natural in the real world, but applying a scale factor is not.
What would be the meaning for a scale factor in M3 morphs?
> xextent and yextent are not substitutes. Indeed they
> cause ambiguity because unless you look at the works
> you wonder if you turn the morph first then apply the
> extent scalers or the other way around.
>  
In my opinion, rotating an object does not change width and height.
Let's suppose you have a morph with angle zero. You adjust the width to
be w1 and the height to be h1. The width w1 is measured along the X axis
of the owner and the height h1 is measured along the Y axis of the
owner. Then we rotate the morph, for example, by 30 degrees. If we
measure the extent along the X axis of the owner, it is no longer w1,
and the extent along the Y axis is no longer h1. However, these are not
the width and height of the morph, which are the same as before. In
other words: my height is about 5'6". If I lay on a bed, my height is
not 1'. It is the same as before. Do you agree?
> What I found was in any given operation you had to
> choose rotate and scale
> or
> stretch and reflect (That's what should happen when
> one of the extent scalers go negative)
>
>  
I don't understand this. Please elaborate.
> The other decision I realized from my work with
> polygons was to get polygons to truely rotate (with
> their submorphs doing the same thing) I had to collect
> the submorphs refernce locations and subject them to
> the same transformation as the polygon (rotate and
> scale or stretch and reflect)
>  
Well, this is not needed in M3, as the location is always relative to
the owner. If you change the ivar angle in the location in the owner,
all the submorphs rotate correctly. You can try it yourself in my image,
with the halo.
> So the insight as I put your work and mine together
> came in the form of a question:
>
> Do morphs have locations or do locations have morphs?
>
>  
Interesting. I always thought that morphs have locations. What would be
the consequences of the other point of view?
> Yours in curiosity and service, --Jerome Peace
>
>  
Cheers,
Juan Vuletich
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: NewMorphic Feedback (1 source control)

Jerome Peace
Hi Juan,

Cool.

Thanks for listening.

I've actually followed progress to know how much you
advanced things. (Real time performance and the color
background fix. Great steady progress.)

I am using things on an old 400hz iMac running OS9.1.
I'm using one of JMM's old macClassic vms. So I need
to find out if you changed anything in th vm you
distribute with the system?  

I can try somethings that blow my mac out to the water
complete with the macbomb system crash box. That only
happened while using a low memory allocation. I'm
having better luck when I give the vm more room.

I am about to try your new addr. If this doesn't
bounce then were golden.

The last try missed probably due to some typing on my
part.


--- Juan Vuletich <[hidden email]>
wrote:

> Hi Jerome,
>
> I got the message, but this address could die
> anytime, as I'm no longer
> paying for it. My current primary address is
> [hidden email]
> (personal). I also read [hidden email]
> (university) and
> [hidden email] (work).
>
> I have already changed the name of the image,
> changes and sources. They
> are now simply Morphic3. You are right that I should
> add some numeric
> suffix or similar each time I update the ftp. Will
> do it. Thanks!
>
> Cheers,
> Juan Vuletich
>
> Jerome Peace escribió:
> > Hi Juan
> >
> > I just downloaded the most recent NewMorphic.
> >
> > I haven't played with it yet but I do have a
> > suggestion.
> >
> > I keep old images around for historical reseach.
> Or
> > just my general cluttered style.
> >
> > It would be helpful if the images were easily
> > distinguishable by name or release number.
> >
> > All the NewMorphic images go by
> > Squeak3.7-5989-basic.image
> > which means they can get confused with each other
> or
> > with my historic copys of 3.7.
> >
> > I usually put them in a directory and call the
> > directory something unique (like NewMorphic070619)
> > with the digits standing for yymmdd for the date I
> > downloaded it.
> >
> > Whatever you use to distinguish version is less
> > important than that they be distinguishable.
> >
> > That way when someone gives you feedback they can
> > quickly refer to the correct image.
> >
> > Yours in curiosity and service, --Jerome Peace
> >
> > P.S. I hope this gets to you. This is my old
> address
> > for you. I tried sending to your new one but that
> mail
> > bounced.
> >
> >



       
____________________________________________________________________________________
Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Do morphs have locations or do locations have morphs?

Jerome Peace
In reply to this post by Juan Vuletich-4
Do morphs have locations or do locations have morphs?

Actually the answer I came up with was that each has
the other.

Morphs don't have submorphs they have locations (this
makes them resemble very much a polygon morph.)
Locations in turn have morphs (for which they are a
reference point.)

This shift in thinking melts a ton of problems that
morphic ran into. Including flex morphs.

So each location is in a morph (or more precisely its
coordinate system. That is the locations reference
morph.

So each morph is at a location in higher submorph.

assertions

" each location in a most one morph"
"a morph can't be in two places at the same time"
"a location is a sublocation of its owner"
" each location in a morph belongs to that morph."

also:
"more that one morph may share a location."
"locations must be appropriate to their owners
co-ordinate system."
Essentially morphs and locations alternate in a
heirarchy tree.

You could have a morph with bare locations. In which
case it might display like a polygon would (one of my
fancier ones see:
http://209.143.91.36/super/724
PolyFix02-wiz).

Now I suspect doubling the depth of the tree will slow
the works down but this is too early in the process to
be concerned about speed. And if things work right
then they can be tweaked to speed things along.

The great advantage is the conceptual simplicity. And
the rightness of the model from a real world point of
view.


Yours in curiosity and service, --Jerome Peace





 
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: Morph 3.0

Jerome Peace
In reply to this post by Juan Vuletich-4

--- Juan Vuletich <[hidden email]> wrote:

> Hi Jerome!
>
> I'm so glad you're looking at my work!
>
> Jerome Peace escribió:
> > Hi Juan,
> >
> > Two thought have just come together and I am
> excited.
> >  
> :)
> > >From morphic 3.o I was looking at the ivars for
> > Location
> > and comparing them to problems I've been working
> thru
> > with making polygons tilt just like rectanges and
> > ellipses.
> >
> > The problem I noticed with Location was that you
> had
> > angle but no scale.
> >
> > >From my work with polygons I know that angle and
> scale
> > are natural partners.
> >  
> Well, having scale means that somewhere you also
> have the natural size,
> i.e. the size when scale is 1. I think that rotating
> an object is
> something natural in the real world, but applying a
> scale factor is not.

Hmm. What I am using for inspiration is the contrast
between the yellow growth handle on morphs and the
outer handle on a star morph.

With a star as you use the outer handle, the
invariable is the shape. The parts stay the same
relative to each other but the scale and the angle may
both change.

This is a really useful transformation. It allows you
to have all sorts of objects of similar shape but
different scale and orientation.

It is done by matching the scale and angle to the
polar coordinates of the vector from center to outer
handle.

The yellow growth handle on the other hand affects the
aspect ratio of x and y coordinates.  If left
completely unfettered you would have a morph transform
(around its reference point) in response to the x and
y magnitude (and sign) of the vector from reference
point to yellow handle.  

The two interpertations of the vector are mutually
exclusive though they can overlap. You could constrain
the growth handle to just scale (as the orange handle
does).

With the yellow handle presently there are limits put
on the range of growth and shrinkage.

The blue handle is similar to the stars outer handle
but constrains the rotation of morphs to maintain the
same size. A rotated morph can only be scaled (orange
handle) it can no longer be stretched.

 
> What would be the meaning for a scale factor in M3
> morphs?

angle and scale would belong to the location.

xaspect and yaspect would not belong to location but
be a parameter of a cartesian coordinate system.
In my conception I would have a class of orthogonal
coordinates which would have points coded in the range
-1 <=coord<=+1 then multiply by and coord aspect.

so the aspects could both be 0.5 and you would get
your unit square. or they could be some other aspect
ratio.

In manipulating the morph you could put a yellow
handle to adjust (stretch) the aspect ratio of the
coord system. Circles become ellipses. Squares become
rectangles. The yellow handle growth would not affect
the angle and it would always (for cartesian coords)
apply to the coord system. Furthmore you could honor
negative aspects as directions to reflect one or more
axes.

> > xextent and yextent are not substitutes. Indeed
> they
> > cause ambiguity because unless you look at the
> works
> > you wonder if you turn the morph first then apply
> the
> > extent scalers or the other way around.
> >  
> In my opinion, rotating an object does not change
> width and height.
> Let's suppose you have a morph with angle zero. You
> adjust the width to
> be w1 and the height to be h1. The width w1 is
> measured along the X axis
> of the owner and the height h1 is measured along the
> Y axis of the
> owner. Then we rotate the morph, for example, by 30
> degrees. If we
> measure the extent along the X axis of the owner, it
> is no longer w1,
> and the extent along the Y axis is no longer h1.
> However, these are not
> the width and height of the morph, which are the
> same as before. In
> other words: my height is about 5'6". If I lay on a
> bed, my height is
> not 1'. It is the same as before. Do you agree?

It would depend on whether you had this-end-up stamped
on your forehead or along your left arm. :-)

In the reference system you take with you to bed its
one way. In the reference system gravity supplies to
the world its the other. And looked at from a more
distant reference it will change in 6 hours time while
you sleep.

The bug in morphic is that the words we use can't
distinguish.

When I rotate a polygon, Its submorphs stay in their
upright orientation and translate with respect to the
changing #topLeft boundry point.

When I rotate an image or a rectangle all the
submorphs rotate around their refpoints which in turn
rotate around the rectangles reference point.

When I set out to fix the difference I came to the
understanding that rotate and scale which must
maintain the aspect ratio of things, differ from
stretch and reflect which can change the aspect ratio
of things but must maintain the orientation.

The way they are done now (with stretch implemented by
extent:) rotation and stretch are not commutative
operations. You can see this with polygons most
easily.

What I've been striving for is elegance and the lack
of limitations on transform operations. And that
starts to come when I recognise that I can ask for
rotate and scale in the same manipulation. Or I can
ask for stretch/reflect at the same time. But I cannot
mix the two.

So seeing the ivars for location the lack of the scale
ivar jumped out. As did the presence of the aspect
ivars clearly there to facilitate scale. Aspect
belongs to the coord system. Even though aspect and
scale can overlap achieving generality is eased when
they are both present and can be treated separately.

> > What I found was in any given operation you had to
> > choose rotate and scale
> > or
> > stretch and reflect (That's what should happen
> when
> > one of the extent scalers go negative)
> >
> >  
> I don't understand this. Please elaborate.
> > The other decision I realized from my work with
> > polygons was to get polygons to truely rotate
> (with
> > their submorphs doing the same thing) I had to
> collect
> > the submorphs refernce locations and subject them
> to
> > the same transformation as the polygon (rotate and
> > scale or stretch and reflect)
> >  
> Well, this is not needed in M3, as the location is
> always relative to
> the owner. If you change the ivar angle in the
> location in the owner,
> all the submorphs rotate correctly. You can try it
> yourself in my image,
> with the halo.

I did. That's why I know you are on the right track.

I believe there is a very easy way of doing morphic
which people didn't see at first. We can see farther
because we stand on the shoulders of giants. :-)

Yours in curiosity and service, --Jerome Peace



       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: NewMorphic Feedback (1 source control)

Juan Vuletich-4
In reply to this post by Jerome Peace
Hi Jerome,

Jerome Peace escribió:

> Hi Juan,
>
> Cool.
>
> Thanks for listening.
>
> I've actually followed progress to know how much you
> advanced things. (Real time performance and the color
> background fix. Great steady progress.)
>
>  
:) Thanks.
> I am using things on an old 400hz iMac running OS9.1.
> I'm using one of JMM's old macClassic vms. So I need
> to find out if you changed anything in th vm you
> distribute with the system?  
>
>  
Not at all. I should delete the VM from the zip file. It is misleading.
Ok. Done.
So, you are doing a serious performance test there! Unfortunately, the
Morphic 3 stuff uses Floats for coordinates, and I haven't worked on
performance yet, so everything should be slow...
> I can try somethings that blow my mac out to the water
> complete with the macbomb system crash box. That only
> happened while using a low memory allocation. I'm
> having better luck when I give the vm more room.
>  
I believe the same should happen with any Squeak image, right?
> I am about to try your new addr. If this doesn't
> bounce then were golden.
>
>  
Yep, here I am.
> The last try missed probably due to some typing on my
> part.
>  
Now I'm working on scrolling and clipping. I hope to publish something soon.

Cheers,
Juan Vuletich

_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: Do morphs have locations or do locations have morphs?

Juan Vuletich-4
In reply to this post by Jerome Peace
Jerome Peace escribió:

> Do morphs have locations or do locations have morphs?
>
> Actually the answer I came up with was that each has
> the other.
>
> Morphs don't have submorphs they have locations (this
> makes them resemble very much a polygon morph.)
> Locations in turn have morphs (for which they are a
> reference point.)
>
> This shift in thinking melts a ton of problems that
> morphic ran into. Including flex morphs.
>
> So each location is in a morph (or more precisely its
> coordinate system. That is the locations reference
> morph.
>
> So each morph is at a location in higher submorph.
>
>  
This sounds very similar to what I'm doing.

> assertions
>
> " each location in a most one morph"
> "a morph can't be in two places at the same time"
> "a location is a sublocation of its owner"
> " each location in a morph belongs to that morph."
>
> also:
> "more that one morph may share a location."
> "locations must be appropriate to their owners
> co-ordinate system."
>  
All these asserts are valid in Morphic 3, as it is today.
> Essentially morphs and locations alternate in a
> heirarchy tree.
>
>  
Here is an implementation difference. To me, a location is an ivar in a
Morph.

> You could have a morph with bare locations. In which
> case it might display like a polygon would (one of my
> fancier ones see:
> http://209.143.91.36/super/724
> PolyFix02-wiz).
>
> Now I suspect doubling the depth of the tree will slow
> the works down but this is too early in the process to
> be concerned about speed. And if things work right
> then they can be tweaked to speed things along.
>
> The great advantage is the conceptual simplicity. And
> the rightness of the model from a real world point of
> view.
>
>
> Yours in curiosity and service, --Jerome Peace
>
>  
I don't see the advantage of getting location in the morph tree, instead
of doing as I did. I also think that M3 is conceptually "right". What
problems do you see in M3? I saw PolyFix02-wiz. I like the WizagonMorph
behavior. It is the one I believe correct. I you look at M3, my morphs
rotate the same way, but resize slightly differently. With my
implementation of coordinate systems, the code is much simpler, there's
no need to go down every submorph to fix its location. Please play a
while with my TestMorphs.

Cheers,
Juan Vuletich

_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: Morph 3.0

Juan Vuletich-4
In reply to this post by Jerome Peace
Hi Jerome,

Jerome Peace escribió:

> --- Juan Vuletich <[hidden email]> wrote:
>
>  
>> Hi Jerome!
>>
>> I'm so glad you're looking at my work!
>>
>> Jerome Peace escribió:
>>    
>>> Hi Juan,
>>>
>>> Two thought have just come together and I am
>>>      
>> excited.
>>    
>>>  
>>>      
>> :)
>>    
>>> >From morphic 3.o I was looking at the ivars for
>>> Location
>>> and comparing them to problems I've been working
>>>      
>> thru
>>    
>>> with making polygons tilt just like rectanges and
>>> ellipses.
>>>
>>> The problem I noticed with Location was that you
>>>      
>> had
>>    
>>> angle but no scale.
>>>
>>> >From my work with polygons I know that angle and
>>>      
>> scale
>>    
>>> are natural partners.
>>>  
>>>      
>> Well, having scale means that somewhere you also
>> have the natural size,
>> i.e. the size when scale is 1. I think that rotating
>> an object is
>> something natural in the real world, but applying a
>> scale factor is not.
>>    
>
> Hmm. What I am using for inspiration is the contrast
> between the yellow growth handle on morphs and the
> outer handle on a star morph.
>
> With a star as you use the outer handle, the
> invariable is the shape. The parts stay the same
> relative to each other but the scale and the angle may
> both change.
>
> This is a really useful transformation. It allows you
> to have all sorts of objects of similar shape but
> different scale and orientation.
>
> It is done by matching the scale and angle to the
> polar coordinates of the vector from center to outer
> handle.
>
>  
Yes, it is very cool.

> The yellow growth handle on the other hand affects the
> aspect ratio of x and y coordinates.  If left
> completely unfettered you would have a morph transform
> (around its reference point) in response to the x and
> y magnitude (and sign) of the vector from reference
> point to yellow handle.  
>
> The two interpertations of the vector are mutually
> exclusive though they can overlap. You could constrain
> the growth handle to just scale (as the orange handle
> does).
>
>  
I believe it is better to have separate handles for rotation and
"scale". With the star outer handle it is hard to do just rotation or
just rescale. But I believe the default should be to keep the aspect
ratio. Perhaps a modifier key could allow changing it.

> With the yellow handle presently there are limits put
> on the range of growth and shrinkage.
>
> The blue handle is similar to the stars outer handle
> but constrains the rotation of morphs to maintain the
> same size. A rotated morph can only be scaled (orange
> handle) it can no longer be stretched.
>
>  
>  
Well, in current Morphic a morph can be both scaled and stretched. I
think this is confusing. I believe the default operation is scaling.
That is the the yellow handle does in morphic 3: change the space the
morph occupies in its owner, but do not change the morph real (or
internal) size, that is, its own coordinate system.

Only some special morphs (currently none) will support scrolling and a
new operation that zooms the morph's contents, but not its external
size, i.e. the extent in the location (to make scrolling necessary). On
those morphs, there will be yet another new operation that changes both
the external extent and the internal scale factor, to keep constant the
apparent size of the contents. For example, for a text editor, where
resizing it does not change the size of the text. Forgive me if I'm not
clear enough on this. I'll write a TWJ (the weekly juan) on this when it
starts working. This is related to
http://www.jvuletich.org/issues/Issue0009.htm but my ideas changed quite
a bit since then, thanks to feedback from Bert and Tim.

>> What would be the meaning for a scale factor in M3
>> morphs?
>>    
>
> angle and scale would belong to the location.
>
> xaspect and yaspect would not belong to location but
> be a parameter of a cartesian coordinate system.
> In my conception I would have a class of orthogonal
> coordinates which would have points coded in the range
> -1 <=coord<=+1 then multiply by and coord aspect.
>
> so the aspects could both be 0.5 and you would get
> your unit square. or they could be some other aspect
> ratio.
>  
But doing this you restrict yourself to Cartesian coordinate systems, in
particular to [-1, ..1] x [-1, .. 1]. To be as general as possible on
this, I allow nonlinear coordinate systems too. I want to use "real
world" coordinates. For example, if I have a morph that represents the
map of Argentina, the "x" (longitude) could go from 80 west to 48 west,
and the "y" (latitude) could go from 56 south to 20 south or something.
This coordinate system (the one that is good for plotting a map of
Argentina) is specified by the bounds of the coordinates (the valid
coordinate values) and the transformation it does to a cartesian system,
i.e. the kind of projection. If you see it this way, it doesn't make
sense to modify the coordinate system just to stretch the map. The
coordinate system is exactly the same. All that changes is the extent it
will use in its owner (the sheet of paper where it is drawn). Thats why
I consider the coordinate system something intrinsic of the morph, part
of its definition, and I consider the location an "accident" something
that happens to be the way it is, but could change without affecting the
essence of the morph.

> In manipulating the morph you could put a yellow
> handle to adjust (stretch) the aspect ratio of the
> coord system. Circles become ellipses. Squares become
> rectangles. The yellow handle growth would not affect
> the angle and it would always (for cartesian coords)
> apply to the coord system. Furthmore you could honor
> negative aspects as directions to reflect one or more
> axes.
>
>  
>>> xextent and yextent are not substitutes. Indeed
>>>      
>> they
>>    
>>> cause ambiguity because unless you look at the
>>>      
>> works
>>    
>>> you wonder if you turn the morph first then apply
>>>      
>> the
>>    
>>> extent scalers or the other way around.
>>>  
>>>      
>> In my opinion, rotating an object does not change
>> width and height.
>> Let's suppose you have a morph with angle zero. You
>> adjust the width to
>> be w1 and the height to be h1. The width w1 is
>> measured along the X axis
>> of the owner and the height h1 is measured along the
>> Y axis of the
>> owner. Then we rotate the morph, for example, by 30
>> degrees. If we
>> measure the extent along the X axis of the owner, it
>> is no longer w1,
>> and the extent along the Y axis is no longer h1.
>> However, these are not
>> the width and height of the morph, which are the
>> same as before. In
>> other words: my height is about 5'6". If I lay on a
>> bed, my height is
>> not 1'. It is the same as before. Do you agree?
>>    
>
> It would depend on whether you had this-end-up stamped
> on your forehead or along your left arm. :-)
>  
Sure, but that wouldn't change for laying down!
> In the reference system you take with you to bed its
> one way. In the reference system gravity supplies to
> the world its the other. And looked at from a more
> distant reference it will change in 6 hours time while
> you sleep.
>
>  
Well, I see it is needed to make a decision here. I believe it is
simpler to ignore the reference system and just focus on the morph (or
my body in this example).

> The bug in morphic is that the words we use can't
> distinguish.
>
> When I rotate a polygon, Its submorphs stay in their
> upright orientation and translate with respect to the
> changing #topLeft boundry point.
>
> When I rotate an image or a rectangle all the
> submorphs rotate around their refpoints which in turn
> rotate around the rectangles reference point.
>
> When I set out to fix the difference I came to the
> understanding that rotate and scale which must
> maintain the aspect ratio of things, differ from
> stretch and reflect which can change the aspect ratio
> of things but must maintain the orientation.
>  
I agree.

> The way they are done now (with stretch implemented by
> extent:) rotation and stretch are not commutative
> operations. You can see this with polygons most
> easily.
>
> What I've been striving for is elegance and the lack
> of limitations on transform operations. And that
> starts to come when I recognise that I can ask for
> rotate and scale in the same manipulation. Or I can
> ask for stretch/reflect at the same time. But I cannot
> mix the two.
>
>  
I agree, but I believe it is good to distinguish the intrinsics of the
morph (its extent expressed in its own coordinate system) from the
accidental (position, angle, "zoom"). I believe you think that rotate
and scale don't change the morph (that's why the contens rotates and
scales as a whole). But I don't see how you view stretch / reflect. Do
they change the morph? Do you think they are operations we can perform
on any object in the real world?

It would be great if you try to experiment with this in M3.
> So seeing the ivars for location the lack of the scale
> ivar jumped out. As did the presence of the aspect
> ivars clearly there to facilitate scale. Aspect
> belongs to the coord system. Even though aspect and
> scale can overlap achieving generality is eased when
> they are both present and can be treated separately.
>
>  
I hope my view on coordinate systems (i.e. the map of Argentina) above
is clear enough on this.

>>> What I found was in any given operation you had to
>>> choose rotate and scale
>>> or
>>> stretch and reflect (That's what should happen
>>>      
>> when
>>    
>>> one of the extent scalers go negative)
>>>
>>>  
>>>      
>> I don't understand this. Please elaborate.
>>    
>>> The other decision I realized from my work with
>>> polygons was to get polygons to truely rotate
>>>      
>> (with
>>    
>>> their submorphs doing the same thing) I had to
>>>      
>> collect
>>    
>>> the submorphs refernce locations and subject them
>>>      
>> to
>>    
>>> the same transformation as the polygon (rotate and
>>> scale or stretch and reflect)
>>>  
>>>      
>> Well, this is not needed in M3, as the location is
>> always relative to
>> the owner. If you change the ivar angle in the
>> location in the owner,
>> all the submorphs rotate correctly. You can try it
>> yourself in my image,
>> with the halo.
>>    
>
> I did. That's why I know you are on the right track.
>
>  
:)
> I believe there is a very easy way of doing morphic
> which people didn't see at first. We can see farther
> because we stand on the shoulders of giants. :-)
>
> Yours in curiosity and service, --Jerome Peace
>  
Indeed. BTW, John Maloney himself said (in the SqueakNews interview)
that rotation and flexing were added as aftethoughts, and that a
reimplementation where each morph defined its own coordinate system was
needed.

Cheers,
Juan Vuletich
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: Do morphs have locations or do locations have morphs?

Tapple Gao
In reply to this post by Jerome Peace
On Thu, Jun 21, 2007 at 01:36:09PM -0700, Jerome Peace wrote:
> assertions
>
> " each location in a most one morph"

This assertion appears to conflict with

> "a location is a sublocation of its owner"

and

> "more that one morph may share a location."

if one is using world-relative locations. Is this not the case?
What is a location? Parent morph + relative 2d location?

Also, what is in a Parent morph? location + rotation + shear +
scale?  or is there some more general transform system that
could handle funky stuff like jiggly morphs, or allow morphs to
be 2.5d? That would be nice.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: NewMorphic Feedback (1 source control)

Jerome Peace
In reply to this post by Jerome Peace

--- Juan Vuletich <[hidden email]> wrote:

> Hi Jerome,
>
> Jerome Peace escribió:
> > Hi Juan,
> >
> > Cool.
> >
> > Thanks for listening.
> >
> > I've actually followed progress to know how much
> you
> > advanced things. (Real time performance and the
> color
> > background fix. Great steady progress.)
> >
> >  
> :) Thanks.
> > I am using things on an old 400hz iMac running
> OS9.1.
> > I'm using one of JMM's old macClassic vms. So I
> need
> > to find out if you changed anything in th vm you
> > distribute with the system?  
> >
> >  
> Not at all. I should delete the VM from the zip
> file. It is misleading.
> Ok. Done.
> So, you are doing a serious performance test there!
> Unfortunately, the
> Morphic 3 stuff uses Floats for coordinates, and I
> haven't worked on
> performance yet, so everything should be slow...

Actually the iMac is well designed and the performance
is responsive. I can resize the example at about the
same speed as I am used to. Of Course there not a lot
else going on at the same time. So its not much of a
burden. The real problem is I can usually find things
that bring everything to a screeching halt within 15
minutes. The copy handle is good for that.

The balloon engine is probably the reason for the
speed. Two or three version ago I did give up because
things were too slow.

The system is slow when not just displaying your
morphs. Bringing up a browser or an inspector feels
like it takes forever (compared to what I'm used to.
lol).

The balloon engine is also probably responsible for
the clipping bugs. It has some very bad rounding
errors in it. A lot bugs which I'm good enough to find
but not knowledgable enough to fix.


> > I can try somethings that blow my mac out to the
> water
> > complete with the macbomb system crash box. That
> only
> > happened while using a low memory allocation. I'm
> > having better luck when I give the vm more room.
> >  
> I believe the same should happen with any Squeak
> image, right?
 
> Now I'm working on scrolling and clipping. I hope to
> publish something soon.

Cool. I'll keep following your progress.

Yours in curiosity and service, --Jerome Peace



       
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: Re: NewMorphic Feedback (1 source control)

Stéphane Ducasse-3
In reply to this post by Juan Vuletich-4
Juan

did you check the unit used in Sophie. Because told me that their  
units are quite good.

Stef


On 22 juin 07, at 03:11, Juan Vuletich wrote:

> Hi Jerome,
>
> Jerome Peace escribió:
>> Hi Juan,
>>
>> Cool.
>>
>> Thanks for listening.
>> I've actually followed progress to know how much you
>> advanced things. (Real time performance and the color
>> background fix. Great steady progress.)
>>
>>
> :) Thanks.
>> I am using things on an old 400hz iMac running OS9.1.
>> I'm using one of JMM's old macClassic vms. So I need
>> to find out if you changed anything in th vm you
>> distribute with the system?
>>
> Not at all. I should delete the VM from the zip file. It is  
> misleading.
> Ok. Done.
> So, you are doing a serious performance test there! Unfortunately, the
> Morphic 3 stuff uses Floats for coordinates, and I haven't worked on
> performance yet, so everything should be slow...
>> I can try somethings that blow my mac out to the water
>> complete with the macbomb system crash box. That only
>> happened while using a low memory allocation. I'm
>> having better luck when I give the vm more room.
>>
> I believe the same should happen with any Squeak image, right?
>> I am about to try your new addr. If this doesn't
>> bounce then were golden.
>>
>>
> Yep, here I am.
>> The last try missed probably due to some typing on my
>> part.
>>
> Now I'm working on scrolling and clipping. I hope to publish  
> something soon.
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Morphic mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic

_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: NewMorphic Feedback (1 source control)

Juan Vuletich-4
In reply to this post by Jerome Peace
Hi Jerome,

Jerome Peace escribió:

>
>> performance yet, so everything should be slow...
>>    
>
> Actually the iMac is well designed and the performance
> is responsive. I can resize the example at about the
> same speed as I am used to. Of Course there not a lot
> else going on at the same time. So its not much of a
> burden. The real problem is I can usually find things
> that bring everything to a screeching halt within 15
> minutes. The copy handle is good for that.
>
> The balloon engine is probably the reason for the
> speed. Two or three version ago I did give up because
> things were too slow.
>
> The system is slow when not just displaying your
> morphs. Bringing up a browser or an inspector feels
> like it takes forever (compared to what I'm used to.
> lol).
>
> The balloon engine is also probably responsible for
> the clipping bugs. It has some very bad rounding
> errors in it. A lot bugs which I'm good enough to find
> but not knowledgable enough to fix.
>
>
>  
I think we need serious work on performance too. But now is too early
for that in M3.

WRT Balloon, it is great. It is fast and it is there. I know it has
bugs, but now I'm focusing on the morph themselves. It is good to have
balloon around to get morphs working. Later, maybe it could be replaced
by Cairo as in Sophie. Or perhaps we can enhance Balloon. Or use some
other engine. Neither Ballon nor Cairo are the final solution for M3
because they only support affine (i.e. linear) transforms.

Cheers,
Juan Vuletich
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: Re: NewMorphic Feedback (1 source control)

Juan Vuletich-4
In reply to this post by Stéphane Ducasse-3
Hi Stef,

You suggested that to me some time ago and I did. Sophie uses
smallintegers for coordinates. This is ok for books, to go from printer
pixels to books of several kilometers. But I want float coordinates and
multiple nonlinear coordinate systems in the same world. I don't want to
be restricted to Cartesian with a single scale all over the system. In a
morph, the number 3 could mean 3 milimeters, and in another it could
mean 3 astronomic unit (mean distance from the earth to the sun), or 3
degrees of latitude north, or 3 db or whatever.

Cheers,
Juan Vuletich

Stéphane Ducasse escribió:

> Juan
>
> did you check the unit used in Sophie. Because told me that their
> units are quite good.
>
> Stef
>
>
> On 22 juin 07, at 03:11, Juan Vuletich wrote:
>
>> Hi Jerome,
>>
>> Jerome Peace escribió:
>>> Hi Juan,
>>>
>>> Cool.
>>>
>>> Thanks for listening.
>>> I've actually followed progress to know how much you
>>> advanced things. (Real time performance and the color
>>> background fix. Great steady progress.)
>>>
>>>
>> :) Thanks.
>>> I am using things on an old 400hz iMac running OS9.1.
>>> I'm using one of JMM's old macClassic vms. So I need
>>> to find out if you changed anything in th vm you
>>> distribute with the system?
>>>
>> Not at all. I should delete the VM from the zip file. It is misleading.
>> Ok. Done.
>> So, you are doing a serious performance test there! Unfortunately, the
>> Morphic 3 stuff uses Floats for coordinates, and I haven't worked on
>> performance yet, so everything should be slow...
>>> I can try somethings that blow my mac out to the water
>>> complete with the macbomb system crash box. That only
>>> happened while using a low memory allocation. I'm
>>> having better luck when I give the vm more room.
>>>
>> I believe the same should happen with any Squeak image, right?
>>> I am about to try your new addr. If this doesn't
>>> bounce then were golden.
>>>
>>>
>> Yep, here I am.
>>> The last try missed probably due to some typing on my
>>> part.
>>>
>> Now I'm working on scrolling and clipping. I hope to publish
>> something soon.
>>
>> Cheers,
>> Juan Vuletich
>>
>> _______________________________________________
>> Morphic mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
>
>

_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: Re: NewMorphic Feedback (1 source control)

Stéphane Ducasse-3

On 23 juin 07, at 14:35, Juan Vuletich wrote:

> Hi Stef,
>
> You suggested that to me some time ago and I did. Sophie uses  
> smallintegers for coordinates. This is ok for books, to go from  
> printer pixels to books of several kilometers. But I want float  
> coordinates and multiple nonlinear coordinate systems in the same  
> world. I don't want to be restricted to Cartesian with a single  
> scale all over the system. In a morph, the number 3 could mean 3  
> milimeters, and in another it could mean 3 astronomic unit (mean  
> distance from the earth to the sun), or 3 degrees of latitude  
> north, or 3 db or whatever.

I thought that they used something new with a strange name for having  
better precision....
I cannot find the name anymore.

>
> Cheers,
> Juan Vuletich
>
> Stéphane Ducasse escribió:
>> Juan
>>
>> did you check the unit used in Sophie. Because told me that their  
>> units are quite good.
>>
>> Stef
>>
>>
>> On 22 juin 07, at 03:11, Juan Vuletich wrote:
>>
>>> Hi Jerome,
>>>
>>> Jerome Peace escribió:
>>>> Hi Juan,
>>>>
>>>> Cool.
>>>>
>>>> Thanks for listening.
>>>> I've actually followed progress to know how much you
>>>> advanced things. (Real time performance and the color
>>>> background fix. Great steady progress.)
>>>>
>>>>
>>> :) Thanks.
>>>> I am using things on an old 400hz iMac running OS9.1.
>>>> I'm using one of JMM's old macClassic vms. So I need
>>>> to find out if you changed anything in th vm you
>>>> distribute with the system?
>>>>
>>> Not at all. I should delete the VM from the zip file. It is  
>>> misleading.
>>> Ok. Done.
>>> So, you are doing a serious performance test there!  
>>> Unfortunately, the
>>> Morphic 3 stuff uses Floats for coordinates, and I haven't worked on
>>> performance yet, so everything should be slow...
>>>> I can try somethings that blow my mac out to the water
>>>> complete with the macbomb system crash box. That only
>>>> happened while using a low memory allocation. I'm
>>>> having better luck when I give the vm more room.
>>>>
>>> I believe the same should happen with any Squeak image, right?
>>>> I am about to try your new addr. If this doesn't
>>>> bounce then were golden.
>>>>
>>>>
>>> Yep, here I am.
>>>> The last try missed probably due to some typing on my
>>>> part.
>>>>
>>> Now I'm working on scrolling and clipping. I hope to publish  
>>> something soon.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> _______________________________________________
>>> Morphic mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
>>
>>
>

_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: Re: NewMorphic Feedback (1 source control)

Herbert König
In reply to this post by Juan Vuletich-4
Hello Juan,

JV> pixels to books of several kilometers. But I want float coordinates and
JV> multiple nonlinear coordinate systems in the same world. I don't want to
JV> be restricted to Cartesian with a single scale all over the system. In a

that's good to hear! In road design and survey even 64 Bit Floats
aren't enough. A few trigonometric calculations and you loose your 1mm
precision.

Sorry, first attempt went to your private email.

Cheers

Herbert                            mailto:[hidden email]

_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
Reply | Threaded
Open this post in threaded view
|

Re: Re: NewMorphic Feedback (1 source control)

Juan Vuletich-4
Hi Herbert,

You're right. In fact we should be careful enough to support even higher
precision numerical representations, if the image has support for them.

Cheers,
Juan Vuletich

Herbert König escribió:

> Hello Juan,
>
> JV> pixels to books of several kilometers. But I want float coordinates and
> JV> multiple nonlinear coordinate systems in the same world. I don't want to
> JV> be restricted to Cartesian with a single scale all over the system. In a
>
> that's good to hear! In road design and survey even 64 Bit Floats
> aren't enough. A few trigonometric calculations and you loose your 1mm
> precision.
>
> Sorry, first attempt went to your private email.
>
> Cheers
>
> Herbert                            mailto:[hidden email]
>
> _______________________________________________
> Morphic mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic
>
>  

_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic