.

There should be another voting-possibility like "I use them to advance my animations, but I could live without them if I had to...".
I would vote for that...

Expressions are very helpful for some sort of Animations and useless for others... I combine both if I think it is neccessary or much easier to use one or the other...

*Fuchur+

I would use them but I have no idea where to start and dont really have the time to sit there and figure it out.

It is a pretty wierd choice of questions - not exactly encompassing all the options. Reminded me of a typical political poll.

There were only two pro-expression choices and one was



At least I think that was a pro-expression choice. On the other hand, it could be a sign of madness.

I love having expressions and I use them, but if I can get by with simple animation in the timeline, I will.

The main reason is that expressions tend to be invisible in the workspace unless you know where to dig for them.

In a production environment, I think that any time we use expressions, we will have to add some extra external documentation describing the use of the expressions. If we didn't do that, there would be times when an animator would be trying to modify a scene without even realising that expressions were there - a real recipe for trouble.

If there was a new sub-group in the Workspace called "Expressions' that allowed you to simply browse all instances of expressions, I would use them much more often.

Richard Harrowell.

The Squetch Rig uses Expressions for the squetch and Steve's Hand Gizmo...so, I use them a lot, they are a great tool.

I'm definitely interested in expressions but have had little time to experiment with them (or learn the math!).
Due to others interest here in the forum though I've slowing been gaining ground.

My primary interest is in automating location of objects with respect to other objects.
Example: A red ball moves into a field of blue and green squares... the blue squares move away from the red ball while the green squares advance and/or follow.

An oversimplification... but an interest of mine and I'm confident that expressions will provide the solution.
In general I want to create switches to control behavior in animation.

Rodney

I have tinkered with expressions and would use them more but I just wish there was better docs of all the available functions..I have preety much figured them out but an not 100% sure. This from a person who programed John Conways Life Simulation to work on Lotus and Excel and wrote page flipping machine language subroutines on my OSI computer. But has never programmed In C++ or Java script


By the way nice animation Colin

There should be yet another category you can vote for -- as it was I couldn't vote at all.

>> I believe expressions have a huge potential for use in animation but... right now I can't think of ways to use them or what to use them for!

Isn't that sad! And I'm fairly good at math. I guess its a matter of not having the time to researh and explore. I've searched for books on the subject thinking such a book would open my brain up to ways to put them to use but I found nothing (that was several years ago and I should check again).

Rusty

.

I think it's the limitation to equations that has supressed my interest. I'm a fluent Actionscripter in Flash; if A:M expressions were upgraded to incorporate loops and decision structures and other "language" things I'd probably be more interested.




He left out the choice to blame Clinton for everything!

.

The tough part is regulating the expressions vs. keyframe content. Ideally the contest entries would be pure expressions, no keyframe animation.

I many cases, expressions act like the opposite of relationships and so it is not that hard to work out the right place to use it.

Relationships are attached to the driving bone, channel or pose slider and can control one or many other A:M objects.

Expressions are stored in the destination channel (for example the X transform parameter of a model) and can be driven by any number of other channels in its calculations.

So basically if you want one thing to control many things, relationships are the obvious choice. When you want many things to control one thing, expressions are best. When one thing is controlling one thing, you can use either but you would probably use a single constraint if possible.

There are also some types of calculations that are much easier to implement in equations rather then relationships such as motion driven by time.

Where can you use Expressions? Basically anywhere - in models, in actions or in choreography.

Say for example in a chor, I wanted a model to always be in the geometric center of a group of 9 other models. I could do it by creating 9 translate constraints from my center model to each of the 9 objects the group.

Or I could use a single expression in each of the X, Y and Z channels of the center object which would seem a much simpler and neater solution.

Now if you want to try relationships out, you will soon realise that you have absolutely no hope of writing anything more then a very simple equaition directly in an expression edit box.

You build the equation in a text editor and paste it in. And Don't try the complex eqution right from the start.

So for example I want My model "M10" to always stay at the geometric center of models M1, M2, M3, M4, M5, M6,M7, M8 and M9.

I first write out a equation in the text editor in an understandible form:


So I have added together the X translate for the 9 models and I have divided by 9.0 to get the average X translate. That is hopefully simple enough to understand. You will see in a moment why I haven't gone straight to the final expression.

Now M1.X of course isn't a proper path to the X translate channel of object M1. I will use the Expression edit box to capture the correct path to the channel and I find it is:


Don't think that experienced users somehow know what these paths will be. You just let A:M tell you what the path is.

OK. Now is the time to stop thinking. Just take the equation above and paste the proper X translate paths in. Don't try and understand it - just do it.

If you do, you get this for the expression on the right of the = sign in the equation:


Just paste that into M10's X translate Expression edit box.
Now using the text editor, replace all the ".X"'s with ".Y"s and paste into M10's Y Translate Expression, and likewise for Z.

So for anyone who has looked at expressions written by others, the initial reaction is "I have no hope of understanding this - no way can I do this". Once you start building equations yourself, you will generate equally long and incomprehensible expressions, but generating them is really not that hard.

Two tips that really help are (1) most values used by expressions are floating point numbers with a range from 0.to 1.0 (So Red=255, Transparency = 100%, or time in timeline = 1 second are all represented in expressions by the value 1.0) and (2) parentheses are your friend - if you are not sure about the order inwhich calculations will be done, stick the brackets in to force the order.

Richard Harrowell.

Except some html and some lingo , I dont know much of programming.
And since there`s already so much to learn in AM
and then Expressions and then javascript for Webhamr,
why cant it be both the same javascript just to simpilfy things.
(Not that I know javascript yet)

One other feature that Hash definitly needs , is something like "Add the sea" , at least for my purposes.

;>) Jake

Math is a mystery to me ,I wish I had a very small percentage of Richerds understanding .It must be wonderfull to be able to use expresions

Excellent explanation, Richard.

However, within that gem of an explanation, I think Richard hit on possibly some reasons why many users don't try or use expressions that much - readability, and of course, debugability.

And, it depends on the user's orientation, as hinted at by others.

Expressions have lots of potential for those that desire to simulate physical systems, or introduce some randomness into their animations and are not normally put off by looking at such long incomprehensible-even if you wrote them yourself-strings for simple equations. Good also for repetitive, interactive applications. And also for just exploring, just because one enjoys figuring out how to make something work.

For an animation artist, and IMO, "randomness" usually looks best when introduced in deliberate manner. It seems much easier to just tweak those keyframes, so that it's best suited for aesthetics. Stylistic animation is about creating a universe for comic or exaggerated effect. (perhaps if there were a MakeItFunny function, it might entice more animators to explore?)

I think Real Animators like to play god. (hee hee - she said with a snotty tone)

ps I was the one with the keyframe fetish in the poll

You can run loops in the current state of a:m's expressions...
it comes in the form of the if statement.

I think that it could only help one to have an understanding of expression in
the software...
but last check thier are some wierd bugs in the expression system.
Like if you write expressions via touching the element you want in the
expression statment via the prj. workspace window, it sometimes wont
collect the info correctly.... you just have to manually retype the
correct words. But it could certainly contribute to ones
confusion when first learning expressions.

Mike Fitz
www.3dartz.com

Thanks Richard for that explanation.
It cleared out the gray areas a bit more for me.

I'm a big fan of letting A:M do the hard work. It excells at that.
Expressions are perfectly suited for that too.

I think where I often go wrong is in trying to make expressions do things they weren't necessarily meant to do.
I'll call these attempts 'switches' and 'variables' for lack of better understanding.
The ability to reuse these switches and variables is an important aspect of my plan.

In creating reusable switches I think the solution may be found in having the expressions drive a pose (pose slider).
As poses can be either on/off or a percentage that would give the switches a lot of range.

Variables (or controls) seem harder to do but could possibly just be the names of those switches?

If for instance, a variable was created called 'Proximity Control 1' it might be aligned with a Null that drives the value of that variable through its location, orientation and more. A character or object designed with that control in mind would then be effected by that control. Those without the control would (of course) not be effected.

I'll stop now before I hurt myself.

A study of the Squetch Rig and FACE controls would enlighten so I hope to do that soon.
Best to study more examples of what works methinks.

.

.

hmmm..interesting point.

Yes you're right. I definitely appreciate the beauty of mathematically produced imagery or procedurally created motion - and yes I think fractal geometry & motion is gorgeous & love looking at it, and am fascinated by it - but the process of creating with it is not as satisfying to me (nor as quick) as using a spontaneous and sloppy brush.

I can't say that I really like procedurally created music tho.

The patterns I've been working with recently have been chosen mainly because most of the textures are for manufactured type surfaces (fabrics, metal) - rather than for organic creatures & designs where I would be more inclined to handcraft abstract those surfaces (even though organic growth patterns are fractal) .

I hate having to interrupt a right brain process with thinking. It's not as relaxing for me.

But I love looking at someone else's creation who does - and yes I can be "tricked" into exploring expressions for motion art. (You clever trickster, you!!!)

.

Well, GetTime() doesn't actuall work that way.

GetTime() returns 1.0 after one second in the choreography regardless of frame rate. One of the nice things about GetTime is it is unaffected by frame rate so a model that uses GetTime in an expression can be put into a project with any frame rate you like and it will behave exactly the same.

What if you need to know the frame rate?

Just get the expression to read it (though it might be a bit buggy. I tried and I got this path for Frame rate: "..|..|..|..|..|..|..|..|" which didn't work. Changing it to "..|..|..|..|..|..|..|..|FPS" and it worked).

I think Nancy is absolutely correct when she is saying how ultimately she wants to control directly what is happening. Really, one of the really big things about Animation:Master is that is doesn't depend on script files the way other 3D programs do. It would be possible to do a complete animation and never touch expressions.

There is no reason why Expressions shouldn't be used to enhance the animators control over a scene rather then subverting it to random number generators and the like.

Expressions just LOVE pose sliders. They don't seem to like the Pose On/Off controls much, so use the sliders even for switches. Just make empty pose controls (ie with no relationship) and use them directly in the equations. They really work fabulously.

When you are using pose sliders in an equation, remember that 100% in the slider = 1.0 in the expression.

Simple.

Also Bones are fabulous either as sources of input to an Expression or as the object controlled by the expression.

Say you want a looping function as Colin is discussing. Sure you can use the Mod function in expressions, but you can also add an extra bone to a model and use its Z rotation as the looping function.

So something rotates the bone (could be an expression or direct animation) and then another expression can use the Z rotation value as the input to the eqution that was meant to loop.

For the animator, this can possibly gives a number of advantages:

- They can see the bone position when they are animating
- They can, if they want, directly animate the bone positon
- They can constrain other bones to this rotating bone.

So yes, Expressions could be used for example to generate the perfect parabolic flight of an arrow, but if it looks better to animate the flight yourself for better dramatic effect, do it.

Using an Expression with some extra manual controls (like a pose slider) could allow you to have a computer generated arrow flight, but with an extra control that allows the animator to control the speed, so in the animation of the arrow flight can have a real feel of floating slowly in the air and then arriving at a huge speed.

So use correctly Expressions can help the artist, rather then subverting the artist.

Nancy - I really appreciated your edited summary of my post.

I think you really picked out exactly the key points I was trying to get across.

Richard Harrowell.

Definitely one of those 'Now why didn't I think of that' moments.
Thanks for that Richard.

I am pdf'ing these posts for further reference

.

Go easy on me Colin. I'll change!!! *sob*

(especially if this discussion on expression continues)

I just heard today about a rule of thumb in the publishing industry:

“Book sales are inversely proportional to the number of equations in the text.”

In most cases where you could use equations, you can do the same thing with conventional timeline animation.

I think Hash have been very smart in making an animation program that can be used completely without the animator using mathematics at all. Its nice that epxressions are there, but I like it when I do not need to use them.

Richard Harrowell.

.

I couldn't find me in the poll....something along the lines of" I like expressions...but I haven't needed them often and most of the time I can do it by hand faster than I can figure it out. I'm still glad they're there"
I script in other programs by hacking up and rearranging bits of other people's scripts, if there was more information/examples I'd use them more. Threads like this make a good start

Since I have already said I like having equations, I am obviously not going to suggest they are bad.

I was trying to acknowledge how clever most of the rest of the A:m animating environment is.

A:M is a pure mathematical package - absolutely everything it does involves mind staggering amounts of extremely sophisticated an precise calculations. In spite of this, Hash have been able to provide intuitive and non-mathematical controls to almost all the features.

The fact that an animator with a good artistic eye, or a good feeling for motion is able to precisely direct this unbelievable concert of calculations without thinking about a single equation themselves is really quite brilliant.

Expressions in A:M are at a really simple and basic level. What they often end up doing is simpler even than what is happening in a typical constraint (the mathematics happening behind a lot of constraints is awesome). And the truth is if you are not good at mathematics, there is always an alternative to equations. For example, the Squetch rig hand uses Expressions. I liked the control interface but I thought the hand was far too complicated for my needs (we never use the squash and stretch features at all). I designed my own much simpler hand rig with exactly the same control interface as the Squetch rig hand and it does not use Expressions

The point of my quote was this.

If someone posted a tutorial on how to achieve some difficult effect using Expressions, I believe a typical response would be "Wow! That is great. I will file that tutorial away so I can read it one day." Most people will probably never bother to fully understand the tutorial at all.

If someone posted a tutorial on how to achieve the same effect without using Expressions, a typical response would probably be "Wow!. I never thought of using bones like that. I get it."

At the end of the day, Expressions are a band-aid - a way of quickly achieving an effect while you are waiting for someone to develop for A:M some better intuitive and non-mathematical tools for acheiving the same results.

Richard Harrowell.

The IF test can enable some loop-like things but without being able to build variables with strings inside the loop too many things have to be explicitly coded and you can't make generalized code that works in arbitrary situations.

Think crowd simulations where a character must repeatedly test his relationship with every other character in the scene. Do you want to code a separate test for every character or one loop that can sequence through all the characters just by changing a number on the end of the character name?

More tutorial like practical examples of most functions offered will help more people than the info in the technical-reference alone.

Expressions can be of great value and ease at animation time.


[EDIT] I also wish the technical-reference would be more clear in things like, getTime or getChorTime, will it return in seconds like 1,2,3 or in seconds with hundreds like 1.88 or in seconds with frames like 1.30, I would like the functions described more clearer.

Its in the nature of the artist to try to take on more than is reasonable.
That'd surely describe me.

Robert hit on the usage I hope to someday incorporate into one of my own animation projects... crowds.
I haven't spent much time working out the intracacies but I know its going to take some doin'.
Expressions (among other things) will surely be key.

I'm way ahead of schedule (right now there is no schedule) and don't have to have the solution right away.
But I keep trying to learn as I know I'll be staring at that scene some day.

Explorations and discussions like this help me better understand my options.

.

.

Its been over a year since my last 'crowd test'.
It was pretty promising but I had more pressing things to move on to.

If I understand what you said you are pretty close.

What I experimented with was rendering out several characters performing representive actions like 'Move Forward', 'Dodge', 'Pary', 'Thrust'. You know... that kind of thing. It was very very simple stuff. Most were just various walkcycles standing in.

Then I set up 'cards' to represent those characters. I experimented with Layers and simple meshes and for the most part they worked the same. I liked the meshes better as I could add bones to them whereas Layers I could not.

I never got past the initial stages of automation.
I replicated the basic movements of one of Hash Inc's Dynamics Tech Talks and that was reassuring.
I can't recall ever trying Newton Dynamics so I don't think I had access to it at that time.
I briefly tested images via particle hair and really looked promising for far away characters!

In the end I found that using really simple images for the far background worked well. Characters with a bit more detail worked well in the midground, many of the forward troops were still on cards and the hero shots were actual models. The standard techniques.

Alas, those tests were lost when my laptop died as I left the middle east.
Probably best though as I hope to rebuild them bigger and better.

Colin, what I going on here? I have said I like having Expressions and I even gave some (hopefully) contructive tips to encourage people to give them a try. You seem to think I am bagging the feature or something.

I will repeat I like Expressions and I do use them, but they are a band-aid. Expressions only touch on the minimum features that a programming environment usually allows, and that is fine.

For example you could use them to simulate some extremely simple physics, but Steffen Gross's Newton Physics plugin does about 1000 times more then expressions could ever do.

And I am not saying you have to wait for others to develop tools either - lots of Hash user (like Steffen) have gone and written powerful plugins themselves. I know Martin would love to see much more SDK programmers developing tools.

If you are having fun with Expressions then that is really good. I am honestly not trying to be funny or cynical or anything. I really am glad you are passionately spreading the word about Expressions.

Richard Harowell.

.

OK No more "negative" comments then.

I guess my opinion at the moment is colored by the fact we are setting upn a studio at the moment and Expressions is probably about the least self documenting feature in A:M.

If you have to take over someone elses work and you don't know it uises expressions, it can be pretty interesting.

OK then - something positive:

Question: How do you workout exactly what functions do - particularly functions like GetTime()?

Anwer: You set up a simple test. Just make a new model with one bone in it starting at the origin (0,0,0). Now add an expression in say the X translate consisting of the one single function you want to learn about.

Then just use the timeline to view what happens with the X translate.

So for example with the GetTime() function, you will see the graph of the X translate is an absolutely straight line passing though 1 at 1 second, 2 at 2 seconds, etc.

So from that you can quickly see that Gettime returns real seconds - not frames. It is very quick doing a simple test and it really doesn't take long to see exactly how each function works.


Richard Harrowell.

.

As far as I can tell, a typical programming language-style value assignment like



isn't possible in A:M expressions. Or is it?

It seems the timeline nature of expressions makes that unlikely.

.

If you mean can you define variables to hold, say, a counter, then no you cannot.

The only place a result can be stored is into a channel such as a bone's X transform, Z rotation and so on.

You also cannot do multiline equations - everything must be in a single statement.

Having said that, you can certainly just add extra bones to act as variables. The only thing is that if you re trying to implement a multi-statement function using several expressions, you obviously need to be able to define the order the expressions are evaluated and I do not know how to do this. (I am not going to say it is impossible - with A:M there is usually a way).

Also, to try and implement a counter-type function ( like X=X+1) is probably a non-sensical approach im A:M. If you are running multipass with motion blur, all the expressions will be run multiple times for each frame with each pass being evaluated at a slightly different time. Your counter would probably get incremented on every pass rather then being incremented once per frame. A much better solution is to replace the X=X+1 counter either with the GetTime() function or with an animated channel (say a Pose Slider) and use the pose slider's value in the equation.

The only way to implement a really complex function programatically is to move on to the A:M Software Development Kit (SDK). In the SDK you are programming in C++ which means you can do almost anything in terms of calculations - including calling up 3rd party libraries.

Richard Harrowell.

The X+1 was just a "fer instance". There are all manner of situations besides counters where one wants to do X=X+SomeValueDerivedFromSomeOtherCircumstanceInTheAnimationAndNotNecessarilyACon
stant.

But X not being able to operate on itself is a problem. Yes, some clever person needs to devise a scripting language. Preferably similar to one I already know.

I did understand what you were saying - I just called it a counter because a counter is a common example of this kind of code. The key point I was trying to make was this.

If what you intended was


Then you have a real problem with expressions because the expression will be evaluated once per pass, rather then once per frame.

Let me give an example of exactly where you face this problem. Expressions are great for rotating a wheel. Something like


will cause the wheel to rotate once every second. But the problem here is that this is a wheel going at a constant speed - in most cases, you probably need to be able to vary the speed of the wheel. So we do this:


It does work in controlling the speed, but there is a huge problem - if you change the speed of the wheel, the wheel also suffers a sudden angle change. Say you go from full speed in one frame to a sudden stop the next frame. According to this formula, the wheel angle at speed = 0% is always 0 degrees. So whatever the angle of the wheel on the previous frame, it jerks back to 0 degrees rotation when you stop it. It is actually a bit worse then that. If you had rotated the wheel forward 10 rotations and then you stop it, it will rotate backwards 10 turns in one frame before stopping. Ugly! The obvious problem is that it doesn't have a memory of its angle the way a real wheel would have.

The next thing you might then try and do it to add this memory by something like


Now even if this worked, it would be calculated once per pass, so if you rendered at 16 passes, the wheel would move forward 16 times in the one frame.

This is just the wrong thinking of thinking in A:M. A much better way of getting the result in A:M is this:


Now you just animate Wheel_Angle_Slider in the timeline. An upward slope in the timeline will turn the wheel forward, a downward slope will reverse the wheel, and a flat horizontal slope will be a stationary wheel. This solution will also work absolutely perfectly with multipass rendering and motion blur. As a solution, it might not seem as nice as the old speed control, but it really works.

So in summary, if you need an equation like X=X+1, then you are trying to solve a problem in the wrong way. There will almost certainly be another better solution that will not use the same channel value on both sides of the equation.

Richard Harrowell.

.

pretty looking curves Colin - might be useful for creating paths for painting with sparkly pretty sprites that have persistance

That's why I said "the timeline nature..." at the very start.

I'm just dreaming out loud here. X=X+something is one of the classic programming tactics; it works in Flash animation without catastrophe. The clever guy who devises a genuine scripting environment for A:M will find a way for certain scripts to be executed once per frame rather than once per pass, and will find a way to make x=x+something legal.

The thing I was trying to explain is that you cannot do a single evaluation with multipass rendering because each pass can be done at a slightly different time. The expression has to be evaluated every pass. There is not even a defined order in which the different passes would be done at or a defined time gap between the passes - all that is up for A:M to decide for itself..

One of the biggest problems in learning a new programming language is that you tend to try and use tricks from the old language. In A:M anytime you want to do a X=X+1 expression, there will be a better alternative way of getting the same result.

Richard Harrowell.