Expression Affects Any Object?

[positron]

Is there a way for an expression to affect ANY and ALL objects in a scene. For example, I'm using cube.bbxx attribute to drive the visibility of multiple objects.
I can get it to work on a single object by naming it discretely but how to get it to work on all other objects in the scene?
If it helps, it's okay if the other objects have listed names, like ball1, ball2, ball3, so as to write an array or something similar? There will be a LOT of these other objects.

Thanks.

[mantrid]

Either place all objects into an array (recommended) and add a bit to your script to select all objects in the array, or just select all and then tell the expressin to affect selected....also, adding a naming prefix to all objects you want it to affect is a good idea....e.g.

//select all
select -cl;

OR :

//select all with name prefix
string $body = "select -r "objects_*"";
string $selection[] = ls -sl;

Now you can use the array $selection[] to apply your rules to in the expression.

[positron]

Cool--this points me in the right direction.
My actual code is looking at individual objs bounding box, it looks something like:
if ((a.boundingBoxMaxX > b.boundingBoxMinX)&&(a.boundingBoxMinX < b.boundingBoxMaxX)) then b.visibility = 1; etc...
Since there will be a great number of obj 'b's (b1,b2,b3...bn) all controlled by obj 'a' my problem was how to assign an array of b1-n and have 'a' look at them all at once in the bb detection line of the expression. I don't know how to replace an objects name ( with a variable ($ or whatever--kept getting syntax errors.

Hope this spells out my problem a little better.

[mantrid]

Heres an example :

//select all with name prefix
string $body = "select -r "objects_*"";
//Enter selected into array variable
string $selection[] = ls -sl;
//new string $current representing array elements
//for each element in array
for ($current in $selection)
($current + ".attribute") = <>;
//clear selection
select -cl;

I can't guarantee that syntax as I don't have maya on this machine, but its close enough for you to work out any mistakes.... if there are any Its obviously not ideal in this form for your expression, as you don't want a runtime expression to select lots of objects every frame, but it'll get you started.

[markwilkins]

Here's the thing...

Expressions that execute MEL commands (doing things like selecting objects and so on counts) are HIGHLY inefficient.

The reason that it doesn't work to substitute variables into object names when you're referring explicitly to their attributes in an expression is that those explicit references are evaluated by Maya when you make the expression to figure out to what nodes the expression node you're making needs to be connected. Use a variable and it can't figure that out when you make the expression.

Using "getAttr" and "setAttr" is a poor choice because those connections DO matter. If your expression affects nodes to which it isn't connected, Maya has to throw away everything it knows about the state of your scene and start from scratch on each frame because it can't necessarily determine what side-effects your expressions are going to have.

You must have some mechanism for making these objects, either a by-hand workflow or a MEL script. The approach that will make your scene evaluate fastest is to use a MEL script at object creation time to make an expression, probably one per object. This MEL script could either be triggered by a shelf button (if you're making these objects manually) or by the MEL script that makes the objects (if you're automating that part.)

You could, for example, construct the text of an expression to drive one object's visibility and use the expression command to hook it up at object creation time.

By not executing MEL commands in your expressions you'll avoid possibly costly re-evaluation of large parts of the dependency graph each time your scene gets recalculated, which will make your life much easier once these objects are in the scene.

Here's a specific example. Suppose you're making a hundred spheres in your scene with a MEL script and you want an expression that makes them oscillate in their local X axis.

You could make an expression (or even a scriptJob) that uses ls to get all the names of everything that has sphere in the name, then use getAttr and setAttr to make them oscillate. However, this would be SLOOOOOOOOOOOW. Also, you'd have some trouble getting the expression to evaluate because Maya uses its connections to figure out when to run it.

The better way is to use code like this WHEN YOU MAKE THE SPHERES:

string $mySphereName[] = sphere;
string $myExp = ($mySphereName[0] + ".tx = sin(time);");
expression -s $myExp;

(Note that sphere returns an array of strings which contains the name of the transform node in element 0 and the name of the shape node in element 1.)

This makes a separate expression for each sphere that's connected to its tx attribute. Maya now knows when each one needs to be evaluated by virtue of its connections, and the expression itself doesn't use any MEL commands that create or destroy nodes or get or set their attributes.

-- Mark

[joojaa]

Hmm why use expressions at all in this case just do a mel loop that connects the visibility to the atribute that you want to controll them. Its much faster! Since they all now share the same atribute!

[mantrid]

...Thats a very good point Joojaa. DOAH!!!

[markwilkins]

Joojaaa, are you suggesting a script job??

Script jobs are from hell. Avoid using a script job at all costs -- and DON'T rely on them for render-time execution of your scene.

Expressions are the way to do this, trust me, unless you ONLY want the behavior to happen while you're working and not while your scene is being rendered. I don't even know that scriptJobs run at all when you're batch rendering, but maybe someone else knows better.

-- Mark

[gmask]

Mark,

Do you know if it is possible to execute scripts during render time based on which render layer is about to be rendered? Also is it possible to change the how any given pass that is rendered is named.. such as shortening the names of a beauty pass to simply _B_ or something like that?

[positron]

Thanks for all your help guys. Mark, i will be picking up that book at first opportunity. In a nutshell, though, it seems that expressions aren't the answer to my problem. Expressions are keen for runtime iterative behavior, it seems, but not for conditional detections on mass groups of objects.
An example:
Say I wanted to animate a cube through a space filled with lots of different spheres. When a cube occupies the same space as a sphere, the sphere scales up by a factor of 2, say, and changes color. So this is fine if there are only these two objects, but if I wanted to move the cube randomly through a volume of like, 50 spheres, it doesn't seem expressions are geared for checking up on the behavior of all these objects.
Unless, of course, I use a script to create the spheres and on creation, tag each one with an expression that sources the single cube object?

Maybe. Seems inefficient though. Is this a proper usage of expressions?

I'll play around some more.

:xposx

[markwilkins]

Yes, that's absolutely a proper use of expressions. Of course, your scene will have a lot of interacting expressions if you do this, which might make it a mess to sift through in the Hypergraph.

There are other ways, though. For example, you could possibly use particle-instanced objects and particle expressions to do some of what you want. A particle expression will automatically be evaluated for each particle in the object, and you can use particle instancing to make many copies of an object all over the place. (This is ideal when you want hundreds or thousands of identical objects in a scene.) This will also evaluate faster than a whole mess of expressions per-object.

The thing is, whether you use some kind of per-frame MEL script to muck with attributes or use object expressions or particle expressions, Maya still has to do the same basic evaluations. Object expressions and particle expressions, however, will give Maya the opportunity to wring out some efficiency in evaluating the scene by culling out calculations that don't have to happen because objects are out of frame, or because the inputs aren't changing.

Running a MEL script once per frame will always recalculate everything, every time, and will thus be slower, possibly much more so.

[joojaa]

In reply to:
Joojaaa, are you suggesting a script job??

No, im talking about using connections (its so ovious that it was missed)! but you coud have script job to do the connections if you wish. But since its not doing the change it wont slow things down.

[joojaa]

In reply to:
Do you know if it is possible to execute scripts during render time based on which render layer is about to be rendered?

somebody has done a plug that allows you to do own layers hmm ill dig it out for you! It runs scripts priror to layer change and so on... It was in one very similliar thread!

[gmask]

sweet!

[markwilkins]

No, im talking about using connections (its so ovious that it was missed)!

Ahh, then yes, I'm with you on that.

but you coud have script job to do the connections if you wish.

I doubt you'd really want to do this, considering that a script job runs constantly, over and over again, ALL THE TIME while you're working... maybe just a MEL button?

-- Mark

[campbell]

in this case it makes no sense to dirrect conect, as the OP is talking about testing conditions for each object, and issuing a result on a per-object basis, not just one test condition, multiple results ? id probably go w 50 indep. expressns, or maybe clusters (do some timing to figure out efficiency). if the non-control objects were moving, this would be more efficient as it'd only eval expressn/s w it in it, and not test everybody else. maybe a particle expressn might work as a quick initial pass to see if the objects centres are w/i the control obj's bbox, and if so, do the rest of the checks to see if its wholly w/i the bbox. you'd have to do some tests to find the most efficient.

In reply to:I doubt you'd really want to do this, considering that a script job runs constantly, over and over again, ALL THE TIME while you're working...

thias is interesting, a qn ive been meaning to ask for a while now. i use them for interactive setups. i was hopping thet would be rather efficient, being triggered _only_ under given conditions, that they actually get woven into the dg (in the case of conxn watching). for watching connections or attribute changes, they are like little parasites on nodes, that get disturbed only when the evaluatn stream rattles past their hole. id imagine other events or conditions are also discrete occurences that scriptJobs latch onto, and trigger only then. certainly they only do their thing when the conditions are met. sure, things like checking for new DAGs will run on all creation events, and hence not neccessarily the ones you want ...

[markwilkins]

script jobs don't get hooked into the DG in any normal sense. According to the Maya documentation:

"This triggering happens very frequently so for speed considerations no events are forwarded during playback. This means that you cannot use scriptJob -tc tcCallback; to alter animation behavior. Use an expression instead, or the rendering callbacks 'preRenderMel' and 'postRenderMel'."

-- Mark

[campbell]

hmm, wish they would be a little more explicit! so there is a whole heap of testing to see whether the scriptJob should be run? sounds poopy. why cant they hook into the evaluatn network? like miny expressions attached to node attribs, rather than as indep nodes. thinking about the attribute monitors.

cheers.

[markwilkins]

well, not really.

Internally, Maya has, among other things, an "event queue." Certain things trigger events, which in turn either trigger things internal to Maya or make scripts that have been installed as scriptJobs run.

Because a goal of Maya was to make playback seamless, the event queue gets suspended when Maya's playing back, so script jobs don't run. Also, the event queue is not enabled when you run stuff in batch mode.

At least that's my understanding. I admit to having a fuzzy picture of the details.

-- Mark

[joojaa]

hmm jep thats probably true. But i think that if you attach a script job to a certain atribute it only gets run whan that spesific event comes up. Offcourse it adds a 2 querries for the event even if it isnt to be run but...

but not all events are realy helpfull. Some are just too broad!