origin expression vs blend objects - performance question

[ofer]

Hi,

In a situation where I want a Null to have the position of one object, and the orientation of another object, I have two options:

1. Parent the Null to the first object and use the origin expression to grab the orientation from the second object.

2. Use a blend object parent it to both objects, and then take TX/TY/TZ from the first object, and RX/RY/RZ from the second object.

Both works fine, but if Im building a complex rig, with several Nulls like that one, will I see a performance difference between the two?

Im asking this because I noticed the when rigs becomes a bit more complex then a few bone chains, it also becomes very slow, and Im trying

to find good ways to optimize them.

Thanks.

[Jason]

Hi,

In a situation where I want a Null to have the position of one object, and the orientation of another object, I have two options:

1. Parent the Null to the first object and use the origin expression to grab the orientation from the second object.

2. Use a blend object parent it to both objects, and then take TX/TY/TZ from the first object, and RX/RY/RZ from the second object.

Both works fine, but if Im building a complex rig, with several Nulls like that one, will I see a performance difference between the two?

Im asking this because I noticed the when rigs becomes a bit more complex then a few bone chains, it also becomes very slow, and Im trying

to find good ways to optimize them.

Thanks.

I'm sure Arctor would be able to answer this, but I can't see how expressions could be faster than a Blend

[michael]

I'd say blends would be faster in a head to head test....

BUT - you'll take a performance hit for every node in the scene...so it's a bit of a toss-up...

we typically have ~1500 nodes at object level in our characters...which, amazingly, is even more than it sounds...our muscle rigs have WAY more...

so it really depends on the degree of complexity - esp since you'll have to manage/keep track of/fix all this stuff...

[thekenny]

wolfwood told me once that he profiled all the hscript commands and they were actually faster than CHOPs.

Mike is right about every node taking up memory and will consume your speedieness as you make more and more. Funny enough if you take advantage of the Pre-transforms and do not store the information in separate nulls then... you will be faster...as you can imagine it is optimized.

cool beans..

so.. wolfwood what say you?

-k

[ofer]

Thanks everyone.

1500 nodes sounds a lot. All in one digital asset?

So actually there are two opinions here, one says that more nodes is bad for performance and maintenance, but expressions are still slower, and one

says that hscript expressions are faster.

What was that about the pre-transforms? Can I use pre-transform to solve the problem I described, or is it just a general rule?

Thanks again.

[thekenny]

My comments were general information.

For your specific solution 1 object position with another object's rotation == BlendObject.

Since you are building the rig it makes sense to have that flexibility.

In general, use of pre-ransforms will give you faster performance, as mike mentioned over a 15k structure these little things add up. Yes that is a lot of nodes, but typical for a complex rig. Remember hands and feet take up the majority of the structure and then the facial system. The actual topic of "do you use pre-transforms or not" can get a bit religious with people wishing to maintain absolute control of what gets stuffed into them.

They really allow you to store offsets and are handy to present animators with the "zero" keyframe value, which again is a religious debate. (so holidays)

Yes there are other ways to get things to, some are faster then others. for instance if you are using attribute expressions you could store them in a detail attribute if want a faster return. Again it depends on what type of expression you are doing but those will be faster than others. I'm sure Ed could elaborate on that if he wanted.

If you start thinking that ever node adds a footprint, and its parameters and # of them can add a bit more memory it can be helpful to optimize things, but really that can get in the way. Somethings are "meant" to be more expensive then others and you just have to find the right spots to take the hit for them. One example is using a textureSOP to project eyes for characters.... which means per frame cooks and although it gives you control over deforming the iris/pupil when deforming the eye, it can be prohibitive for animators to see this while animating...so you can avoid it add give them an alternative display mechanism for animation and still render with the unique UVs. ... in the end its all options

Build the function first, profile it and then try options to optimize afterwards that would be best.

Good hunting

-k

Thanks everyone.

1500 nodes sounds a lot. All in one digital asset?

So actually there are two opinions here, one says that more nodes is bad for performance and maintenance, but expressions are still slower, and one

says that hscript expressions are faster.

What was that about the pre-transforms? Can I use pre-transform to solve the problem I described, or is it just a general rule?

Thanks again.

[AdamJ]

Storing object pre-transforms in the nodes itself will be more efficient as opposed to breaking them out into a separate pre-transform nulls in the hierarchy (for readability for example). I think there's an rfe for nodes to have some sort of visual indication that it contains pretransforms.

Yep as Kenny said nodes eat up memory/speed/cook times. Profiling the setup with Performance Monitor will help you see where the slowdowns are; you can track the memory usage with 'memory' in Textport (loading the hip with cooking turned off will show how much the nodes themselves take up before cooking).

Another thing to note is to avoid asset within asset setup. All those nested channel references will also cause performance hits. Flattening the rig to one level is best for speed.

Generally the blend should be faster than multiple origin expressions.

Yep the nodes are contained in the asset. It doesn't feel anywhere over 1200

edit:

Kenny beat me to it heh

Edited December 22, 2008 by AdamJ

[thekenny]

Another thing to note is to avoid asset within asset setup. All those nested channel references will also cause performance hits. Flattening the rig to one level is best for speed.

You see... I was actually hoping they had fixed this one.... but yes.. it can be painful... direct channel references are best... but that takes some planning when doing nested HDAs in an uber asset.

-k

[AdamJ]

I've had some ideas on how to avoid the whole thing with 'editable objects' in 9.5. Less channel refs and a clean (maya like ) ui for the animators .

You see... I was actually hoping they had fixed this one.... but yes.. it can be painful... direct channel references are best... but that takes some planning when doing nested HDAs in an uber asset.

-k

[thekenny]

okay.. you've said it... so show us

-k

I've had some ideas on how to avoid the whole thing with 'editable objects' in 9.5. Less channel refs and a clean (maya like ) ui for the animators .

[AdamJ]

lol

Here's the idea..

- ctrl objects are tagged as 'Editable Nodes' (field accepts wildcards which is handy)

- ctrl objects internals have permissions turned off so users can't mock around; ui is cleaned up

- display/callbacks/caching/etc would still be at top level

- hide asset rig internals since houdini jumps into the asset only leaving ctrls visible (still not sure if this is a good thing or not.. I could see it as a plus as the animators would potentially could have a nice layout to pick controls in network if needed)

- animator only see the current transformations of the control when picking the controls(ala maya)

I haven't had a chance to strip one of the rigs and redo it using this method, but in theory it sounds like it would give a performance boost as you're skipping the promotion of hundreds of ctrl objects tranformation channels. Also, the top level interface only would have a few tabs/folders since all the controls are now keyed internally. Still thinking about all this though..

ctrlsTest2.hip.gz

[edward]

I think the issues with this approach while potentially getting more speed is the same as it is in the other packages:

- how do you version your animation in a consistent fashion

- how do you update your rig to make fixes when you have it in use already

[AdamJ]

Animation publish would need to grab the editable nodes channels instead of top level character node and publish that. We were kicking around an idea that it would be nice for the 'editable objects' field to support opdef syntax (does it already? haven't tried it). Keep a list of the controls in the asset that need to be tagged editable, and use it in the animation publish process. All of our rigs are pretty consistent in terms of naming conventions/animation controls so publishing is fairly transparent.

We publish/version up rigs, the animator just updates their scene with a new publish. I think that process should still work with this workflow. Though you bring up a good point. With flattening of rigs you loose a way of doing sub asset modifications which ripple across the floor. There are ways of scripting/automating that on non asset nested character but it is an issue, especially when you have 100+ characters. Though at this point the performance impact from nested assets forces you to flatten the characters.. thought this is a topic for another thread probably.

[edward]

I'd think that there's potentially other problems. Like what happens when you remove a node in the rig? How do you still maintain the animation in the original shots, etc. The power of having a non-editable rig is precisely because animation is all on one set of parameters that you can easily redirect at will.

[ofer]

Very interesting stuff here. Thanks for the answers.