Scaling + move!() == ant feast
-
Buggy as hell. I am trying to sort it out. Will let you know.
transform!()is one solution. If you want to animate (and I do) ...You don't need an animation to study the critters. Just try scaling/transform and then the same scaling/move. Ugh.
Aside: I now believe the docs are correct re
move!(). It's the code that's bad. The guy who wrote this had a very bad day. -
You do not need to use the .move! method in a transformation. You can stick with .transform! if you prefer. You could keep it from being added to the undo stack yourself by wrapping your code in start and commit operation methods.
Also, its hard to say if the docs are right and the programming is wrong or vice versa. But we can say how it actually works. And it works so that
.move!is the same thing as.transformation=.So just keep that in mind, and you can use
.move!with no glitches whatsoever (wow that leaves me wide open to get proven wrong in a million ways....
). I even posted sample code for how to use .move!and keep scale and rotation intact, by first applying the scale and rotation to your transformation object before applying your transformation to the group/comp with.move!I think there is room for improvement in the docs and the ruby methods here. Taking the time to hash out some of this stuff will hopefully make changes possible for SU ver.8. We just need to have a coherent report of the problems, and desired results, and a list of possible fixes.
-
@chris fullmer said:
You can stick with .transform! if you prefer. You could keep it from being added to the undo stack yourself by wrapping your code in start and commit operation methods.
It will still add something to the undo stack - not really transparent. the start_operation will add one undo point. Where as
.move!adds none. No way around that until they fix the third and fourth argument of.start_operation. -
Ahh yes, true there. It will add a single undo command, no way around that then.
Chris
-
@chris fullmer said:
You do not need to use the .move! method in a transformation. You can stick with .transform! ... by wrapping your code in start and commit operation ...
Wish I'd thought of that. I just want to fly my airplane.
Anyhow, I've got translation and rotation plus the global scaling cases done. These are xforms after transform (SU) and move (after me poking values into the xform).
Now if only I could think of a nice, high-level way to describe movements. I've got some Ruby that taxis down the runway adding speed as it goes, lifts off, tilts tail down, gains altitude, levels off, flys away. It's great to watch. Need to turn, return, land...
But the Ruby is an ugly mess. Not something you'd publish with your name on it. Hmmm.
-
Curiosity, here:
Is the ! a special modifier for move or transform? -
It's a ruby naming convention. ! at the end of a method name indicates that the object it's performed on will be changed. Possilby destructible or irreversibly. like
.erase!Then you have the ? which denotes a query, like
.is_a?()or.same_direction?() -
You find it in pairs of commands too - like with arrays
a2=a1.reversemakes a2 the reverse of a1, AND a1 is unchanged.
BUTa2=a1.reverse!makes a2 the reverse of a1 AND it also reverses a1 at the same time ! -
Damn! (notice modifier at end of damn)
So much to learn--so little time.
Advertisement